Take the Windows Application Platform Team survey

Hey all,

The Windows engineering teams are putting together plans for how application installation and servicing will work in future versions of the operating system. We would like to take this opportunity to hear from you to better understand your current pain points and needs going forward.

We have put together a survey to collect your valuable feedback. We hope you will take this opportunity to tell Microsoft what you feel are the needs and priorities to take into consideration to improve the overall application setup & deployment experience.


Windows Application Platform team

[Author: Zainab Hakim]
This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.

Comments (11)

  1. No one of consequence says:

    Hm…there was nowhere on the survey to say, "Microsoft’s Windows Installer technology is insanely complicated, over-architected, under-documented, under-supported, prone to incomprehensible and unrepairable failures, and a huge step backwards compared to, say, OS X application bundles, or even xcopy." So I’ll say it here.

    Question: if an .msi file is a database, why can’t I open it with Access? Or SQL Server?

    Question: what was so wrong with dialog boxes written as .rc files and compiled into .dll files, that Microsoft had to reinvent the wheel (badly) by cramming dialog box definitions into database tables?

    Question: It’s been, what, twenty years since Microsoft shipped an operating system that *didn’t* support long file names, so why does everyone creating an MSI installer have to specify 8.3 aliases for installed files?

    I tried to use MSI, and WiX. Now I use InnoSetup, and life is good.

  2. Mike Diack says:

    While I agree .msi is difficult, I have to take issue. Long filename support only appeared in NT 3.1 /Win 95 (1993/5 respectively)


  3. Bryan says:

    Q1:  Why can’t I open an Oracle Database with Access?

    Q2:  Not every setup developer has resources to compile DLLs.  MSI Supports that anyway through external UI handlers.

    Q3:  You don’t, but more specifically, why not?  It doesn’t hurt anyone.


  5. ZippyV says:

    – Why were all the questions from the survey asked twice?

    – Why is the Windows Installer team not providing a decent installation editor for creating installer packages? Orca is not a solution, Visual Studio’s Installer project has still the basic functionality since the first release of the installer plugin for Visual Interdev 6.0 and Wix is still in beta if you want the latest features of msi.

    – Why did I still see the suggestion (during the pdc talk) to create a setup.exe?

  6. You've probably already seen this , but in case you haven't: Microsoft is currently running a

  7. Vadim Rapp says:

    Three suggestions:

    1. (quite specific): teach windows installer to support xml files on per-setting basis, same as .ini files. This is long, long overdue.

    2. Microsoft might want to promote good practices in creating installations, same as it promotes development in Visual Studio. While there are huge efforts advertising new features for developers, conferences, seminars, webcasts, etc., etc., the activities related to authoring installations are close to non-existing. Meanwhile, according to IBM research, 30% of support calls are attributed to issues that could be avoided by good installation.

    3. And speaking of (2), it would be not bad if Microsoft itself showed an example of professional usage of Installer technology. So far, it has been showing exactly the opposite – which is obvious to anybody who knows how to look inside of an MSI package, not to mention to validate it. The insane setup of Office 2007 is probably the most notable example, when there’s no day on installation-related forums that yet another pure soul is not asking how the heck can this be deployed, and the answer is in pointing to several not exactly trivial articles in MSKB each many pages long. Or look at all these mutually incompatible dotnet frameworks, where each one has cleanup utility and cleanup MSKB article explaining how to clean up the mess left behind – after successful uninstallation, it should be noted. Now practically every major product has its own cleanup article(s) and utility – sql server, visual studio, you name it. It would be not bad if Microsoft showed the example not only by creating installation standards (ICE validation) but actually enforcing them first in their own installations.

  8. Edward Tippelt says:

    1. When will Microsoft implement conditional installation of advertised shortcuts? It is incredibly awkward to provide users with conditional desktop and quicklaunch shortcuts without resorting to custom actions or non-advertised shortcuts. This is a basic requirement which no-one seems to think about.

    2. Permissioning of files is a nightmare – the Lockpermissions table is the most user-hostile experience I know. The windows installer 5.0 addition of SDDL support looks like an attempt to address this, but what about support for Active Directory group names?

    3. More documentation is required on coding MSI installations for more secure operating systemss such as Vista and Windows 7. Each one brings with it a new experience when it comes to working with the UAC, or requiring code signed drivers. Some detailed worked examples would help – and not 6 months after the O/S goes RTM, but during the beta phase.

    4. Some documented sample code for creating custom action DLLs using the Express Version of Visual C++, maintained in line with new releases of VC++ Express, would again help developers create more reliable packages.

    5. Some new tools to supplement ORCA which provide ICE resolution would be welcomed with open arms by the packaging community.

    6. Installation and removal of assemblies and management within the different releases of the dotnet framework needs to be seriously improved. If MSI is intended to be a serious installation methodology then it should not require extensive additional coding to make it work properly.

    7. Windows Installer was clearly designed on a Friday afternoon after a lengthy lunch of beer and pizza, as a convoluted practical joke. Now that we are all stuck with it, I would like to think that the team developing it is not doing it under similar circumstances.

  9. Vadim Rapp says:

    Ed’s #7 is most obviously evidenced by the contents of Installer’s log file. I remember during the beta of 4.5 I even posted a bug with the example of the log of some managed advertising installation, as I recall, that did not say what was being installed, why was it being installed, for what purpose, and what was the result.

  10. Dick Mincher says:

    I am running Vista 64 (SP1) and have been plagued by the 1719 error.  Lots of people seem to be having this problem and Microsoft doesn’t seem to be addressing it.  I see proported fixes for XP, but none of them work for me on Vista 64.

    I refuse to believe that re-installing Vista is the only solution.  Can someone tell me how to fix this?  I’ve tried upgrading to 4.5 and still have the same problem.  Help!

Skip to main content