Thoughts about setup and deployment issues, WiX, XNA, the .NET Framework and Visual Studio
All postings are provided AS IS
with no warranties, and confer no rights. Additionally, views expressed
herein are my own and not those of my employer, Microsoft.
A little while back I posted a blog entry about some common 1935 errors that might happen during an MSI installation. Since then, I have gotten a few questions about different types of 1935 errors that have HRESULTs not listed in my previous post.
I wanted to talk about one specific interesting type of error. The HRESULT for this error is 0x80131532, and the corresponding error code in the header file means COR_E_MISSINGMANIFESTRESOURCE.
This error has a couple of possible causes. Both of the causes I have encountered so far are rooted in errors during setup creation.
Case 1 – incorrect file entry in the MsiAssembly table
In the case of the customer that reported this HRESULT to me, the MSI was authored with an invalid file value in the File_Manifest column of the MsiAssembly table for one or more assemblies that are listed to be installed. The fix is to make sure that the File_Manifest values for all assemblies in the MsiAssembly table refer to file entries that exist in the File table of the MSI. The interesting thing (in a bad way) is that the customer who hit this problem reported that ICE validation suites did not catch this problem. I haven’t had a chance yet to look into why ICEs would miss this because it seems like a relatively simple thing to validate.
Case 2 – invalid assembly attributes in the MsiAssemblyName table
The other cause that I have seen so far is specific to the .NET Framework 2.0 beta 1. In this scenario a .NET assembly is authored with invalid attribute pairs in the MsiAssemblyName table of the MSI.
In the .NET Framework 2.0 beta 1, if in valid attribute pairs are found in the MsiAssemblyName table, installation fails with a 1935 error. In the .NET Framework 2.0 beta 2 and later, this will be reverted back to the behavior seen in .NET Framework 1.0 and 1.1 - unknown assembly identity attributes will be ignored and not cause errors or failures.
The following blog entry and bug report describe this instance of the problem in more detail.