|
Hi Kevin
Thanks for that feedback, it was very helpful. Let me explain my difficulties here.
The system that we are talking about here is a production system worked on by a team of developers, so we cannot consider using project compatibility. Our system here has nearly 90 individual modules and many of these reference the DLL's/Ocx's which are in the build so we cannot "muck about" with the interface GUIDS or the whole thing falls apart. The order of compiles within the build is absolutely critical.
So, I have all the compiles done with binary compatibility. When a code change causes binary compatibility to be broken then my subroutine compiles with no compatibility. This is followed by a custom action step which works out the GUID of this new compiled DLL or OCX then updates all 90 of the VB Project files to set the reference to this new GUID (after an Unregister step before the compile and a Register step after it). This is all neccessary to keep the registry form filling up with rubbish,
I want the the build to stop only when one of the compiles fails because of (say) a syntax error, otherwise I want the whole thing to happen automatically (which was the business case for buying the licence).
Is there an in-built way that VBP could handle this?
In relation to your comment about logging, yes VBP does log but there is so much stuff in the log that the key events can be difficult to see so I've included extra "Log Event" steps to make it easier to read. Is there any way to reduce the "verbosity" of the log?
Cheers
Sam
|