About Windows Installer, the .NET Framework, and Visual Studio.
Windows Installer 5.0 is shipping in Windows 7 as part of the operating system. To address the issue where the User Account Control consent dialog is displayed with an “Unidentified Publisher”, the .msi package is cached in its entirety.
Prior to Windows Installer 5.0, installation packages, or .msi files, were stripped of their embedded cabinets – if any – when cached on the system to save space. When repairing the product, if installed files were missing then Windows Installer would attempt to use the last used source location, an application-defined location, or prompt for the installation source. While these prompts can be annoying or even difficult to resolve sometimes, they do reduce the disk space required after an installation is complete.
When Vista added UAC, elevation even for administrators by default was required. Elevation was always required for per-machine installations, but administrator accounts already ran with full privileged tokens so elevation was implicit. To add validation to this elevation prompt - aka the consent dialog - the publisher for signed packages was displayed, and “Unidentified Publisher” was displayed for unsigned packages. But during uninstall, packages would display “Unidentified Publisher” even if they were signed because their embedded cabinets were stripped thus invalidating the digital signature and so Windows Installer wouldn’t verify the cached package as shown below using Windows Installer 4.5 on Vista.
MSI (s) (DC:0C) [16:46:44:058]: MSI_LUA: Elevation required to install product, will prompt for credentials MSI (s) (DC:0C) [16:46:44:059]: MSI_LUA: Entering Credential Request. hwnd = 1120166, MsiAction = 2, productname = Microsoft Visual Studio Team System 2008 Team Suite - ENU, version = 9.0.30729, language = 1033, manufacturer = Microsoft Corporation MSI (s) (DC:0C) [16:46:44:059]: MSI_LUA: (continued)... packagepath = , packagesource = , dwUpdates = 0
To resolve this issue, Windows Installer 5.0 in Windows 7 will cache the installation packages without stripping their embedded cabinets and verify the cached package as shown below using Windows Installer 5.0 on Windows 7.
MSI (s) (20:98) [16:51:25:386]: MSI_LUA: Elevation required to install product, will prompt for credentials MSI (s) (20:98) [16:51:25:386]: MSI_LUA: Entering Credential Request. hwnd = 1116208, MsiAction = 2, productname = Microsoft Visual Studio Team System 2008 Team Suite - ENU, version = 9.0.30729, language = 1033, manufacturer = Microsoft Corporation MSI (s) (20:98) [16:51:25:386]: MSI_LUA: (continued)... packagepath = C:\Windows\Installer\33e5a8b.msi, packagesource = C:\Windows\Installer\33e5a8b.msi, dwUpdates = 0
But this won’t prevent prompts for source even if all files are compressed into embedded cabinets. Windows Installer 5.0 does not consider the Installer-cached .msi files to be valid source and will still resolve possible source locations or prompt as it has in the past.
Installation developers should take this into account since Windows Installer already may require so much disk space and compress files if necessary in external cabinets. Consider your servicing scenarios carefully and determine if you should cache the installation source yourself using the Source List APIs like MsiSourceListAddSource provided by Windows Installer, or just let Windows Installer use its default source resiliency behavior.
"Windows Installer 5.0 does not consider the Installer-cached .msi files to be valid source and will still resolve possible source locations or prompt as it has in the past."
Wow, the worst of both worlds. WTF?
What about MSI installs with external CABS?
Will the external CABS get cached also, or is the MSI in this case, considered to be signed as a separate entity?
Since some apps display their serial numbers in the help tab, isn't this also providing an opportunity for software theft as the complete source is cached locally as well?
I have to ask the same question. Why on earth would MSI not consider a cached copy of the orig installation file be a valid source?
etippelt, the external CABs will not be cached. The embedded (internal) CABs are not stripped from the cached MSI to maintain the integrity of the (possibly) digitally signed MSI file. The signed hash includes all substreams, which also includes embedded CABs thus safeguarding against payload tampering. External CABs should be signed too, but are not necessary to maintain the integrity of just the MSI file which the consent dialog requires to display a valid publisher.
I'm curious as to why it wouldn't be used as valid source. I'm also curious why you would cache a full package if it's not digitally signed. Couldn't it be that you only do a full cache if it is digitally signed. Further if it's a full cache, why not use it for a source location? Is it because the cached MSI name is different?
Heck, if it's only going to be fixed in Windows 7 and not Vista, why fix it at all? And if the jenga tower is so fragile that you can't do anything actually useful then maybe it's not worth even trying. Wasting tons of disk space without the benefit of being able to resolve source just to solve an ugly unsigned uac dialog doesn't seem to add value in my opinion.
Windows installer is already notorious for consuming 40% of disk space in a typical Windows installation through its package cache, why would you go even further than that just to solve a corner case?
Hemchander, development lead for the Windows Installer team, has this to say,
"Windows Installer chooses to cache the entire MSI w/o stripping the embedded cab to give a consistent UAC expirience. i.e., for all types of MSI packages.
"However, this does open up several other interesting questions:
"1. What about cache size? Package authors are recommended to keep the package size in mind when designing their setups. Especially, packages with embedded cabs because now the entire thing gets cached. So, package authors should use external cabs to prevent their users from running out of disk space due to the new package caching semantics.
"2. Why doesn't Windows Installer use the cached MSI for source resolution? While caching an MSI with embedded cab can enable the source caching scenario, it doesn't solve the problem completetly (i.e., for MSI with external CAB and loose files). Eliminating the need for source prompts for MSI is a new feature in itself and is not addressed in Windows 7."
I think that what it eventually means is that we should no longer use embedded cabs even for small setups. I think that there should be an ICE about it.
Still we do want to provide a single file setup experience, I think that as part of the SDK should come a self extractor utility, that will wrap the MSI and all of the CAB and execute the setup.
Btw, why not strip MSI that are not self singed? most of the setups are not singed anyways.
Shay, while I agree about stripping cabs from unsigned MSIs there may have been resource constraints or other concerns around testing this fully.
I would like to state, however, that WiX has been working on a chainer that is coming along well. It's already used in a few places and is very robust. A lot of peopel agree - including those working on Burn, WiX's chainer - that a robust chainer should be provided. There's actually a lot of "gotchas" a good chainer has to consider such as caching.
The single file setup.msi story is my favorite. Why should I have to add the complexity of a bootstrapper just to support this?
And no offense, but just how far into the future is MSI.Next after Windows 7? 2 years perhaps? And yes, Burn looks promising, but how far is that one from being in a production relase... 2 or 3 years also?
ISHNMET handles all of this for me today and I keep trying to evaluate a switch to WiX instead but it just never happens because of key missing features.
Seriously, WiX jumps to add support for MSI 5.0 functionality and yet it's missing the boat on key 4.5 functionality.
Chris, I'm not sure how this has anything to do with MSI 4.5. WiX does support MSI 4.5. It supports adding embedded UI handlers but does not provide UI handlers since those would be wholy custom.
But how does this eliminate your single file setup? If it's small there's no big impact to the size of the cache, and if it's too big you run the risk of failing SAFER or WinVerifyTrust checks as I've blogged about happening in the past due to memory pressure and fragmentation.
And MSIs can still install copies of themselves and use Source List APIs in CAs to register the source location. This is how .NET has worked in past versions until we started using MSPs for a slipstreamed install and MSPs are cached in whole (thus negating the need of a second cache).
I'm using Wix 3.x, and the signed msi is still displaying "unknown" publisher. The machine has Windows 7 and msi 5.0
@allanCm, WiX doesn't sign MSIs since that's very different for everyone. Are you signing the MSI yourself? When do you see "Unknown" publisher? If only during uninstall, did you see it during install?
Even if you sign your file, you must also add the signing certificate chain to the machine certificate store. Authenticode certificates are as much about trust as they are verification. If you don't trust the signing certificate, or it's signing certificate, and so on, you can't trust the package. Anyone can make a signing ceritifcate, but only a trusted authority (explicitly or implicitly) can sign a package or signing certificate to be trusted.
Yes, I'm signing the binaries that msi will pack, and the msi itself, after the msi is built.
Also I'm signing the bootstrapper setup.exe that contains the packed msi.
I'm using signtool using a pfx file that I created based on a certificate signed by Verisign.
The dialog with the company is well displayed when the file is going to install (displays the blue alert), but when the uninstall is going to perform, the "unknown" publisher displays (in Vista and Win7 machines).