Tips to help debug "Could not load file or assembly X or one of its dependencies"

Question

I'm looking for tips/suggestions/insights to help debug an on application load issue; Could not load file or assembly...

The solution/project where I'm experiencing this issue is a conversion from a working copy in Visual Studio 2008 to the Visual Studio 2010 Release Candidate. The conversion process appeared to be successful, and all the solution projects are set to Framework 4.

The exception is on a 3rd party component (a graphics processing library), but any answers could possibly help others with any troublesome DLL.

Could not load file or assembly 'Aurigma.GraphicsMill.DLL' or one of its dependencies. is not a valid Win32 application. (Exception from HRESULT: 0x800700C1)

What's confusing about this exception is the additional text: is not a valid Win32 application.

The full exception stack trace is up on PasteBin, but doesn't seem to shed much more light on the issue...

What I have tried so far with no success:

1. Simple clean, rebuild, restart combinations of Visual Studio 2010 RC.
2. Removing and re-adding the DLL in question.
3. Toggling "copy local" to true and false on the DLL in question.
4. Confirming that after a "successful build" the DLL in question appears in the bin\debug folder.
5. Checking for any unnecessary references to the DLL in question (none found).
6. The associated licence file for the DLL in question is in the same directory with it.

I've also had no luck with it hitting any debugger breakpoints on application load.

Answer 1

I had a similar exception when my executable project was set to Any CPU and had a reference to a dll compiled with x86.

Try setting your executable to x86 and see if it works. If it doesn't try fusion log to get more detail about the error.

Answer 2

Tip

One investigation avenue that we undertook, that solved part of our issues but not the overall problem was a mix of x86 (32-bit) and x64 (64-bit) assemblies referencing each other.

Ensure you do not have 32 bit assemblies depending-on/referencing 64 bit assemblies.

Answer 3

I have found the cause of this issue to be that because you have switched to .net v4, you are now using a new application pool in IIS7 specificially for asp.net v4 (the pool itself is called 'ASP.NET v4.0')

In the advanced settings section of the application pool, set 'Enable 32-bit Applications' to true and your problem DLL will now load as expected.

Obviously you should do the same if your web application has its own application pool.