Incremental VB6 builds not always working when a reference changes?

[gmichaud]

Hello,

I would like to know if there are any reasons that would cause Visual Build not to rebuild a project when a related project has been rebuilt. The "Exclude references when determining the need for incremental build" is not checked, and we were successfully able to use this feature for a couple of builds. We're setting all projects to project compatibility before building.

In our build, project A is referenced by project B. Project A is modified and recompiled first by Visual Basic, but project B is not recompiled because Visual Build thinks the project has not changed. However project B is newer than it's compiled DLL on disk. After recompiling project A Visual Build correctly updated the references in all related projects but did not recompile every projects that were referring it.

I would gladly send a sample project to reproduce this problem, however there are more than 50 projects in our project group totalling almost 1.5gb in source files.

Are there any guidelines we need to follow for this feature to work? Anybody here ever had similar problems? Would enabling "Set binary compatibility after compile" help?

Thank you.

[kinook]

That should work. The VStudio.bld sample demonstrates a project group where essentially that occurs (FirstVB has a reference to SecondVB, and FirstVB gets built if it is up-to-date but SecondVB was built). I've attached a modified VStudio.bld sample that I used to verify the correct behavior in this scenario (adding steps to modify a source file in SecondVB to cause it to be built, and setting projects to project compatibility), and this is the build output:

Processing 'c:\temp\VisBuildPro\VStudio\work\Source\SecondVB\ SecondVB.vbp'...
incrementing version...setting project compatibility...building ('c:\temp\VisBuildPro\VStudio\work\Source\SecondVB \Class2.cls' newer than target)...
Build of 'SecondVB.dll' succeeded.
setting binary compatibility...updating references to project...
Processing 'c:\temp\VisBuildPro\VStudio\work\Source\ThirdVB\T hirdVB.vbp'...
setting project compatibility...not building (no changes)...setting binary compatibility...
Processing 'c:\temp\VisBuildPro\VStudio\work\Source\FirstVB\F irstVB.vbp'...
not setting base address (does not apply for project type)...incrementing version...not setting compatibility (does not apply for project type)...building (reference file 'c:\temp\VisBuildPro\VStudio\work\Executables\Seco ndVB.dll' newer than target)...
Build of 'FirstVB.exe' succeeded.
not setting compatibility (does not apply for project type)...
2 of 3 project(s) updated


If the Build VB Projects step is built again (alone), none of the projects are built; if the attrib+modify steps before it are built and then Build VB Projects is built again, both SecondVB and FirstVB are built again.

If you can tweak the sample projects to reproduce the behavior you're seeing, we can take a look at it. Also see this FAQ for some general recommendations on handling VB builds:
http://www.kinook.com/Forum/showthread.php?threadid=57

[gmichaud]

We're still having problems. By looking at the log, it also seems that some projects are not being built in the right order.

Is there a debug/verbose mode to help us diagnose the problem ? Our project group is very very large and the list of references is long, making it difficult for us to make a sample project that shows the problem.

Thank you.

[kinook]

Please put the attached bld file [GetVbgInfo.bld] in the base folder of your source code, and build it with Visual Build Pro. It will add all the *.vbg, *.vbp, and *.bld files into a zip file [saving path info].

Please send the resultant file [SendToKinook.zip] (should be in the same folder as the .bld file), the log output of the failed build to support@kinook.com, indicating which project you believe was built in the wrong order and we'll take a look at it.

Note: if several *.vbg or *.bld files are in SendToKinook.zip, either remove them before sending, or just add a note indicating which files we should evaluate.