IIS 中的应用程序池回收正在更改 DLL 上的文件权限
App Pool Recycle in IIS is changing file permissions on a DLL
我从未见过这样的事情，希望有人能给我指出正确的方向。
我在 IIS 中有一个应用程序，在 bin 文件夹中我有一个 Microsoft.Practices.EnterpriseLibrary.Common.dll.
的副本
当有人回收应用程序池或关闭网站并再次打开时，我使用 Microsoft.Practices.EnterpriseLibrary.Common.dll 的应用程序的功能开始抛出：
Could not load file or assembly 'Microsoft.Practices.EnterpriseLibrary.Common, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. Access is denied.
存在问题的 DLL，位于 bin 文件夹中，对提供给应用程序池的服务帐户具有完全控制权。
为了 "fix" 这个，我发现我可以简单地在同一个 bin 文件夹中执行任何写入操作 - 重命名文件夹、删除文件、重命名任何文件。他们都做了某事，在不更改权限的情况下（因为我已经比较了前后）解决了这个问题。
如果我再次回收应用程序池，同样的 Access is denied 错误 returns。
所以我的问题是：
- 什么可能导致
Access is denied 问题开始？应用程序是否没有使用我期望的 bin 文件夹中的 DLL？
- 回收应用程序池会导致 DLL 恢复到
Access is denied 状态有什么作用？它是否从某处引入 old/cached/broken 版本的 DLL？
- 为什么在
bin 文件夹中执行文件写入操作可以解决这个问题？当 IIS 监视它为应用程序提供服务的目录发生变化时，它可能在幕后做什么？
信不信由你，ASP.NET 实际上并没有执行或 link bin 文件夹中的文件。相反，它将它们复制到一个看起来像这样的临时文件夹：
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\VdirName06a747
每当您修改站点中的任何内容（包括 bin 文件夹）时，ASP.NET 都会创建一个新的临时目录并将文件复制到那里。新目录可能如下所示：
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\VdirName\ a9b6d973
我的猜测是某些进程锁定了 DLL。当您修改 bin 文件夹的内容时，ASP.NET 创建了一个新的临时文件夹并将 DLL 复制到那里。新文件夹没有锁定问题。
要找出谁锁定了文件，请转到命令行并键入以下内容：
tasklist /m Microsoft.Practices.EnterpriseLibrary.Common.dll
所以在这个问题持续到其他环境后，我需要快速解决这个问题。
John Wu 的回答帮助我找到了 IIS 正在旋转的临时 IIS 文件夹的问题，其中第一个从 IIS 重置中刷新的新文件夹被破坏，随后强制新的临时文件夹工作，但超时那些会"corrupted"。
我猜测可能是计算机上的病毒扫描程序或其他预定进程（不幸的是，它在许多团队和许多应用程序之间共享）正在拾取文件并将其锁定，我尝试通过将其添加到其他位置来移动我的临时文件夹我的 web.config:
<compilation tempDirectory="D:\Inetpub\[path to my application in IIS]\Temporary Files">
Temporary Files 只是我在应用程序部署位置中为新文件夹指定的名称。授予我的 AppPool 服务帐户对此文件夹的权限后，我的问题就消失了。
我没有解决 什么 弄乱了我的 DLL 的问题，但我已经接受了，在繁忙的共享框上，这可能是不可避免的- 只需将我的应用程序临时文件从通用默认位置移动到新的特定于应用程序的位置。
应用程序池回收停止破坏我的应用程序，它整个上午都在工作。如果您遇到此问题并且无法花时间找出是什么锁定了您的文件，将它们移到它们自己的位置可能会有所帮助。
我从未见过这样的事情，希望有人能给我指出正确的方向。
我在 IIS 中有一个应用程序，在 bin 文件夹中我有一个 Microsoft.Practices.EnterpriseLibrary.Common.dll.
当有人回收应用程序池或关闭网站并再次打开时，我使用 Microsoft.Practices.EnterpriseLibrary.Common.dll 的应用程序的功能开始抛出：
Could not load file or assembly 'Microsoft.Practices.EnterpriseLibrary.Common, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. Access is denied.
存在问题的 DLL，位于 bin 文件夹中，对提供给应用程序池的服务帐户具有完全控制权。
为了 "fix" 这个，我发现我可以简单地在同一个 bin 文件夹中执行任何写入操作 - 重命名文件夹、删除文件、重命名任何文件。他们都做了某事，在不更改权限的情况下（因为我已经比较了前后）解决了这个问题。
如果我再次回收应用程序池，同样的 Access is denied 错误 returns。
所以我的问题是：
- 什么可能导致
Access is denied问题开始？应用程序是否没有使用我期望的 bin 文件夹中的 DLL？ - 回收应用程序池会导致 DLL 恢复到
Access is denied状态有什么作用？它是否从某处引入 old/cached/broken 版本的 DLL？ - 为什么在
bin文件夹中执行文件写入操作可以解决这个问题？当 IIS 监视它为应用程序提供服务的目录发生变化时，它可能在幕后做什么？
信不信由你，ASP.NET 实际上并没有执行或 link bin 文件夹中的文件。相反，它将它们复制到一个看起来像这样的临时文件夹：
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\VdirName06a747
每当您修改站点中的任何内容（包括 bin 文件夹）时，ASP.NET 都会创建一个新的临时目录并将文件复制到那里。新目录可能如下所示：
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\VdirName\ a9b6d973
我的猜测是某些进程锁定了 DLL。当您修改 bin 文件夹的内容时，ASP.NET 创建了一个新的临时文件夹并将 DLL 复制到那里。新文件夹没有锁定问题。
要找出谁锁定了文件，请转到命令行并键入以下内容：
tasklist /m Microsoft.Practices.EnterpriseLibrary.Common.dll
所以在这个问题持续到其他环境后，我需要快速解决这个问题。
John Wu 的回答帮助我找到了 IIS 正在旋转的临时 IIS 文件夹的问题，其中第一个从 IIS 重置中刷新的新文件夹被破坏，随后强制新的临时文件夹工作，但超时那些会"corrupted"。
我猜测可能是计算机上的病毒扫描程序或其他预定进程（不幸的是，它在许多团队和许多应用程序之间共享）正在拾取文件并将其锁定，我尝试通过将其添加到其他位置来移动我的临时文件夹我的 web.config:
<compilation tempDirectory="D:\Inetpub\[path to my application in IIS]\Temporary Files">
Temporary Files 只是我在应用程序部署位置中为新文件夹指定的名称。授予我的 AppPool 服务帐户对此文件夹的权限后，我的问题就消失了。
我没有解决 什么 弄乱了我的 DLL 的问题，但我已经接受了，在繁忙的共享框上，这可能是不可避免的- 只需将我的应用程序临时文件从通用默认位置移动到新的特定于应用程序的位置。
应用程序池回收停止破坏我的应用程序，它整个上午都在工作。如果您遇到此问题并且无法花时间找出是什么锁定了您的文件，将它们移到它们自己的位置可能会有所帮助。