VB6 project (VBP) file changes upper/lowercase among computers

We check in our VB6 project on PC 1, and get it on PC 2.

When we want to run (F5) it on PC 2 VB6 says it cannot save the VBP file (which is readonly because not checked out). Strange because nothing changed, we only loaded the project and want to run it.

I checkout the VBP file and saved it to diff the changes, and on a few lines are changed the case is changed:

(See \ADO)
Repository version: Program Files\Common Files\System\ado\msado26.tlb
Working version: Program Files\Common Files\System\ADO\msado26.tlb

On both machines there is the same directory:
C:\Program Files\Common Files\System\ado

Another difference:
Object={5664FAD6-05FD-11D4-AABA-00105A6F87AB}#1.0#0; dxeditrs.dll
Object={5664FAD6-05FD-11D4-AABA-00105A6F87AB}#1.0#0; dxEditrs.dll

Both DLL's are installed with capital E, the filename is the same on both drives.

Object={6A24B331-7634-11D3-A5B0-0050044A7E1A}#1.7#0; dXDBGrid.dll
Object={6A24B331-7634-11D3-A5B0-0050044A7E1A}#1.7#0; dxdbgrid.dll

Object={F9043C88-F6F2-101A-A3C9-08002B2F49FB}#1.2#0; comdlg32.ocx
Object={F9043C88-F6F2-101A-A3C9-08002B2F49FB}#1.2#0; COMDLG32.OCX
and so on

Both PC's run VB6 SP6.

I hope someone can give me some information why VB6 changes cases of references and paths in the project file.


Who is Participating?
HooKooDooKuConnect With a Mentor Commented:
One of the things we do is to maintain two copies of the VBP.  One copy is the "developement" version that the programers are free to load.  It's "ok" if they mess that one up because of things like different versions of DLLs (a big issue if your project includes DLLs you've written yourself and therefore likely change all the time).  We then also maintain a "release" copy this is only ever openned from the "official" compiler machine.

With this scheme, you're always safe allowing the "developement" version of the VPB from getting saved every time you want to do something, yet presurve binary compatibility and avoid undesired changes in your "release" copy.
First of all... it sort of seems to be a fact of life with VB6 projects.  Even for projects I create on my machine, put in source safe from my machine, and reload from my machine, if I want to run the application, VB wants to save the file even if nothing has changed.

Now logically, something that sort of does change every time a VB project opens is that it wants to update the ActiveX OCX/DLL links to match what ever is on the local machine.  I know this is something that has tripped us up before... create a project on one machine, load it on another machine with newer versions of an ActiveX OCX/DLL, then try to reload the project on the old machine and it fails to properly load because VB can't seem to "down grade" the OCX/DLL to what is on the older machine.

As a guess (and this is sort of a guess), the reason VB wants to save the VBP file is because even if nothing has seemed to change, because it always attempts to update ActiveX links, the moment the VBP file is openned, it is immediately "dirty" because it attempted to update the ActiveX links.  As for the upper-case vs lower case, as a guess, perhaps the controls are registered on one machine with one case, and registered on the other machine in the other case.  If so, again, VB attempts to update the ActiveX links when the VBP is openned.
Go to Tools|Options|Environment, there you will see some options for what VB6 should do when a program starts. If it is set to 'Save Changes', it will attempt to re-write the VBP file whether it has been changed or not -- I don't know why. You may be tempted to set it to 'Don't Save Changes' and handle the saving yourself, but I would caution against that as it is too easy to forget to save before running and end up losing work if something happens to make it crash. The safest option is to set it to prompt, in which case it will run an unchanged program without prompting but could become a bit of an annoyance if you're making changes and testing frequently.
Introducing Cloud Class® training courses

Tech changes fast. You can learn faster. That’s why we’re bringing professional training courses to Experts Exchange. With a subscription, you can access all the Cloud Class® courses to expand your education, prep for certifications, and get top-notch instructions.

_Rene_Author Commented:
It seems there is no solution for this problem other then 'live with it'.

I am not sure if this is related to my other post about DynamicReports that marks all binary files dirty after a build.
_Rene_Author Commented:

Nice solution, but I don't see how to use your solution with source control because the 'free' VPB is not bound to it.

Keep the "free" VBP in source safe as well.  There isn't any reason why multiple VBPs can't exist in the same folder/source-safe.  But the idea is that even if someone else has it checked out at any given time, because it's an "unofficial" copy, you're always free to just make it writable on your local machine without worrying about overwritting someone else's code changes.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.