Runtime error: Could not load file or assembly - Modules with different CPU types were found

Question

I'm getting the following runtime error in my WCF service.

Could not load file or assembly 'MyAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.

After some looking around, I found a suggestion to use Assembly Binding Log Viewer, or Process Monitor. Neither or which yielded any information (that is, the log viewer showed nothing at all, and the process viewer didn't see the assembly load being attempted.

I finally came across a suggestion to use this utility (dependency walker) to find out what the assembly was actually looking for. On opening, I got an error immediately; and the log stated the following:

Error: Modules with different CPU types were found. Warning: At least one delay-load dependency module was not found. Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.

Error: Modules with different CPU types were found.
Warning: At least one delay-load dependency module was not found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.

According to the module list, it couldn't find these:

API-MS-WIN-CORE-COM-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
API-MS-WIN-SHCORE-SCALING-L1-1-0.DLL
DCOMP.DLL
IESHIMS.DLL

Some of these look like they relate to the RT framework; however, this application was developed in .NET 3.5 (actually, that's not strictly true - it was developed in 4.5 and downgraded to 3.5).

Looking at some of these files seems to imply they are quite core Windows files, and oddly, I have used this dll elsewhere in the solution (admittedly on the client) without issue.

I'm using VS2013 although I've tried VS2012 and get the same issue.

I did come across this question which at first glance seems to be the same, although it relates to C++.

Can anyone give me some guidance as to what the issue might be, or what to try next?

Here is my fusion log:

=== Pre-bind state information ===
LOG: DisplayName = MyAssembly.MyLib.XmlSerializers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null, processorArchitecture=MSIL (Fully-specified)
LOG: Appbase = file:///c:/myprog/bin/Debug/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = myprog.exe
Calling assembly : System.Xml, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: c:\myprog\bin\Debug\myprog.exe.config
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).

I managed to reduce the library in question down until it was just a single static function that returns a string, and still get the error.

Solution 1

The thing that always helped me with resolving this error was to take closer look at the part of the error message which says "or one of its dependencies".

Solution 2

Visual Studio with WCF has a quirk - if you build using a selected platform, it dumps the assembly in a platform-specific folder. If you build with "Any CPU" it puts it in the root of your WCF's "Bin" folder.

When it configures IIS to help you? It automatically assumes your assemblies will be in the root of that "Bin" folder.

The net event is that when you select "x86" instead of "Any CPU" you end up with the assemblies built in the wrong spot and suddenly your WCF does not run. So this is one of the few rare cases where the catch-all error about not being able to load your file or assembly is telling the literal truth - Visual Studio put your assembly in the wrong place and now it can't find it.

I have no idea why they did it like that. WCF has some... interesting design decisions.

Comments

[user1703401]

Dependency Walker hasn't been maintained in a long time, it is completely inadequate to diagnose this problem. You will need to get Fuslogvw.exe going. It will always provide a trace of this error if you use it correctly.

[Paul Michaels]

I maaged to get the fusion log and have updated the question

[user1703401]

That was the 2nd failure, you need to find the entry for the original failure to load the assembly. The original failure error code was a simple "file not found" error, very common of course. Copying the file into c:\inetpub\MyServices\bin ought to bring some relieve.

[Paul Michaels]

The file is already there.

[user1703401]

Update your trace with the first failure to get help.

[Paul Michaels]

I've managed to get the actual error log.

[PMF]

Are you mixing platform types? Try setting both assemblies' target platform to x86 (or x64). Make sure your build is clean (the output path per platform is unique and no other files lie there)

[Mike Beeler]

When you "downgraded to 3.5 how did you do that exactly? It may make more sense to recreate your project file(s) and re add the references to verify that the right version of the runtime .dlls are being used

[Olivier]

Two questions: Is everything ok when opening your dll in reflector ? Are you changing current working directory at some point ? (debug=>breakpoint=>add : Environement.set_CurrentDirectory => will break if you do)

[Jay]

This link might solve your issue . stackoverflow.com/questions/10295614/…

[Jay]

This link might help solving your problem. [stackoverflow.com/questions/10295614/… [1]: stackoverflow.com/questions/10295614/…

[Jay]

This link might solving your problem. [mismatch-in-assembly-and-product-version][1] [1]: stackoverflow.com/questions/10295614/…

[Paul Michaels]

Just to be clear, I'm not using the WCF service from a website, but from a WPF desktop app

[Paul Michaels]

They are, I also checked the build order and it's correct, and manually built the projects in the correct order, and physically verified that the library is, in fact, there.

[Paul Michaels]

I've tried taking everything out, so that the library is basically a single static function that returns a string, and still get the error.

[Marek]

Well could you upload some isolated example?

[Paul Michaels]

I've rationalised the question a little.

[Mike Beeler]

None of the library methods rely on a third party library correct?

[Paul Michaels]

As I said, I migrated from VS2012 to 2013 during dev of the project; however, it's all deployed and run on my machine, and I'm now exclusively running 2013.

[Paul Michaels]

I'm not building with x86 - everything is Any CPU

[Paul Michaels]

I think this turned out to be the closest to an answer, so I'll award the bounty.

[Mike Beeler]

So it really would have helped, if you had said for example only fails when deployed.

[Paul Michaels]

It wasn't deployed, it was all running locally on my PC