在我的web和worker角色中，我引用了核心框架DLL的替代版本。该文件标记为Copy Local。 Visual Studio在项目引用中显示正确的版本。编译项目时，bin目录也包含正确的版本。
但是，当我要求Visual Studio创建Azure包时，包（以及打包期间创建的csx文件夹）仅包含Worker角色的错误（原始）DLL。 Web角色具有正确的DLL。如果我手动使用cspack，则不会发生这种情况，但这并不是一种理想的打包方式。
什么可能导致Visual Studio使用正确的引用DLL进行编译但捆绑错误？
其他信息：
当我运行msbuild来进行打包而不是Visual Studio时，我看到以下两行：
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".
因此，它似乎复制了我的引用，然后使用系统引用复制它。
注意：我很清楚替换.NET CLR DLL的整个概念是一个巨大的黑客攻击。当.NET 4.5出现支持我需要的功能时，这一切都将被删除。与此同时，我需要能够继续发展。
这是对问题“Azure References Incorrect DLL”的替代，这实际上是不正确的，导致答案有效，但没有解决我的问题。
答案 0 :(得分：1)
即使Visual Studio项目引用了GAC中的程序集的本地和/或修改副本，它也将在编译期间使用，但在运行时，CLR将始终从GAC，即使它与您的应用程序位于同一目录中。
因此，该解决方案不涉及找出一种巧妙的方式来打包或部署修改后的程序集，而是找出一种方法使CLR实际加载它（如果它在那里）。
两种可能的解决方案：
1）使用角色启动任务和安装项目在生产服务器的GAC中部署修订版本的程序集。
2）删除程序集的签名，并确保在没有签名的情况下对此版本进行所有引用。请注意可能引用原始签名版本的其他程序集，并尝试从GAC加载它。
有关详细信息和链接，请参阅How to prevent a .NET application to use an assembly from the GAC?