One of the customers of my MZ-Tools 6.0 for Visual Studio .NET add-in reported some days ago that the setup was showing the following error when installing MZ-Tools for Visual Studio 2010 (RC) (it worked fine for other IDE versions):

“The assembly ‘VSLangProj80, version 8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’ should be present in the Global Assembly Cache (GAC) but it has not been found there, maybe the uninstallation of some other product remove it”

It happens that it is not clear for some people (even within Microsoft) that EnvDTE.dll, VSLangProj,dll, etc. should not be included in the setup of Visual Studio add-ins, so some people were including those dlls in their add-in setups, with the undesired consequence that somehow those dlls were being removed from the GAC when uninstalling some add-ins. When I got tired of bug reports related to this, I made the setup of my add-in to check the existence of some required Visual Studio assemblies such as EnvDTE.dll, etc. and to provide the customer with a procedure to restore them (omitted for brevity in the message above) copying them from the Visual Studio folders to the GAC.

So, I got my customer to check the VSLangProj80.dll in the GAC and… it was there. Then I noticed that VSLangProj80.dll has a dependency on VSLangProj2.dll that the setup was not checking. But that dll was also in the GAC. Then I noticed that to check the existence of a DLL in the GAC my setup was trying to load the dll using System.Reflection.Assembly.Load(assemblyName) and if the load failed with any exception, then it assumed that the assembly was not in the GAC. So I guessed correctly that the error message was misleading, I changed the setup to show the message above only if the exception was a System.IO.FileNotFoundException, and to show the actual exception otherwise. Then we got this other error:

“System.IO.FileLoadException: Mixed mode assembly is built against version ‘v1.0.3705’ of the runtime and cannot be loaded in the 4.0 runtime without additional configuration information”

Then I learned what a “mixed mode assembly” is and the useLegacyV2RuntimeActivationPolicy attribute that needs to be used in a .config file to fix that issue in CLR 4.0, but I will let Mark Miller (Marklio) to explain it in full detail and to the MSDN documentation the short version.

There is something that I haven’t solved yet and it is why I was unable to reproduce the problem on my computer when the .config file didn’t have yet that attribute, but anyway the problem was solved for my customer.