The Ever Changing Process of Building Processes

So I've been spending the past few days updating the build processes for all the software I've been working on. The problem is that, while I'm not the first person to ever have to build installers for commercial components using the deployment tools in VS.NET, I'm the only one willing to talk about it. Several searches on Google for information on nuances like what an “Environment String Value” is in the Registry Editor have turned up utterly fruitless.

Further, I discovered that my previous method of organizing my builds was shoddy at best. Before, I would have a “3300“ or a “5000“ folder in the “bin“ folder of my project. This caused problems for my GenX.NET installer, because I was accidentally pulling assemblies from 2 different locations. It turns out my embedded trial license wasn't getting called, because the version installed to the GAC had it, and the version in the installation directory (which is what gets called from the “Add References“ tab) didn't..

This just plain sucked, and I got tired of dealing with it. I now have a separate folder on my hard drive called “Builds“, which then has a hierarchical structure very similar to my Workspaces structure, where each different AssemblyFileVersion has a new folder, with the Framework-specific compiles in separate directories.

I've also had such a horrible time with the Installer creation experience, that my next project after Version Commander is released will more than likely be to create a templated-based Wizard for designing *.vdproj files. Fortunately, I've been campaigning inside Microsoft to improve this experience in Whidbey, so hopefully it will be much better by then.

And since no one is willing to talk about how Build Environment Best Practices for VS.NET Component Developers, I'm going to write a whitepaper on it. I shouldn't be having to figure this stuff out for myself, but since I did, I might as well help others going through the same thing. I could have had ScrollingGrid out on Tuesday if I hadn't been experimenting with what methods would work best for this and future server controls.

Well, now that I have everything figured out, after I get the ScrollingGrid installer finished, I'll be experimenting with Merge Modules (another apparent industry secret), and put up the new installer for the new version of GenX.NET. I figured out that I CAN install my ASP.NET Sample Application after all, if I have a separate samples MSM and include it in the main installer. It's a really stupid workaround, but it works. I still can't have all this other stuff though.

Microsoft does such a great job with every other aspect of VS.NET, but here's where they drop the ball: The deployment story is horrible. I no longer wonder why there aren't more smaller ISVs building complete, quality controls. There are too many barriers to finishing the 18 other steps that need to take place after the code goes gold. Stuff like Integrated Help, Deployment, Documentation.... all are so difficult that I'm sure many just give up. I don't scare off so easily.

2 Comments

  • MSMs are actually pretty easy to deal with, albeit I've never tried to use one in VS' installer wizmo. I think the issue is that if VS could build the best MSI out there, then InstallShield and Wise would have issues - Installshield and Wise make great stuff, I use Installshield stuff every single day.

  • Yeah, but Brian you have a fairly wealthy school district's budget behind you. I don't want VS to be the best MSI builder out there. I just don't want it to be handicapped because there are ISVs that make a product too. If that is Microsoft's justification for crippling it's deployment capabilities, then MS better come up with another answer.

Comments have been disabled for this content.