Vault and Visual Basic 6

Paolo_ituk1971 · Post by **Paolo_ituk1971** » Fri Aug 17, 2007 6:43 am

I am part of a team of 5 developers working with Visual Basic 6.

We have decided to start using Vault for source control but have hit a problem.

When working on a vb project, every time I start the application for debugging (Run -> Start) the IDE saves any modified files AND the project file (vbp).

As the project file is not checked out (read-only) the IDE will not start.

We want to work with exclusive locks and therefore each developer has to be able to debug the application without checking out the project file but only checking out the files they are actually working on.

How can we overcome this issue ?

Thanks.

davidt · Post by **davidt** » Fri Aug 17, 2007 8:27 am

In VB6, you can visit the Tools->Options dialog, and click the Environment tab. There, you can select that when a program starts, changes are not to be saved.

VB6 wants to save the project file because it thinks the contents have changed. This is often because referenced COM libraries are stored in different locations on your team's computers, or different locations relative to the VB6 source code you're working on.

Regards,

Paolo_ituk1971 · Post by **Paolo_ituk1971** » Fri Aug 17, 2007 1:22 pm

Thank you for your reply David.

We decided against this option because of the risk of losing any changes made should Visual Basic 6 crash while debugging (It has happened more than once).

Is there any other workarounds to resolve this issue ?

Thanks

davidt · Post by **davidt** » Fri Aug 17, 2007 1:39 pm

Well, the basic issue is that VB decides on its own when it feels the VBP needs to be rewritten on disk.

1) You can enable multiple checkouts on the VBP. Then the team can all check out the VBP file, and VB can happily save when it wants to.

2) The team can each make their VBPs writable on disk. VB can happily save, but the file shows as "Renegade" in Vault. Biggest problem is the possibility of making inadvertent changes in the project file that affect how your code runs.

3) Turn off save-before-run, and acquire the habit of saving manually before running. This is what I do.

4) Analyze what is changing (or what VB thinks is changing) in the VBP file, and make appropriate corrections in your dev environments so VB doesn't feel the need to save the VBP as often.

That's really about all there is. Either allow the save to complete, or arrange things so VB doesn't try to save the file.

Regards,

Beth · Post by **Beth** » Fri Aug 17, 2007 3:25 pm

David has it.

If you wish to make it so your project files can be checked out concurrently, you will need to set those as mergeable file types in the Admin tool under Repository options.

It would be best to find out what is being changed.

If all your changes are in Vault, you could also perform a Get out to a different location than your working folder and run the debug on that copy instead.

Paolo_ituk1971 · Post by **Paolo_ituk1971** » Sat Aug 18, 2007 8:57 am

Thanks for the advice.

I feel that introducing concurrent check-outs and file merging would add a layer of complexity to our development environment that I would rather avoid.

Our project references COM objects so that is probably why VB is trying to save the project file, as Mark suggested.

I will go down this route and try to prevent VB from saving the project file by adjusting reference locations/values on all development machines.

Thank you.