Tips to help debug "Could not load file or assembly X or one of its dependencies"_问答_开发者

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

The solution/project wh开发者_高级运维ere 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:

Simple clean, rebuild, restart combinations of Visual Studio 2010 RC.
Removing and re-adding the DLL in question.
Toggling "copy local" to true and false on the DLL in question.
Confirming that after a "successful build" the DLL in question appears in the bin\debug folder.
Checking for any unnecessary references to the DLL in question (none found).
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.

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.

If you are using Windows Server 2008 (not R2) see this post on how to assign correct permissions for your application pool identity

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.

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.

This is caused because you are trying to load a binary dependency (one of the the files in your Bin folder) that is 32bit and your application is running under 64 bit mode.

In .Net 4 and IIS 7 the application pools default to running in 64 bit mode.

Most .Net binaries are compiled with Any CPU set in its build properties. This means they work in 32 and 64bit mode.

Most C++ and C applications written in .Net do require to be specifically compiled for either 32bit or 64bit. This means that if you are using the wrong bin deployed version of you dependency it cannot load.

This can be solved using on of the following:

if you want to keep your 32bit reference/dependency:

Specifically set your IIS application to run in 32bit mode.
- In IIS Management;
- Application pool -> Advanced Settings (on the right)
- "Enabled 32bit applications" set to True.
- Restart your application pool
Install both of your assemblies (32bit and 64bit) in the GAC. IIS will load the correct version depending on the operating environment (in your case this appears to be the 64bit one).

If you just want to get it working:

Replace yout 32bit binary in your Bin folder with the 64bit one. IIS won't have a problem loading it.

Weird thing is, I was facing the same problem, and I put 'false' in the allow 32 bit applications in advanced settings of the app pool, and then it worked!

Changing advanced settings section of the application pool -> set 'Enable 32-bit Applications' to true solved my issue.

Check if the DLL was blocked. Right click on the Dll > Properties > UnBlock.