I'm seeing an issue where the visual studio process Microsoft.VisualStudio.Web.Host.exe is locking a native dll for gRPC grpc_csharp_ext.x86.dll.
We have a .net Framework 4.6.1 web application running in IIS, on windows machines (Windows10 and Server). It uses gRPC and bundles with it the following dll's
Grpc.Core.dll
Grpc.Core.Api.dll
grpc_csharp_ext.x64.dll
grpc_csharp_ext.x86.dll
From what I can tell of the the gRPC library loads the correct dll for it's architecture here https://github.com/grpc/grpc/blob/2780136fcf9bd268aaddea74b115fbc2faa97c61/src/csharp/Grpc.Core/Internal/NativeExtension.cs#L83 and never makes any attempt to release it. I believe this is ok as everything should be released once the running process stops.
However if you have the application running in IIS and attach the debugger from Visual Studio, then attempt to rebuild the application, Visual Studio will ask you to stop debugging, perform the build and hit this issue which mainifests as:
"...\packages\Grpc.Core.2.29.0\runtimes\win\native\grpc_csharp_ext.x86.dll" to "bin\grpc_csharp_ext.x86.dll".
Exceeded retry count of 10. Failed. The file is locked by: "Microsoft.VisualStudio.Web.Host.exe (34932)"
"...\packages\Grpc.Core.2.29.0\runtimes\win\native\grpc_csharp_ext.x86.dll" to "bin\grpc_csharp_ext.x86.dll".
The process cannot access the file 'bin\grpc_csharp_ext.x86.dll' because it is being used by another process.
I've had a similar issue with IIS locking the same dll, and am aware of this issue raised against gRPC https://github.com/grpc/grpc/issues/21867 which resulted in the Grpc_SkipNativeLibsCopy being created. This issue was mitigated by adding a pre-build app pool recycle.
However there does not seem to be any way to around this issue, the only course of action seems to be to kill the Microsoft.VisualStudio.Web.Host.exe process.
Can anyone help shed any more light on how we can either stop this from happening, or find a better way to mitigate the issue?
