Orcas, The Bootstrapper, and Beyond

Well we shipped Visual Studio 2005, I took a little breather, and now I am back in my office thinking “what’s next”.  As much as us here at Microsoft wish we could just go back to working on the next version and making it even better, we are stuck in a waiting game.  What’s next?  What’s the next killer feature to add? 

Unfortunately only you can answer that.  Yes, you.  As we ramp up on our Orcas (the next version of Visual Studio) planning we require a great deal of custom input, in order to make sure we are making products that truely help people.  So what would you like to see the Bootstrapper do that it doesn’t already?  If you have any feedback don’t hesitate to use that contact link!

Currently we are planning on publishing the following packages in an out of band release:

  • Localized versions of the core Bootstrapper packages

  • 64-bit package of the .Net Framework

  • 64-bit package of SQL Server Express

And for Orcas:

  • Unicode support

But the rest is totally up to you.


Comments (4)

  1. Sean Timm says:

    The current deployment strategy of the bootstrapper for ISVs is very cumbersome and seems to be designed with the expectation of in-house deliverables. One of our server products installs with a ClickOnce application. The problem, of course, is that the customer installing the software determines where it actually ends up (ie. which machine name, which virtual directory, etc.). Since the bootstrapper gets compiled with a hardcoded URL, it is immediately pointing at the wrong location.

    I finally tracked down the information on your site regarding changing the URL via a command-line parameter to setup.exe which allowed us to modify our installer to be able to call and change the URL during installation. Unfortunately (as you’ve mentioned previously), it invalidates the authenticode signature, so now anyone that launches the bootstrapper gets a warning. Also, the very *first* time that you run setup.exe and pass it an override, it prompts you with a dialog mentioning the fact that it will remove the signature. I couldn’t find a way to tell it not to show that, so now I can’t even make the bootstrap creation part of our automated build process. I have to manually create the bootstrap, manually run the resultant setup.exe to get it to point to another (bogus) URL (so I can get rid of the dialog prompt), and then we can include this final executable in our install process that we distribute to customers. This is a HUGE HASSLE, and in the long run, it will be more effective for me to roll my own (based on the current bootstrapper implementation).

    It’s always possible that I’ve missed something incredibly obvious about the bootstrapper that makes all my problems disappear, though, so I’m all ears. 🙂

  2. Here’s an idea:

    Get rid of the bootstrapper.

    Work with the Windows Installer team to create a patchable, signable Merge Module system that can be registered on the computer and patched by MS and if signed by MS can distribute files to the System32 folder etc.

    By doing so, we can go back to a bootstrap that does one thing and only one thing: Install the Windows Installer package and then run the setup.msi file and then everything is seamless to the user.

    Any bootstrap on an application is a failure to create a good experience for a customer and Microsoft should feel ashamed that they have forced developers to this point. It is specifically this lack of user friendliness that causes people to ask "Why should I bother with Microsoft when Linux is just as hard to use?"

    Everything should be merge modules that can be added to an installation (including the .NET framework. The only reason that bootstrapping started to happen was because of a failure to plan ahead with merge modules for patching (i.e. Slammer) and the ability of some merge modules to update system files. Fix these issues and we can go back to seamless installs that just work instead of confusing customers. (and get rid of the new DLL hell… just look at trying to uninstall Vs.net 2005 or SQL Server 2005 if you need proof of this one)

  3. ChrSmith says:

    I just wanted to let you all know that I really appreciate your feedback, good and bad. I’ll definitely forward your thoughts onto our PM to do everything I can to get rid of your hassles in Orcas.

    Thanks again,

    -Chris Smith [MSFT]

  4. ShadowChaser says:

    I would like to see a generic "MSBuild" project type in visual studio.

    Right now there is no spot to put generic MSBuild projects – things that don’t fit into the current Visual Studio model. Bootstrapper and WiX projects come to mind.

    It would be great to just have a project type that consists of nothing more than the XML MSBuild project file and some file dependencies added underneath. It would make it a LOT easier to do source control…