A procedure imported by {myassembly} could not be loaded

Question

when running a prorgam, it seems that I am missing a library, when I launch the output of my project I get an exception at startup.

A first chance exception of type 'System.IO.FileLoadException' occurred in mscorlib.dll
An unhandled exception of type 'System.IO.FileLoadException' occurred in mscorlib.dll

Additional information: A procedure imported by 'my assembly, Version=xx.1.1.0, Culture=neutral, PublicKeyToken=7292581204d9e04a' could not be loaded.

'ScriptX.vshost.exe' (Managed): Loaded 'C:\WINDOWS\assembly\GAC_MSIL\System.Configuration\2.0.0.0__b03f5f7f11d50a3a\System.Configuration.dll', No symbols loaded.

My question is: how can I determine which library is missing because, at this point, I cannot see the values passed to:

mscorlib.dll!System.AppDomain.ExecuteAssembly(string assemblyFile, System.Security.Policy.Evidence assemblySecurity, string[] args) + 0x3a bytes    

Answer 1

There is in fact a built in mechanism for just these diagnostics.

(1) In your project properties/Debug, make sure 'Enable native code debugging' is checked:

(2) Raise the show-loader-snaps flag - it is a registry key in the IFEO, and is accessible via the 'GlobalFlags' GUI:

(3) Run the app and inspect the (very) verbose output pane. You can mostly skip to the end or look for 'ERROR'.

More details here.

Answer 2

Are you doing any dllimport? - this looks like an issue with an unmanaged dll not being found?

First thing is to ensure that any unmanaged dll's or exe's that you are calling into (via dllimport) are deployed into the same folder as the .Net exe that you are building

If the source of the calling assembly is not available you could try using reflector on that assembly to search for dllimport statements

Other than that you might want to enable the fustion log viewer to trace assembly load issues - see this blog post and msdn page for more details

Answer 3

Implement a handler for the AppDomain.AssemblyResolve event. It tells you which assembly it is looking for with ResolveEventArgs.Name. If this is just an effort to troubleshoot this particular assembly then use Fuslogvw.exe. If the hangup is an unmanaged assembly then DependencyWalker's Profile option can show you what LoadLibrary() call is failing. SysInternals' ProcMon will work too but is a lot noisier.