Last time I talked about what the bootstrapper is and what goals it's trying to accomplish. This time, I'll go into other bootstrapper features we have planned that make it a pretty cool deployment technology. I was going to go into detail about the contents of the XML files that make up a bootstrapper package but the formats have changed quite a bit since the PDC release and it wouldn't help anyone for me to describe formats that are just going to change on you. Now that you have the Community Preview version, I'll go into some more detail about the XML next time. For now, let talk a little higher level.

Conditional Installs When you define a package, you determine under what conditions it will be installed. For example, the J# redist requires the .Net framework to be installed so you would put a condition in the package XML to stating "if the .Net framework reg key isn't there, fail this install." You can have bypass conditions as well; the .Net framework would check to see if the version of .Net contained in the bootstrapper is already installed. If it is, then that component doesn't need to be installed. Checks can look at registry keys, MSI product codes, or be external exe's that can do what ever you want. When the end user runs the bootstrapper, the only components that get installed are those that user needs. One installer is needed for all consumers; no more separate installers for people with the framework or without. Also, if the bootstrapper determines that the user needs none of it's components, they never even see it. The MSI or ClickOnce app starts up right away as if the user ran it directly. Pretty cool.

Download on demand The bootstrapper's smart. When you run it from the web or a UNC share, only the exe is copied down to run. After running it's checks, the bootstrapper knows what components need to get installed. Since they are not bundled in the bootstrapper and are loose files on disk, the initial download is small: just the engine (which contains all the data the bootstrapper was built with and any external check exe's embedded inside). Once it has a list of components to install, it downloads them from the origin site. It only downloads those packages that need to be installed. Some users already have the .Net framework? The bootstrapper saves them a 20 or so meg download and gets them running your app that much faster. And they don't even need to know if they have the framework; the same bootstrapper works for all users and just does exactly what it needs to, nothing more nothing less.

EULAs Got a component that is redist-able but requires the user's to accept a licence agreement? No problem! You can configure your packages to present EULA's as plain text files and the bootstrapper will show them to the user for acceptance before the install. Got a couple components with the same agreement (we do: dotnetfx, MDAC, etc.)? The bootstrapper detects this and aggregates them together so the user only sees each agreement once. Easy for you and easy for your user. Not only are you deploying easily and efficiently you're legal too :)

As always, this is just what we have planned. Things change before products are release so by the time you get the final version features may have come and gone.