We have a VSTO Excel document customization with installer targetting .NET 3.5 SP1 (full) that has been working for some time. We have begun to see a subset of users on Windows 7 that cannot load the customization with this error:
Microsoft.VisualStudio.Tools.Applications.Runtime.CannotCreateCustomizationDomainException: Customization could not be loaded because the application domain could not be created. ---> System.TypeLoadException: Could not load type 'System.AddIn.Pipeline.QualificationDataAttribute'
from assembly 'System.AddIn.Contract, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
at System.ModuleHandle.ResolveType(Int32 typeToken, RuntimeTypeHandle* typeInstArgs, Int32 typeInstCount, RuntimeTypeHandle* methodInstArgs, Int32 methodInstCount)
From what I can tell, a couple machines that can run this properly have System.AddIn.Contract of file version 3.5.30729.5420, while I have a machine that cannot load the customization and has file version 2.0.50727.146. If I drop the 3.5
assembly into the GAC on the "non-working" machine, it works. Replace it with the 2.0 assembly and it fails again. In fact, my Windows 7 development machine has the 2.0 version in the GAC and the 3.5 version in "Program Files (x86)\Reference
Assemblies\...". At this point, I'm assuming this is the root cause of our issue, an incorrect version of a .NET framework DLL.
Again these are Windows 7 machines, so we did not need to install or touch .NET 3.5 from our application's installer. I'm trying to understand where the 3.5 file version came from so I can determine how to properly resolve the issue on user machines. For example, am I missing a MS patch on some machines? Is the .NET install "corrupt" (even though netfx_setupverifier claims it is valid), and I should "uninstall/reinstall" the .NET 3.5 feature? I don't want to include
the DLL in our installer as it should come from somewhere else, I just don't know where.