A couple of weeks ago a received an error report from a customer of my MZ-Tools add-in saying that VS 2005 failed to load it with error “Unknown error” and error code 0x80131018. Searching my e-mail history it happened that that error was already reported by a previous customer months ago, but it was not clear how it was solved. The current customer tried to reinstall the add-in, to reinstall VS 2005 and even to format the hard drive, to no avail. Searching on the web, there is little information about this error, only that it is mapped to COR_E_ASSEMBLYEXPECTED and that it caused because a .NET assembly doesn’t have a manifest, that is, it is not a .NET assembly actually. In fact, this method is used to know if a DLL is a .NET assembly or not. But how could it be that a .NET add-in assembly does have a missing manifest? The customer sent it to me and the manifest was there. In fact, it loaded perfectly on my machine, and on another machine of him. The fuslogvw.exe tool gave this log:
LOG: This bind starts in LoadFrom load context.
WRN: Native image will not be probed in LoadFrom context. Native image will only be probed in default load context, like with Assembly.Load().
LOG: Using application configuration file: C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\devenv.exe.Config
LOG: Using machine configuration file from C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\configmachine.config.
LOG: Attempting download of new URL file:///C:/Program Files/MZTools2005/MZTools5.DLL.
LOG: Assembly download was successful. Attempting setup of file: C:\Program Files\MZTools2005\MZTools5.dll
LOG: Entering run-from-source setup phase.
ERR: Error extracting manifest import from file (hr = 0x80131018).
ERR: Failed to complete setup of assembly (hr = 0x80131018). Probing terminated.
In the tests that I asked him to perform, the assembly loaded correctly using Assembly.LoadFrom from a Windows application or using the Reflector for .NET tool, so the error happened only inside VS 2005.
Finally, and when I was quite desperate with this problem, the customer discovered that the problem was caused by the version 2007 of his antivirus, which I won’t cite, but suffice to say that the culprit was its “Protection Against Unknown Threats” feature. As soon as he deactivated that feature, the add-in loaded quite happily.
I hope this helps if you ever find this problem.
9 thoughts on “The strange case of error 80131018 loading a Visual Studio add-in”
Great catch! Thanks!
Carlos can’t says the name of the Antivirus, me as a Certified Reseller can.
The Antivirus is Panda Antivirus. In my case I get the trouble strangely in the middle of the work. From one moment to another the MZ toolbar disappeared.
Reinstalling the new version I got that exception, and despite was able to load the assembly with the LoadFile Method on VS I wasn’t able to see again my toolbar.
The solution is close VS; manually unregister the dll with the RegAssembly20 /u MzTools5.dll, wait the end, reinstall, open VS, re-enable Antivirus.
I’ve had a similar problem with References not resolving properly on one machine, while they do on other machines. After I read this post, I tried to disable the TruPrevent feature of Panda Antivirus, and suddenly it worked! So thanks for the info! =)
I had the same problem when referencing any downloaded dll in my projects (rhino mocks, log4net, castle windsor, …). After disabling TruPrevent the problem is gone.
The problem still exists in Panda Antivirus. Thankfully I found this blog item which solved my problem directly.
I see this error while installing Autocad mechanical desktop 2007, after disableing my NOD32 antivirus I saw the error again. what about my problem?
Thanks a lot, spent 8 hours to figure out why VS refuse to register a dll. The problem was in Panda for Desktops…
I have the same problem and after i read your article and answers I disable Panda Antivirus Software and Application worked.
Thanks for your sharings.
Hello thx for help !
I resolve my issue, in GAC folder with explorer i could see the system.runtime.serialization dll but when i used cmd prompt on this folder the dll exist on GAC_MSIL and not on GAC. So i have copied System.Runtime.Serialization folder from GAC_MSIL on GAC
and after reboot VS my project compile perfectly.
To move dll easily I used
start > run > cmd
type : “cd windows\assembly”
type: “attrib -r -h -s desktop.ini”
type: “ren desktop.ini desktop.bak”
now i can open the GAC folder normally in your explorer, and you can see the actual structure.
Comments are closed.