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

Posted on 2009-04-21
Last Modified: 2012-05-06
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.


Question by:_Rene_
    LVL 16

    Expert Comment

    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.
    LVL 11

    Expert Comment

    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.

    Author Comment

    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.
    LVL 16

    Accepted Solution

    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.

    Author Comment


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

    LVL 16

    Expert Comment

    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.

    Write Comment

    Please enter a first name

    Please enter a last name

    We will never share this with anyone.

    Featured Post

    How to improve team productivity

    Quip adds documents, spreadsheets, and tasklists to your Slack experience
    - Elevate ideas to Quip docs
    - Share Quip docs in Slack
    - Get notified of changes to your docs
    - Available on iOS/Android/Desktop/Web
    - Online/Offline

    When designing a form there are several BorderStyles to choose from, all of which can be classified as either 'Fixed' or 'Sizable' and I'd guess that 'Fixed Single' or one of the other fixed types is the most popular choice. I assume it's the most p…
    I was working on a PowerPoint add-in the other day and a client asked me "can you implement a feature which processes a chart when it's pasted into a slide from another deck?". It got me wondering how to hook into built-in ribbon events in Office.
    As developers, we are not limited to the functions provided by the VBA language. In addition, we can call the functions that are part of the Windows operating system. These functions are part of the Windows API (Application Programming Interface). U…
    This lesson covers basic error handling code in Microsoft Excel using VBA. This is the first lesson in a 3-part series that uses code to loop through an Excel spreadsheet in VBA and then fix errors, taking advantage of error handling code. This l…

    779 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    12 Experts available now in Live!

    Get 1:1 Help Now