我几个星期以来一直在努力解决这个问题。我所有的DLL都被正确引用，设置为Copy Local，我可以从我的本地机器到我们的构建机器上构建我的应用程序。我的本地和构建框都安装了Azure SDK 2.9，但是在我们的暂存环境中运行应用程序时，我们得到了
“无法加载文件或程序集'Microsoft.Practices.EnterpriseLibrary.Common，Version = 5.0.505.0，Culture = neutral，PublicKeyToken = 31bf3856ad364e35'或其中一个依赖项。系统找不到指定的文件。”
我在我们的登台机器上启用了融合日志，这是输出：
=== Pre-bind state information ===
日志：DisplayName = Microsoft.Practices.EnterpriseLibrary.Common，Version = 5.0.505.0，Culture = neutral，PublicKeyToken = 31bf3856ad364e35 （完全指定的） 日志：Appbase = file：/// F：/ sitesroot / 3 / 日志：初始PrivatePath = F：\ sitesroot \ 3 \ bin
日志：此绑定在默认加载上下文中启动。 日志：使用应用程序配置文件：F：\ sitesroot \ 3 \ web.config 日志：使用主机配置文件：D：\ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ aspnet.config 日志：使用D：\ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ config \ machine.config中的计算机配置文件。 日志：政策后参考：Microsoft.Practices.EnterpriseLibrary.Common，Version = 5.0.505.0，Culture = neutral，PublicKeyToken = 31bf3856ad364e35 日志：尝试下载新的URL文件：/// D：/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Files / public_ [my DLL] /80b18788/752a457e/Microsoft.Practices.EnterpriseLibrary.Common .DLL。 日志：尝试下载新的URL文件：/// D：/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Files / public_ [my DLL] /80b18788/752a457e/Microsoft.Practices.EnterpriseLibrary.Common /Microsoft.Practices.EnterpriseLibrary.Common.DLL。 日志：尝试下载新的URL文件：/// F：/sitesroot/3/bin/Microsoft.Practices.EnterpriseLibrary.Common.DLL。 日志：尝试下载新的URL文件：/// F：/sitesroot/3/bin/Microsoft.Practices.EnterpriseLibrary.Common/Microsoft.Practices.EnterpriseLibrary.Common.DLL。 日志：尝试下载新的URL文件：/// D：/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Files / public_ [my DLL] /80b18788/752a457e/Microsoft.Practices.EnterpriseLibrary.Common 。可执行程序。 日志：尝试下载新的URL文件：/// D：/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Files / public_ [my DLL] /80b18788/752a457e/Microsoft.Practices.EnterpriseLibrary.Common /Microsoft.Practices.EnterpriseLibrary.Common.EXE。 日志：尝试下载新的URL文件：/// F：/sitesroot/3/bin/Microsoft.Practices.EnterpriseLibrary.Common.EXE。 日志：尝试下载新的URL文件：/// F：/sitesroot/3/bin/Microsoft.Practices.EnterpriseLibrary.Common/Microsoft.Practices.EnterpriseLibrary.Common.EXE。
当我去D：/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET时，DLL不在那里，所以它显然在寻找这个DLL的“错误”位置。
我正在使用VS 2013.任何人都有任何想法？
编辑：当我从本地构建时，我可以确认bin文件夹正在被清除，然后将一些DLL重新复制回该文件夹。奇怪的是，成功复制到那里的DLL不再在我的代码或配置文件中的任何地方引用。我也有一个post build脚本，但我确认这些旧的DLL都没有在那里被引用，
第二次编辑：
我在其中一个暂存实例上找到了Enterprise Library DLL，但它不在错误引用的目录中。我们有一个Web项目，它引用了第二个项目，实际上是一个Azure云服务。因此，看起来该服务的文件夹是在Temporary ASP.NET Files文件夹下创建的，但它是空的。
DLL在这里：
D：\ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ Temporary ASP.NET Files \ root \ 59a01799 \ 5b6b1a2 \ assembly \ dl3 \ 11d624d2 \ 4e820e1f_4413d201
我认为“root”是Web应用程序。该错误发生在此文件夹中：
D：/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Files / [我的服务类库] / 060e4c2a / e3b3457e /
用于Microsoft.Practices.EnterpriseLibrary.Common.DLL。我们为web项目和引用的服务类库都有一个“packages”文件夹，它们都包含所有必需的DLL。所以我认为服务类库中有一个设置仍然指向根Web应用程序项目文件夹来查找DLL，我只是无法弄清楚它是什么。
答案 0 :(得分：0)
所以问题在于，在引用到Web项目中的服务库的预构建脚本中，前开发人员编写了一个文件复制程序来手动将某些DLL复制到bin文件夹。我在构建定义和中提琴下将这些DLL添加到该脚本，它起作用了。
感谢大家的回复。