Azure references incorrect DLL

Question

This is somewhat of a follow up to: Reference alternate to reference assembly in Visual Studio 2010?

I am referencing an alternative version of a core framework DLL. Visual Studio (and the local debugger fabric) has no problem referencing this file. Additionally, the file is marked Copy Local. However, when I deploy to the cloud, I get:

Could not load file or assembly '(assembly strong name)' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.

Using remote desktop, I determined that the correct file is indeed in the E:\approot folder along with my other dependencies. I am assuming that the fabric is looking in the GAC instead of using my files.

Is there a way to force it to use my DLL first?

Note: The entire concept of replacing a .NET CLR DLL is a huge hack anyway, so hacks are welcome. When .NET 4.5 comes out supporting the feature I need, this will all be stripped out.

Further info: It appears my web role works fine, but my worker role dies with that error when it attempts to build my Autofac container. This happens even if I explicitly load the assembly before building it, which also works fine.

Answer 1

Could you try hinting the CLR that shall probe first in the local folder:

<runtime> 
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> 
  <probing privatePath="." /> 
</assemblyBinding> 
</runtime>

Check out more on Locating Assembly by Probing section here. This might help.

Answer 2

You could try to use the Appdomain.AssemblyResolve event to catch it and load it manually. However, i don't know if it's fired and it is a workaround.

Answer 3

You could run a fusion log to see where it is loading from. You may need to create a .config file for the process if something else is running and loading that file first. You may be able to do something exotic also like create a new appdomain and load your assembly there, something like what this does for dynamic assemblies:

http://blogs.msdn.com/b/tom/archive/2007/12/05/dynamic-assemblies-and-what-to-do-about-them.aspx

Answer 4

I've seen this issue befure if one of the project's doesn't have the .NET Framework version targetted. Perhaps check to make sure all projects in the solution have the same setting.