Breaking another rule costs me

Here is another one of those rules I have learned the hard way:

Never test install your application installer on your development machine.

Why? Many moons ago I did test one of my install packages on my development machine and then promptly tested the uninstaller. Testing the uninstall is not something I find many developers doing because most do not think their clients will uninstall the app or would prefer they never uninstall the app. Well I prefer a clean Add/Remove Program list on my test machine so I always uninstall right after I install just to make sure it works.

So Monday I was writing up some instructions for the latest install I shipped and needed some screen shots for the documentation. I was out of the office when I was writing the steps so I decided to run the install on my development machine. I needed screen shots for the last step (the progress thermometer) and the "you are done screen". I finished the documentation late Monday night.

The install had a couple of OCX files, which are registered without merge modules (not my favorite way to do things). Do you know what happens when you uninstall an application with OCX files? Well they get unregistered. This is not a big deal unless you use them somewhere else. {g}

Forward to today. I am in a rush. One of my clients needs a new application before Friday. It is a small application and figure I can squeak it out in between the other three projects I am working on this week (which might explain why I have not blogged at all in the last week). So I crank open my friendly Visual FoxExpress Project Wizard to start this new project this evening and I get a crash!

OLE error code 0x80040154: Class not registered.

OK, lets see, what has changed in the last 48 hours? That's right, Mike and Toni pulled their traditional Friday the 13th release last Friday and I updated last night. Great! So I try to put together the reproducible steps to the crash to help the Feltman's debug the problem. I reverse out the update and it still crashes. I dig in to the debugger and try to find the code that is troubled. The code is very straightforward and points me to the class and the class library which cannot be instantiated. This is where it really gets interesting.

I fire up the trusty Class Browser to look at the class and see what object is in the class and firing the OLE error. The Class Browser chokes on the same darn error. Uh-oh.

Then it hits me, I violated another cardinal rule of development on Monday and now I have just wasted 45 minutes tracking down a problem that I never should have hit. Stupid me. I could have simply used a VirtualPC session, but I was not near my external hard drive where I have the virtual machines stored.

So I have decided to fine myself for this rule violation, and added this problem into my personnel file so I can include it on my next review.

I hope you can learn from my mistakes. I hope you can avoid this problem and not waste time chasing problems that never should happen in the first place. OK, back to work.