|
Daily Builds Are Your Friend
or so I'm told...
But exactly _how_ do you implement this? I have spent a little time lately trying to implement what I call 'Buildomaton', have finnished 80% of the coding work and will probably rewrite:
Scenario:
---------
* lot's of VB code
* VSS contains all projects
* project $/_Reusability contains modules used in 80% of the projects. These library modules are getting bigger and bigger as new functions get added (blah, blah)
Solution (so far):
------------------
* VBScript to get all projects from VSS, compile them (optionaly executing 'BeforeBuild.bat', 'BuildMe.bat' and 'AfterBuild.bat' if defined in project) and send error text to mail recipients.
(this actually works! But getting dependencies right was harder than I thought - but now I'm sure my projects will build on someone elses machine as well)
Solution (planned):
-------------------
* Start a VMWare instance automatically at lunch time which does the build.
* have yet to figure out how to start the script.
Problems:
---------
* VBScript was hell to do scripting in (even though I know VB6 well)
* non-standard: will have to document Buildomaton for my collegues
* how to extend it to build other project types as well (--> 'BuildMe.bat')
I was wondering if there is a (free) tool to do this all. Yes, I _do_ know of make. Yes, I _have_ implemented this in make before. BUT: make is rather hard to understand, unless you like declarative style programming - something I don't expect all (future) coworkers to enjoy.
I wonder if I can get away with rewriting the Buildomaton in Python, replacing the *.bat files with *.py files?
What other solutions are there out there?
Daren Thomas
Thursday, January 15, 2004
The new "classic" tools for making build scripts are either Ant for Java or its MS world cousin NAnt.
I have found Ant to be a convenient tool for scripting the various steps needed during a build; i.e. getting sources from your source control system, compiling, creating custom files, deploying, running custom tools. There are lots of built in commands that are made for all of these tasks, and writing your own task is also quite simple.
As an aside, were you able to solve the problem of an unattended build of VB6 where you want to break binary compatibility for some ActiveX component? I been wracking my brains on this problem for over a month but can't find a way. It seems that the only way to break compatability is when building from inside the IDE and agreeing to break the compatibility (by pressing buttons) whenever asked if this is what you want to do.
ICBW
Thursday, January 15, 2004
If you're breaking compatibility then lifes a bitch anyway.
VB doesn't do this well. Historically I would recommend creating a seperate interface which you then implement against. i.e.
Class CSalesOrder Implements ISalesOrder,IOrder,IOrder2
You then write code of this form:
Dim ThisOrder as ISalesOrder
Set ThisOrder=CreateObject("MyThing.CSalesOrder")
Which means you never have to turn on binary compatibility ever, just add another interface via a TLB.
To create easy interfaces for VB use, Write them as normal in VB. Register them, get the "IDL" by using OleView, compile with midl and out pops a TLB.
DO NOT DO THIS IF YOU WANT TO USE VBSCRIPT
VBScript has no easy way to get to secondary interfaces.
You can kludge this with a freebie DLL but I wouldn't recommend it.
Peter Ibbotson
Thursday, January 15, 2004
ICBW,
Write a program that pre-processes your VBP. Change the CompatibleMode value to 0. This should build your dll with no compatibility assumed.
Rick Childress
Thursday, January 15, 2004
Peter:
I have joined a group of developers that have been working with "binary compatibility" for a long while and have great resistance to changing, even though the binary compatibility is not doing them any good. I tried in the past to get them off of it (at least until we make a release to the customer!) but couldn't get them to agree. Another not insignificant problem is that compiling with project or no compatibility on the project causes VB6.EXE to crash. Every time. If you have any suggestions on that score that would be nice too... :-)
Rick:
If I do that, I will get a different GUID for my typelib. When "breaking compatibility" during compilation, the typelib keeps the same GUID and increments the version; so the results are very different. Also note what I wrote above about the frigging VB6.EXE crashing when I try to remove compatibility.
Additional suggestions would be very welcome!
ICBW
Thursday, January 15, 2004
Save the binary dll used as a master for binary compatibility to VSS and ask developers to update it when they break the compatibility. Make a clean build (delete the previous folder completely and don't forget to unregister all dlls before that). Since all required information is in VSS and up to date the build should be fine.
coresi
Thursday, January 15, 2004
I assume you have a dedicated Build Machine. You probably should also store Ghost images of the environment and from time to time wipe the machine to make sure you know of all the components required to build.
pdq
Thursday, January 15, 2004
ICHB, that's what project compatibility is for. It will keep the GUID for the type library.
Anon
Saturday, January 17, 2004
coresi:
That is what I have now. My main problem is that I haven't been able to convince the other developers to always compile a dll after breaking compatibility, so the build often doesn't work.
Anon:
I know. That is what I want to happen, which is why I don't want to change the CompatibleMode value to 0.
ICBW
Sunday, January 18, 2004
If, through regex, you turn off binary compatibility in the vbp, you thereafter get a new set of typelibs each time you build. We have a huge VB6 app - so after about 3 weeks, the registry runs out of room and the machine kinda stops.
There seems to be no way of pre-disposing VB6 to ignore it (and use the same typelib references).
Any body got some bright ideas?
VB6 sceptic
Monday, February 23, 2004
 Recent Topics
Fog Creek Home
| 
