我有一个名为MyApp
的MVC 5项目,它编译成MyApp.dll
我正在使用Visual Studio 2015并编译目标.net Framework 4.5.1
开发一段时间之后我再也无法编译了,因为IIS Express Worker Process
没有释放文件\obj\Debug\MyApp.dll
奇怪的是,如果我事后完全重新编译,程序集会被释放,然后我可以再次开始调试,至少大部分时间都是。
(在某些情况下,重新编译不再有用了,我必须开始杀死这个过程)
任何想法为什么IIS Express工作进程会阻止我的程序集?
答案 0 :(得分:6)
如果在目录上激活了索引,则可能存在文件锁定问题。可能是问题,因为它结果是在IIS中的虚拟目录的设置中。如果虚拟目录仍然index this location
标志已转为on
,则表明IIS正在对这些文件进行临时锁定,即使Web应用程序未启动(即它是只是一个编译,而不是一个调试运行)。转动index this location
设置off
后,文件锁定问题将消失。
有关详细信息,请参阅this。
答案 1 :(得分:3)
我认为这里真正的答案是Visual Studio在这方面有点麻烦。 有时桌面应用程序(winforms或WPF)也会发生这种情况,因为项目的锁定输出(您正在构建的exe或dll)导致构建失败。
我有类似的问题,有时,使用Visual Studio professional 2013,我认为它也发生在旧版本上。 当发生这种情况时,我关闭Visual Studio并重新打开它,这解决了所有问题。
一些参考:
Visual Studio 2010 build file lock issues
答案 2 :(得分:2)
我在使用除Internet Explorer之外的其他浏览器调试应用程序之前遇到的问题,Visual Studio将仅分离该过程,但不会关闭该服务。 有时当释放句柄时,应用程序不会释放服务正在使用的资源(例如正在访问的日志文件或附加到刚刚离开的会话的长时间运行的进程。)@Michael提到可能存在内存泄漏。 我不得不强制关闭IIS,以释放资源。 发生的另一件事是同一台机器(RDP)中的2个开发人员正在处理相同的服务器,并且端口/库不会在一个或另一个使用它时发布。 由于我们没有关于您的开发环境的更多详细信息,所有这些都构成了“可能”的场景。
答案 3 :(得分:1)
根本原因是IIS对文件有锁定,VS无法在编译时删除该文件。 Mark Russinovich(微软院士和SysInternals联合创始人)有一篇关于如何跟踪这个问题的博客:The case of the mysterious locked file - 他基本上使用Process Monitor(FileMon)和Process Explorer进行调查。
在您确定IIS无法解锁DLL的原因之前,以下是一些解决方法:
使用提升的权限启动cmd并发出netstat -an -p tcp
以检查其他应用程序是否正在争用您正在使用的端口并导致绑定冲突问题。您可以查看httperr日志以获取更多信息。
转到项目的属性> tab" Debug" >取消选中"启用 Visual Studio托管过程"。
使用提升的权限启动cmd并发出net stop iisadmin /y
后跟iisreset
。
执行一个干净的解决方案并完全重新编译,这是间歇性的,因为没有100%安全的方法来了解文件是否正在使用"因为你检查后的毫秒数,文件可能不再被使用,反之亦然。
通常我必须回到最后的手段并将锁定的文件MyApp.dll
重命名为MyApp1.dll
。
我想要解决的最后一件事是@ user1438893评论" IIS Express是错误的"。也许这是一个错误,也许是它的设计,但更可能是由最终用户代码引起的内存泄漏/未释放的钩子/未处置 - 非托管资源。使用Process Monitor和Process Explorer将能够帮助您找到答案。
答案 4 :(得分:0)
我几天前从Visual Studio 2015 Update 1升级到Update 2。那以某种方式解决了我的问题。 其他人也可以确认一下吗?
答案 5 :(得分:0)
我正在使用VS2019。我在asp core 3.1
系统中遇到了此问题。
我在VS中关闭了所有打开的项目,然后重新启动了PC,它可以正常工作。
尝试一下,也许会对您有所帮助。
答案 6 :(得分:-2)
请注意,如果工作进程(w3wp.exe)是试图访问MVC应用程序的进程,那么仅当通过浏览器访问的客户端关闭时才会释放对dll的依赖性。您可以在IIS中部署Web应用程序后尝试对其进行调试,这样就可以将副本发布到inetpub / vitual目录中,并且可以阻止VS中对dll的directoy依赖。