Most people don't write every single piece of their app. Programs are linked together with shared libraries so that we can share functionality. Of course, we have to actually share these libraries for this to work. With .Net and COM components, this usually meant running a bunch of installers on all of your client machines to install the .Net runtime, insert assemblies into the GAC, push out policy, register COM components, etc. This was a deployment nightmare and VS didn't help you that much. Sure you could package your .Net app in an MSI pretty easily and we'd bootstrap the MSI runtime but that's not enough. MSM's for the framework were considered but they pose a servicing nightmare (the topic of a future post to be sure). So we created the "mondo" MSM that is simply a file list of the stuff in the .Net framework so we could detect your .Net application's framework dependencies (System.dll, Microsoft.VisualBasic.dll, etc.) and not deploy them but you couldn't use this to deploy anything and we had no story at all for other installers.

Fast forward to today. We now have the 2k3 bootstrapper on MSDN that lets you bootstrap the .Net runtime and MDAC along with your VS Setup project. This is a great step in the right direction: to all those developers writing simpler .Net apps or purely isolated programs they now have the solution they need. Unfortunatly, this doesn't cover people who work with the existing components mentioned above. These people need more than just XCopy deployment: they have their own dotnetfx.exe style redists. So these guys are still in the same boat as they were back before this package was released. They can get the framework on the machines easier but they still have to run a bunch of other installs before their app will install and run.

In Whidbey, we have a solution. Enter the Generic Bootstrapper.

The generic bootstrapper is simply an unmanaged app that will run an arbitrary number of redists based on conditions users specify then run a final "app" install (be it a ClickOnce deployment manifest that will ultimately run the application or an MSI from a setup and deployment project which will install the app but not run it). It is purely data-driven and customizable. All a user has to do to get the bootstrapper to run their package is to author a few XML files and then build the bootstrapper and include your new custom package. So lets dig in a see what it takes to make a bootstrapper. [Note: the format, layout, names and function of these files is subject to change before final release. Look on these are more of a conceptual explanation rather than a exacting technical one. Expect a more thorough, technical description during the Beta's and after release]

Under your VS install there is a packages directory. Each sub directory under that represents a package. VS will come with some core packages like Windows installer (instmsi), the .Net Framework (dotnetfx), MDAC, etc. Each of those has a product.xml file inside that directory along with any culture-neutral package files (more on those in a bit). Also there is a subdirectory for each locale the package has been localized to (such as en, ja, etc.) and each of those has a package.xml file and any locale specific files. The tree looks like this:

packages\    
   dotnetfx\       
       en\
         package.xml
         dotnetfx.exe
      product.xml
      dotnet_chk.exe
   instmsi\
      en\
         package.xml
         instmsia.exe
         instmisw.exe
      product.xml
   mypackage\
      en\
         package.xml
         english.exe
      ja\          
         package.xml          
         japanese.exe       
      product.xml       
      neutral.exe

Each of these is picked up by VS and in your Publish property page they'll be an option to edit your bootstrapper settings. There you can pick the packages to include and tweak a few other settings. Don't feel left out MSI users! Setup and Deployment projects build bootstrappers too! The UI is exactly the same and you get the same bootstrapper out except that instead of executing the ClickOnce manifest at the end it runs your MSI.

Next up: What's in those XML files, different bootstrapper modes (Web vs. Local) and more!

(EDIT: Well that's what I get for trying to post with w.bloggar. Formatting should be right now)