Most frequent problem with the msi-fusion interaction?


Incorrect authoring of strong name. This particularly crops up at uninstall time as the MSIAssemblyName table ends up feeding the wrong identity to the Fusion API. This doesn't break at install because the Fusion API does not need to use the identity during installation.

Specific Instance

After applying a Major Upgrade, assemblies from the previous version are remaining in the GAC.  The log shows the assemblies being removed. Log Excerpts:

Action 9:00:32: RemoveFiles. Removing files
MSI (s) (80:74) [09:00:32:501]: Executing op: ProgressTotal(Total=5,Type=1,ByteEquivalent=175000)
MSI (s) (80:74) [09:00:32:521]: Executing op: SetTargetFolder(Folder=C:\)
MSI (s) (80:74) [09:00:32:551]: Executing op: FileRemove(,FileName=RTD.dll,,ComponentId={89D876CC-08E6-40BE-ADA1-60A06367E6EE})
MSI (s) (80:74) [09:00:32:571]: delegating uninstallation of assembly file : RTD.dll to Fusion
MSI (s) (80:74) [09:00:32:591]: Executing op: FileRemove(,FileName=ReplView.dll,,ComponentId={310E6806-274C-452F-92A0-84616E49D1BF})
MSI (s) (80:74) [09:00:32:631]: delegating uninstallation of assembly file : ReplView.dll to Fusion
MSI (s) (80:74) [09:00:32:651]: Executing op: FileRemove(,FileName=PerformanceHealthCheck.dll,,ComponentId={51AE0E7A-D7FE-48FC-B02A-4DE0375902FD})
MSI (s) (80:74) [09:00:32:661]: delegating uninstallation of assembly file : PerformanceHealthCheck.dll to Fusion
MSI (s) (80:74) [09:00:32:671]: Executing op: FileRemove(,FileName=DTClassLibrary.dll,,ComponentId={07047D05-CEB0-4EC5-B19F-E7F0BB5AFB3D})
MSI (s) (80:74) [09:00:32:821]: delegating uninstallation of assembly file : DTClassLibrary.dll to Fusion
MSI (s) (80:74) [09:00:32:861]: Executing op: FileRemove(,FileName=System.Runtime.InteropServices.APIs.dll,,ComponentId={CCB66762-BEAF-49D1-B265-C6D70067862C})
MSI (s) (80:74) [09:00:32:941]: delegating uninstallation of assembly file : System.Runtime.InteropServices.APIs.dll to Fusion

So Where's the ICE?

An ICE for this would break a bit of the mold for ICEs in that it would need to check the image against the authoring in the msi. Were we to break this barrier, here's what you'd need to do.

  1. Enumerate the file table and look to determine which ones are managed assemblies.
  2. Extract the assembly identity from each managed assembly in the MSI
  3. Look in the MSI assembly name table to make sure that each identity you found has is also in this table. Any fewer is an error. Any ones you didn't find are also an error.
There are metadata APIs for (1), and Fusion APIs for (2). It's a little ugly because there is a processorArchitecture field, which is new for Whidbey that you have to treat specially.

Content credit also belongs to

  • Alan, Microsoft Dev
  • Carolyn, MSI Dev Lead.  You can get other Carolyn insights about developing for Windows Installer from the Windows Installer Chat Archives
[Author: Robert Flaming]
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