Encountered this problem in the Fusion Log of a .Net website that uses a wrapper for some unmanaged C++ code:
LOG: Assembly download was successful. Attempting setup of file: C:\dev\...\bin\kdu_a75R.dll LOG: Entering download cache setup phase. ERR: Error extracting manifest import from file (hr = 0x80131018). ERR: Setup failed with hr = 0x80131018. ERR: Failed to complete setup of assembly (hr = 0x80131018). Probing terminated.
After a great deal of looking at Dependency Walker traces, countless forum articles and advice, it turned out to be the simple fact that a .Net website will look at every .DLL file it can find in the Bin folder of the website and try to load a .Net assembly manifest from it, even if it isn't a .Net DLL. Because reasons.
The solution to this is as obvious as it is absurd:
- Don't put unmanaged DLL files in a .Net website Bin folder.
- Put them in Windows' System32 folder where IIS will be able to find them.
That's just terrifying, but it does work. It makes me taste a little bit of sick in my mouth, frankly.