MS setups – inconsistent?

I received this question in response to my introductory blog entry - "Why are MS Installer all so different, why do many of them have problems with unattended installation - and why do they sometimes need a user logged on?"

These are all really good questions and ones that I have asked myself many times since I've been working at Microsoft.  The fact that setups produced within Microsoft are so inconsistent is one of my pet peeves. It seems like there isn't an established standard for how to create a good or well-behaved MSI setup, even within Microsoft. For example, a lot of the stuff we learned on the setup team I worked on came from feedback for our released products. Visual Studio 2002 was the first version of VS to use MSI, and we missed some key scenarios - specifically related to Active Directory and other types of unattended deployment.

So, to answer these questions based on my experiences so far - I believe it is because so many teams are creating their own setups from scratch that leads to some differences in look-and-feel and functionality. Unattended installation is too often left until the end in product design and testing and not enough focus is put on deployment scenarios. This is not true across the board, some of our products do a really good job addressing these scenarios I think, but many do not.

Requiring a logged on user is very dependent on what the setup itself is trying to do to configure the product it is installing. There are cases where some level of elevated privileges are needed, but there are also cases where it is enforced by a setup but not truly needed and it just happened to be easier to author the setup that way.

Hope this helps....and thank you for the question and interest.

Comments (3)

  1. Rolando says:

    thanks for sharing your experience, I also would like to know if you (Microsoft) are doing something about this problem ?

  2. Anon says:

    What I would like to know is how Microsoft is going to help developers with building installs that need to configure other Microsoft products. For instance developing an install that has to create a database on an SQL Server. Now that is fun and I am sure everyone that has to do this has their own custom solution to solve this. Why can’t SQL Server output something that an MSI builder can use to install and create a database? Oh yea and correctly setup user permissions 🙂

  3. Kevin says:

    Anon, if you look at WiX, I think it actually has a built in custom action that will run code on a SQL Server. Not sure if this is what you were looking for, but this might help.

Skip to main content