我们有一个ASP.NET应用程序，这个应用程序是由一名前雇员编写的，我迄今为止一直使用胶带。该应用程序是用MVC，NHibernate和其他一些进程编写的，我们的其他任何应用程序都没有使用，因此我对如何支持这些应用知之甚少。为了使事情进一步复杂化，原始应用程序不是为了正确部署而构建的，因此我必须遵循所述员工的一组指令，说明要复制哪些文件以手动获取更新。我今天尝试进行更新，在复制任何内容之前备份应用程序所在的整个文件夹C:\Inetpub\wwwroot。复制文件后，我回收了应用程序池，这通常是应用更改所需的全部内容。相反，我得到了这个错误：
无法加载文件或程序集“Antlr3.Runtime”或其依赖项之一。访问被拒绝。
扰乱，但不是太沮丧，我只是将我的备份文件夹复制回应用程序的文件夹，应该将其重置为我尝试更新之前的方式（因为我所做的只是复制了一些文件）。但是，错误仍然存在。我曾尝试多次重新复制，重新启动应用程序池，重新启动IIS等，但无济于事。到目前为止，我的谷歌已经证明是无用的。如果您认为它有用（对我来说看起来没用），我可以提供完整的堆栈跟踪。我真的在我的智慧结束，因为在我可以告诉的服务器上没有其他任何改变，并且该文件夹已经恢复到其原始状态（再次，据我所知...我没有做过文件比较100多个文件中的每一个。）
答案 0 :(得分：3)
如果您不想让网站在本地运行，这可能不适用，但是，这可能有助于某些人......
我把生产服务器的web.config带到了我的本地工作站。我忘记了生产配置使用模拟。结果证明是我的问题。该用户几乎没有我本地工作站的权限。
如果将模拟用户添加到本地计算机的IIS_WPG，则可以避免对临时ASP.NET文件权限等进行奇怪的操作。
向this post致敬，这让我了解了这一事实。
我的解决方案是从我的本地web.config中删除模拟行
答案 1 :(得分：1)
对我来说问题出在配置文件中。
<identity impersonate="true" userName="abc" password="xyz"/>
此处所提供的凭证不正确，或者如果不需要则注释掉。
答案 2 :(得分：0)
您是否可以检查wwwroot文件夹中的IIS用户和“Temporary ASP.NET Files”C：\ WINDOWS \ Microsoft.NET \ Framework \ version \ Temporary ASP.NET的权限？如果权限正好，请尝试清除asp.net临时文件夹并再次运行您的应用程序（并再次检查此文件夹的权限）。
答案 3 :(得分：0)
刚修好这个。一个新的原因：
部署文件夹上的ACL已经搞砸了（例如。bin文件夹，在资源管理器的安全高级视图中显示，不是从其父级继承权限，而是继承其父级的父级）
来自网站根目录的快速重置权限，并且所有权限都重新开始工作。