Everybody could use a good Burn

Rick Brewster of the Paint.NET team blogged about the pain of getting Paint.NET installed on a system without the .NET Framework. It’s fair to say that for a system running Windows XP without optional updates, installing the latest and greatest Framework is an annoying exercise. Part of the problem (blame) falls on the shoulders of the Framework folks: The Framework installer should install MSI 3.1 for users; asking them to go spelunking on the Microsoft Download Center for the MSI 3.1 redistributable, then run it and reboot, is rude at best.

Rick’s proposed solution for the next release of Paint.NET is OK, though it has the downside of showing several very different UI experiences:

  • A "confirmation" dialog that tells users that prerequisites will be installed.
  • The OS-component update dialog (for MSI 3.1) that most users no longer see, because it’s hidden behind Windows Update.
  • The .NET Framework Client Profile bootstrapper UI, which is slightly different than the OS-component update dialog.
  • The Paint.NET installer configuration UI, which is slightly different than the others.
  • The Paint.NET installer UI itself, which uses MSI basic UI.
  • If needed, a "reboot needed" dialog, which uses slightly different UI.

A key scenario for Burn is to enable this scenario (with the Client Profile or "normal" .NET Framework installation). Part of being successful with that scenario is to have an integrated experience, which means having a consistent user interface and one progress bar.

We’re not there yet, but know that we’re working hard to solve this problem.

8 Replies to “Everybody could use a good Burn”

  1. This is one of my main issues with installation today, a lot of software has a very poor installation experience when compared with say Visual Studio or Office that to a great job of integrating everything. I can’t wait to see what you guys come up with.

    Keep up the good work!

  2. I’d love to have “one progress bar”, but for many reasons my setup wizard is written in C# (it is not MSI basic UI). Thus, it requires that .NET is installed!

    Although if I were charging $500 like Office or Photoshop, you’re darn right I’d have an installer like that 🙂 I like Office 2007’s installer.

    Paint.NET v4’s setup experience, while a bit inconsistent on the UX front, is at least a LOT simpler. And, it works!

  3. Philip,

    That’s definitely our goal!


    Burn is C++, so it can support one progress bar for .NET and a managed app. Our goal is to make that experience available for $499 apps too. 8)

  4. Fairly consistent description with the pain I experience writing .NET apps – including ones distributed on CD.

    The “single progress bar” is a really good point. The original Windows Installer’s design was to have everything “all in one” – merge modules to install OS components, etc.

    Over time, the vision has “eroded”. To work around security issues, merge modules were effectively “dropped” for all but backwards compatibility. Complex systems like .NET had their own isolated installers that couldn’t be chained inside of another MSI.

    Windows Installer 4.5 adds support for external user interfaces. The very fact this was added, in my opinion, means that Microsoft collectively has “given up” on Windows Installer. I realize thats harsh, but lets look at it from the perspective of a setup developer:
    * I can cannot provide a consistent installation experience using MSI
    * I need to resort to additional software to provide the installation experience and chain together multiple installers.
    * If I’m writing lots of extra software by hand, why am I using MSI at all? I now have all of the pain but none of the benefit. I get a few rollbacks, but even that doesn’t work correctly any longer because multiple installations are chained together.

    Take a look at Visual Studio 2008’s installer, or SQL Server’s installers. It literally installs at least 10 different MSI packages to get the program working. Wasn’t the whole vision of Windows Installer that you could have the same reusable components inside multiple installation packages?

    If I need a bootstrapper, the setup technology has failed me. Dependencies for installers are insane – the whole point of an installer is to take care of that for the user. It’s been a “fact of life” for MSI packages since day #1, and I think that people have been so accustomed to it that the “big picture” has been lost. Bootstrappers = Technology Failure!

  5. InstallShield has all of this today, although I do remember reading the description of burn in a previous blog and I believe it has the potential to be better then what InstallShield can do and I always appreciate having an alternative.

    But all of this is way to complicated. I can’t help but wonder if programs like Paint.NET ( kind of a silly user, do users really care that’s it’s coded in .NET or does that imply some web 2.0 type experience? ) wont just end up virtualzing their application with a program like Xenocode or Thinstall and just eliminate the problem all together.

    You’d end up with a simple single EXE that could then so easily be thrown into a WiX project ( think votive, include mondo and define 1 component ) that even I couldn’t complain about the usability.

  6. I think it is fair to say that we developers are used to Visual Studio installs that can last up to 5 hours and that it is not too hard for us to start Task Manager and try convince ourselves that installer is not frozen, that ‘something is still going on’.

    Framework installs look like they were targeted at the same audience. So nobody bothered with the details.

    One progress bar is fine but it doesn’t help if it moves for 3 pixels after half an hour had passed. It is hard to detect that, staring at the screen for half an hour, okay?!

    Fast-flying text with technical goobledy-gook, animation, whatever … just have something that can make a person get the idea that ‘things are going on’, that really ‘some progress was made’ and that ‘she needs to wait a bit more’, in no uncertain terms.

    If experienced developers find themeslevs wondering whether to reboot the machine and start the installation over, what do you think users ponder on in the same situation?

  7. Eric,

    good points! I think that MSI technology is mostly a failure even if you consider just a single (nontrivial) program and single MSI installation. WiX project is probably the best thing that happened to it to keep it alive. So thanks to Bob and others on WiX team!

    Adding features, like GUI dialog initialization Custom Actions, would have helped a lot if it was implemented in MSI, say 4-5 years ago.

    On the other hand, the need for Custom Actions that are not related to GUI should have been reduced. Why is it that I can’t invoke a standard action more than once? For example first time to act on Table1 and second time on Table2. Why I can’t make it act on some rows of the table first time and on other columns on second invocation?

    Something along these lines would have hugely reduced the need for CAs since standard actions provide most of the functionality needed but are just not flexible enough regarding when they get invoked and on which items they act.

    Indeed, as you say, after a while one starts wondering why use MSI at all.

Comments are closed.