If my installer… had a brain…

Recently, I was evaluating obfuscators for Moon River Milestones, and after going through all of the motions, I finally settled on one. Now, being as tight with money as I am these days, not to mention the massive costs I’ve incurred while starting up my business, I decided that I’d wait a little while before I bought it so I could decide on an installer to use as well.

So Thursday afternoon, I pulled out the Moon River Software credit card, and proceeded to spend a few thousand dollars. This software isn’t exactly cheap, which makes the evaluation process that much more important. After all was said and done, I laid out nearly $3,500. Unfortunately, not everyone is up on the times about ordering things on the internet and instant gratification. So, I had to wait until Friday afternoon somewhere around 7pm EST before I finally got all of the software I ordered.

So, back in the bat-cave I’ve spent the last two days trying to get my build environment fully automated. The ultimate goal was to have a single script that I fire off, and when it’s finished, I get a shiny new msi package which I can install and it will work, everyone will be happy, and the Wicked Witch of the West melts into a puddle. Or at least that was the plan.

Let me back up to the beginning so I can explain why all of this was necessary. When I was evaluating the installers, I decided that I liked the Wise for Windows installer the best. It seemed to have great support for web applications, could integrate very easily with Microsoft SQL Server, and it was very easy to learn. The problem that I ran into was that I wanted the user to be able to select the SQL Server database to install Moon River Milestones to. I know that some people have naming conventions they want to follow and I wanted to provide them with the flexibility to do what they wanted. But the installer was giving me the same problems I ran into back when I did my evaluation.

The Wise for Windows (WfW) has the ability to do find and replace on text strings, which seemed to work well enough during my evaluation. I ran into a problem where it stopped working entirely at one point, and after contacting support, and wasting well over 25 hours of time on it, I tried recreating my project. Everything seemed just peachy. I still had to do some work to create the custom dialog boxes which let people type the name of their database, but I decided to leave well enough alone. Support confirmed that there seemed to be some sort of problem, but they weren’t able to duplicate it. Other people had workarounds that also involved recreating their projects. I certainly didn’t want to have to recreate my project every time I wanted to make a minor change, but luckily I have something better. Source control. I have all of my code backed up in Vault, which is an incredibly great source control tool from Source Gear.

So, I had purchased WfW, and now needed to make the aforementioned changes. I had received my license for the obfuscator on Thursday night, and tried installing it on my build machine. Insert barf noises here. My build machine choked on it, and hard. The installation instructions clearly state to uninstall the evaluation version before installing the full version. Every time I tried though, it choked and died on me. Since it was integrated with Visual Studio, it fired up four separate msiexec.exe files. FOUR of them! And it still couldn’t uninstall properly.

Finally, I decided to do a repair, and it seemed to work ok. My build machine is a VMWare image, so taking snapshots isn’t a big deal for me. Speaking of which, VMWare has a great deal going. It’s called a VMWare Technology Network subscription, or VMTN for short. It gives you access to VMWare Workstation, GSX Server, ESX Server, Virtual SMP, and P2V Assistant, all for under $300. Talk about a sweet bargain. The lone caveat is that you can’t use any of the software for production use. It’s all for development use only, and you must have a VMTN license for each developer. You also can’t give demos to clients using any of the software, but since I’m just using it for development, it works out great for me.

So, with my VMWare image loaded with my obfuscator, and my new installer, I started pulling all the final pieces together for my automation. But I ran into my arch-nemesis again. The replacement feature stopped working. I spent most of Saturday trying to figure this out. Most of Sunday as well. I’d previously spent 25 hours on this one problem, so I’ve probably logged 35-40 hours for this one problem. To be specific, there’s a replace function that sets the name of the database the user wants to install to. Having had my share of problems with the obfuscator, and seen the sort of problems that installations can cause, I wanted to make sure that the user got everything right on the first try.

The installer is the first thing the customer is going to run when they download your product. They’ve already paid for it, but you want their experience to be as painless as possible. The very reason they bought your software is because they have a problem they need to solve. So, do everyone a favor and make sure your installer works, and test it as many times as you can, and in as many different situations as possible. Your customers don’t want any surprises, and neither do you.

So, after flipping through countless menus, and attempting numerous times to get the damned SQL code to execute properly, I finally noticed a seemingly innoccuous dialog box under the files I was installing. Notice anything?

I did too. ‘Read Only’. On a hunch, I did some experiments. It turns out that the WfW Installer copies all of the files to the target machine (even the temporary ones) with the same properties you have on your machine. And since I’m using mutually exclusive mode in Vault, my sql files were also being created as Read Only on the target machine. The replace function was failing because the installer does post-processing on the files!!

My guess is that it’s relatively simple to write out the file, and then search through the text for certain strings, as opposed to extracting the file into memory and then searching for strings to replace before writing them out. But I swear if the developer who made that decision was within arms reach when I finally realized that, I’d probably still be choking his lifeless body. So, I made a few changes, and everything seems to work fine now.

I had been hoping to do a full launch of Moon River Milestones as of Monday morning this week, but that’s simply not going to happen now. I’m so close to being completely done that I can taste it. No, I think that’s peanuts and beer. But it’s 5 minutes past midnight, and I’ve got a long day ahead of me tomorrow. Customer demos and such. You understand. So, I’m still working on the final details of the launch, but it is certainly within arms reach. Within the next few days, you’ll be able to see Moon River Milestones in all its glory.

And then the real work begins.