No Long Days

This week I have been tasked with creating an automated build script for one of our legacy Visual Basic 6 applications and putting it under CI.

I planned to use our current build server which is a Xenon 3Ghz machine that currently builds our .Net/VB6 combo projects. It is pretty fast so it works well. The current build is done on an old Dell workstation running Windows 2000 and an old Pentium CPU.

This legacy application has been around for quite a while and uses several 3rd party components like True Grid, Sheridan Data Widgets, BeCubed OLE tools and various other .ocx files... as any good VB project from 1996 is wont to do.

In order to make the build portable the plan was to put the third party .OCX and .DLL files into our svn project which is pretty much a best practice these days. For those that are spoiled with .Net these days you need the OCX to be on the PC and registered to build.

As I started running the compile and working on resolving the missing references copying them from the current PC used to do manual builds I had trouble with it recognizing the components. It started with True Grid 7. The .ocx reported that is was successfully registered when using regsvr32. However, the compile still told me the component was missing. I search the registry and the .ocx was listed in ClassIDs section. But upon comparing the classid in the VBP with the classid in the registry is was 1 digit off.

So, I installed the project on a VM to see what was up. I of course had to dig out the original CD key to do this. After the install I saw that the installed version had a TypeLib key with a value of the classid that was in the .vbp. Apparently the type lib in the .ocx was obscured so this control would not work. So, I added the typelib key to my build machine and tried again. Now I get an error that the .ocx could not load... at least the missing reference message was gone. So, I installed the product on the build server to resolve this.

Next. Yes, the Sheridan data widget gives me an "eval only" message which I try to build a project that uses it. WTF!

As the Principal Architect of my division I am the person that tests and evaluates third party tools prior to purchase. From now on, if your tool has DRM it goes to the bottom of the list. If I am between two tools the clear choice will be the one without DRM.

NO DRM is best. No license file/install needed to build/compile not as good but better than nothing. DRM to just compile when the component is referenced, NO WAY.

The irony here is that I was able to find cracked versions of these files on the internet. No, I didn't use them. But, the point is that DRM only affects your paying customers and does NOT stop theft.

Join me in giving preference to vendors that provide tools that do not EXPECT that you are a criminal.