Azure package contains incorrect DLL

Question

In my web and worker roles, I am referencing an alternative version of a core framework DLL. The file is marked Copy Local. Visual Studio shows the correct version in as a project reference. When compiling the project, the bin directory also contains the correct version.

However, when I ask Visual Studio to create an Azure package, the package (and the csx folder created during packaging) contains the wrong (original) DLL for the Worker role only. The Web role has the correct DLL. This does not occur if I manually use cspack, but that's not really a desirable way to package.

What could cause Visual Studio to compile with the correct reference DLL but bundle the wrong one?

Additional info: When I run msbuild to do the packaging instead of Visual Studio, I see the following two lines:

Copying file from "C:\Users\bytenik\Dropbox\Treadmarks\lib\EntityFramework\System.Data.Entity.dll" to "C:\Users\bytenik\Dropbox\Treadmarks\src\Azure\obj\Debug\Worker\System.Data.Entity.dll".
Copying file from "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\System.Data.Entity.dll" to "C:\Users\bytenik\Dropbox\Treadmarks\src\Azure\obj\Debug\Worker\System.Data.Entity.dll".

So, it seems to copy my reference, and then copy over it with the system reference.

Note: I'm well aware that the entire concept of replacing a .NET CLR DLL is a huge hack. When .NET 4.5 comes out supporting the feature I need, this will all be stripped out. In the meantime, I need to be able to continue development.

This is a replacement to question "Azure References Incorrect DLL", which was actually factually incorrect and lead to answers that were valid, but did not solve my problem.

For future reference it would have been better to re-write the original question. Thanks. — Kev, Feb 14 '12 at 15:51
@Kev I thought about it but all of the answers would have made no sense. — David Pfeffer, Feb 14 '12 at 15:53

score 1 · Accepted Answer · edited May 23 '17 at 12:20

Even if a Visual Studio project has a reference to a local and/or modified copy of a assembly that is in the GAC, it will be used during the compilation, but at runtime, the CLR will always load the assembly from the GAC, even if it is sitting right there in the same directory as your application.

So the solution does not involve figuring out a clever way to pack or deploy the modified assembly, but figuring out a way of making the CLR actually load it if it's there.

Two possible solutions:

1) Use a role startup task and an installation project to deploy the modified version of the assembly in the production server's GAC.

2) Remove the signature of the assembly and make sure all references are made to this version without the signature. Beware other assemblies that may be referencing the original signed version and will try to load it from the GAC.

For more details and links see How to prevent a .NET application to use an assembly from the GAC?

Azure package contains incorrect DLL

1 Answers1