Hi,
I'm developing NuGet packages and one issue with NCrunch is that it locks the DLLs. In my case I need to replace the DLLs in the NuGet cache folder (C:\Users\<username>\.nuget\packages\) for faster development and testing.
When I need to test a new version in another project which uses NCrunch, the files are locked. I need to disable NCrunch, copy the DLLs, and enable NCrunch again (or leave it off).
This problem bugs me since 2016 but I never reported it.
As Visual Studio can work with the DLLs without locking them: can NCrunch do the same?
Remco NCrunch Developer
#13628
27 Jun 2019 22:02 UTC
Hi, thanks for sharing this issue.
The problem here isn't actually NCrunch; it's the .NET runtime.
Packages that are referenced using Nuget are now stored in a global location (under the user profile) and the correct procedure for loading them is to do so from this location. In earlier versions we tried sandboxing these binaries but we ended up with endless problems because the runtime and its packages were simply not designed to work that way.
Something you can try is to turn on the terminate test runners when all test execution is complete setting. This will reduce the amount of file locking because the runner processes won't be left around after they've finished the test run.
Another option is to change your deployment model to avoid interacting with the packages in your user profile. Try referencing the binaries using the MSBuild <AssemblyReference> tag instead of <PackageReference>. This will prevent them from being loaded from a global location.
The problem here isn't actually NCrunch; it's the .NET runtime.
Packages that are referenced using Nuget are now stored in a global location (under the user profile) and the correct procedure for loading them is to do so from this location. In earlier versions we tried sandboxing these binaries but we ended up with endless problems because the runtime and its packages were simply not designed to work that way.
Something you can try is to turn on the terminate test runners when all test execution is complete setting. This will reduce the amount of file locking because the runner processes won't be left around after they've finished the test run.
Another option is to change your deployment model to avoid interacting with the packages in your user profile. Try referencing the binaries using the MSBuild <AssemblyReference> tag instead of <PackageReference>. This will prevent them from being loaded from a global location.
Post a reply
Log in to reply.