在我的 Web 和辅助角色中，我引用了核心框架 DLL 的替代版本。该文件被标记为复制本地。 Visual Studio 将正确的版本显示为项目引用。编译项目时，bin 目录也包含正确的版本。
但是，当我要求 Visual Studio 创建 Azure 包时，该包(以及打包过程中创建的 csx 文件夹)包含仅适用于辅助角色的错误(原始)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 的整个概念是一个巨大的 hack。当 .NET 4.5 支持我需要的功能时，这一切都将被删除。与此同时，我需要能够继续开发。
这是问题“Azure References Incorrect DLL ”的替代，该问题实际上是不正确的，并导致有效的答案，但没有解决我的问题。
最佳答案
即使 Visual Studio 项目引用了 GAC 中程序集的本地和/或修改后的副本，它也会在编译期间使用，但在运行时，CLR 将始终从 GAC 中加载程序集。 GAC，即使它与您的应用程序位于同一目录中。
因此，解决方案并不涉及找出一种巧妙的方法来打包或部署修改后的程序集，而是找出一种使 CLR 实际加载它(如果存在)的方法。
两种可能的解决方案:
1) 使用角色启动任务和安装项目将程序集的修改版本部署到生产服务器的 GAC 中。
2) 删除程序集的签名，并确保所有引用都没有签名。请注意其他可能引用原始签名版本并尝试从 GAC 加载它的程序集。
有关更多详细信息和链接，请参阅 How to prevent a .NET application to use an assembly from the GAC?
关于c# - Azure 包包含不正确的 DLL，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9279255/