VB6: build project and re-build referenced projects when needed

[Alexey]

Suppose we have a VBP-file (Standard EXE, for example) with several references: some pointing to ready-made components (e.g. MSCOMCT2.OCX etc) and some - to "self-made" components whose VB-sources (and binaries as well) are stored somewhere on the hard disk (and in VSS too). Suppose I make changes in source code of such "self-made" component (ActiveX DLL, for example) and perform its check-in to VSS, but do not compile the DLL-file. Then I perform "Make VB6" action for the EXE-project. It will just compile its own EXE because it doesn't know about the necessity to recompile the referenced DLL (whose code has recently changed).

My question is: how can I make the EXE compilation step become more "intelligent" and understand that the referenced DLL needs to be rebuilt? is VBG the only way-out?

[kinook]

The best choice it to use a VBG (necessary if building w/ no compatibility, and preferable in all cases since VBP will determine the proper build order based on references within the group).

[Alexey]

Thanks, I'm just testing "intelligent building" with VBGs. And I found one situation which is not very nice:

I got one "Standard EXE" project (frmMain form inside) and one "ActiveX Control" project (MyTestControl inside); projects are also organized in a group (VBG). The second project is compiled and MyTestControl is placed on frmMain in the first project. After that I open the "ActiveX Control" project, forcedly change "Binary compatibility" to "No compatibility" and recompile it. Of course this rezults in a component with different GUID, and so my "Standard EXE" project can't open anymore - an error occurs: "Component '***.ocx' or one of its dependencies not correctly registered: a file is missing or invalid".

I thought that when in such situation I perform "Make VB6" action for the VBG-file, your program will notice the GUID problem and will update "Standard EXE" project (VBP- and FRM-files) and then recompile it. But nothing happened! Is this the expected behavior of your program?

PS: I'm using workaround suggested by You in http://www.kinook.com/Forum/showthre...threadid=1571. If in both "Make VB6" actions I set "Force a build of all projects", building of EXE-project fails with error «'D:\...\***.ocx' could not be loaded». So, as far as I understand, your program treats DLLs and OCXs in different manner: in case of DLL compatibility problems your program solves these problems easily, and I can't say the same regarding OCXs.

[Alexey]

Still waiting for any comments...

[kinook]

Fixing up of OCX references is also supported (demonstrated in the VStudio.bld sample). Please ZIP and send or post:

1) the info from Help | About | Install Info
2) the .bld file used to build
3) a build log file
4) a reproducible test case (VBG+VBPs+source)

[Alexey]

The info from Help | About | Install Info and the build log output are inside the Info.txt file. All sources are inside VBuildTestProjects.zip. BLD-file is MyTest.bld. As far as it uses "custom action" steps, I also enclose file ICustomAction Test.zip, containing ACTION-file and ActiveX DLL source as well (because Action Type is COM Component).

All the files mentioned above are packed into one file - IntelligentBuilding.zip.

To reproduce my situation exactly as it was, first make everything work by re-positioning VBuildTest_OCX control on the frmMain form (currently binary compatibility is broken). Then close the EXE-project, open the OCX-project, set compatibility to "No compatibility" and compile it again. And then try to build VBG.

[kinook]

Once I got things into a buildable state, building with no compatibility works fine in my tests. I've attached a .ZIP file that you can extract and build to test. It first registers the DLL/OCXs, then does a force build without changing compatibility, another with no compatibility, and again without changing compatibility.

Also, FYI: the build rule you had on the second Make VB6 step should be either

[%LASTSTEP_STATUS%<>0] is true

or

%LASTSTEP_STATUS% is not equal to 0