Tuesday, 17 February 2015

Running unmanaged code in a managed C# .Net website


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.

No comments:

Post a Comment