Last week at Microsoft’s Global MVP Summit I had the opportunity to sit down with the MSI and WiX teams. It was great to meet all these Windows Installer experts and we had some interesting discussions. With me I had some questions from readers of my blog and visitors of my web site, and the MSI team was kind enough to answer them, as below. I want to thank everyone who took the time to meet with me – it was a great experience.
Only some of the people I met:
Zainab Hakim (program manager for Windows Installer), Hemchander "Hem" Sannidhanam (Dev lead for Windows Installer), Bob Arnson (WiX project admin), Ashish Awasthi (developer on the MSI team), Rob Mensching (WiX project admin), Mark Rovetta (documentation writer for Windows Installer)
Answers to your Questions
Please note that some questions were sent to me in German so I translated them to English. I also slightly shortened or re-worded some of the questions.
Question from David: Our problem is basically a componentization problem, and the very, very limited ability to return information from an MSI install. In our case, we chain a number of 3rd-party MSIs into our install. What we would like to be able to do is have custom return codes for msiexec so that we can communicate to our distribution mechanism that the overall install succeeded, but that a particular component package failed. (InstallShield gave us a custom fix that allows error return codes to be ignored for chained .msi packages). Ideally, this could be something like an extra column the Error table, and an option indicating whether that error is a terminating condition or not.
Answer from the MSI Team: Like you already mentioned, handling the exit codes from msiexec.exe would actually be a functionality of the chainer. To get the exact error codes you could use a chainer with external UI, which would receive the error messages via its callback function.
Question from Colby: When will the MSI team add support for managed code custom actions (similar to the WiX DTF extensions)?
Answer from the MSI Team: DTF is a great solution for this purpose. Like every company, the MSI team at Microsoft doesn’t have unlimited resources and therefore has to set priorities. We work to improve and advance the platform instead of duplicating solutions that are already available from third parties.
Question from Carsten: We are using .NET applications more and more. Therefore .NET support in Windows Installer is becoming increasingly important. A hot topic is starting of .NET applications from a network drive. To enable starting from network drives we need to create a code group in the .NET runtime which contains the key of the strong named digital signature of our components. With this code group we can specify a zone in which the .NET code will be executed, for instance the “internet” zone. We currently use installer class custom actions (written in C#) to create this code group. Will there be a Windows Installer solution for such configurations?
Answer from the MSI Team: When using .NET 3.5 SP1 the runtime now trusts network shares (editor’s note: see .NET 3.5 SP1 Runs Managed Applications From Network Shares). Other than that, managed code custom actions are a viable solution.
Question from Carsten: In a Major Upgrade, .NET components which have been installed in the GAC will be removed during uninstall of the old version but not installed again during install of the new version, if the version of the .NET component hasn’t changed. Workarounds would be incrementing the file version of the component, even if the file hasn’t really changed, or moving the RemoveExistingProducts action to the end of the install sequence. The latter is not an option for us, and manually incrementing the file version isn’t a good solution either. Will future MSI versions have better support for GAC installs?
Answer from the MSI Team: This is a bug that has been fixed in Windows 7 (MSI 5). However, the fix has not been back ported to SP2 for Windows Vista and Server 2008 as yet.
Question from Carsten: Will there be better cooperation between Windows Installer and security tools like anti-virus tools? These are sometimes preventing InstallScript custom actions from running, or block applications that are being launched for installation, even if they are digitally signed.
Answer from the MSI Team: This is not a problem that Windows Installer can solve. A workaround would be to avoid script based custom actions. Also there are anti virus tools that are particularly careful with setups to avoid such false positives.
Question from Carsten: When doing an administrative install the digital signature is invalidated. Will there be a solution for this?
Answer from the MSI Team: While MSI 5 will fix the problem with invalidating the digital signatures of locally cached .msi files by not stripping any embedded CABs, it will not solve the issue for administrative installs. When installing from an administrative image the source must be trusted in some other way.