0

I have a .Net 6 (Core) API application. When I deploy it, it fails using our CI/CD software because the servers' IIS worker process w3wp.exe seems to have a lock on the app's primary DLL (bin folder).

The API is pretty standard Microsoft best practice regarding async calls and using HttpClient properly (I use HttpClientFactory, I cache, I do seemingly best practice there too).

How can I find out what in my application is making this DLL locked by the worker process? Any tools I could run on the server to help locate the cause?

Derek R
  • 95
  • 1
  • 1
  • 8
  • Does this answer your question? [ASP.net C# requires IIS restart when new DLL copied to BIN directory](https://stackoverflow.com/questions/6196672/asp-net-c-sharp-requires-iis-restart-when-new-dll-copied-to-bin-directory) – gbjbaanb Mar 20 '23 at 22:06
  • @gbjbaanb this is older from .Net 2.0 days. Does this apply necessarily? I feel like it is just a workaround and not the crux of what causes it. We have other .Net Core (and above) apps that do not require manually killing the worker process... – Derek R Mar 20 '23 at 22:16
  • What CI/CD software are you using, and what are the current steps of the process? If your main .dll is actively being used by IIS during the deployment of new build artifacts, then it seems understandable that it's locking it during the deployment phase. – workinMan Mar 21 '23 at 02:46
  • the problem is not with .NET but with Windows handling of dlls and processes. There's no magic that can stop using a dll whilst simultaneously using it. You must tell the app to stop using it first - or effectively rename each dll so each one can be loaded independantly. This can be automated [using shadowcopy](https://learn.microsoft.com/en-us/dotnet/framework/app-domains/shadow-copy-assemblies) – gbjbaanb Mar 21 '23 at 10:50

0 Answers0