I have the following configurations options set to try and keep nCrunch out of the project build space.
'NCrunch cache storage path' set to '..\..\NCrunch'
'Workspace base path' set to 'C:\ncrunch'
But sometimes, when running 'dotnet watch', the watcher will see a global using file changed (output by the framework, I don't have a file of that name) and then die, complaining that it can't see which project to use.
It seems despite the settings above, NCrunch is occasionally outputting to the obj folder and that upsets 'dotnet watch'.
Am I doing something daft? This is on the latest version of NCrunch and running .net 8.
The output of 'dotnet watch' when this happens;
dotnet watch ⌚ New file: .\obj\Debug\net8.0\nCrunchTemp_ea015509-4955-4ab6-9b2b-f7f96106dd16.GlobalUsings.g.cs. Rebuilding the application.
dotnet watch ⌚ Exited
dotnet watch 🔧 Building...
MSBUILD : error MSB1011: Specify which project or solution file to use because this folder contains more than one project or solution file.
dotnet watch ⏳ Waiting for a file to change before restarting dotnet...
Remco NCrunch Developer
#16994
29 Jan 2024 23:02 UTC
Hi, thanks for sharing this issue.
There are two mechanisms that are likely tripping you up here:
Config files: NCrunch stores these adjacent to your project files by default, unless configured otherwise by changing the project config file storage path setting.
Loading of projects: To integrate with the build system, NCrunch needs to do some tricky stuff inside the project directory when it loads the project. This involves making a modified temporary copy of the project file and calling a number of MSBuild steps to learn about the structure of the project and its various dependencies. This is the cause of the nCrunchTemp files that you've identified. Unfortunately, the build steps involved generally create a number of derived files underneath the obj directory. The nature of these derived files depends on the version of the toolset you're working with (MS change them all the time). Unfortunately we don't have a way to perform this load step outside of your project directory, as all the data acquired during project load needs to come from the project directory.
I think the best move here is to educate dotnet watch on which files it should respond to. If possible, I would suggest instructing it not to respond to file system changes inside the obj directory.
There are two mechanisms that are likely tripping you up here:
Config files: NCrunch stores these adjacent to your project files by default, unless configured otherwise by changing the project config file storage path setting.
Loading of projects: To integrate with the build system, NCrunch needs to do some tricky stuff inside the project directory when it loads the project. This involves making a modified temporary copy of the project file and calling a number of MSBuild steps to learn about the structure of the project and its various dependencies. This is the cause of the nCrunchTemp files that you've identified. Unfortunately, the build steps involved generally create a number of derived files underneath the obj directory. The nature of these derived files depends on the version of the toolset you're working with (MS change them all the time). Unfortunately we don't have a way to perform this load step outside of your project directory, as all the data acquired during project load needs to come from the project directory.
I think the best move here is to educate dotnet watch on which files it should respond to. If possible, I would suggest instructing it not to respond to file system changes inside the obj directory.
That sounds sensible, thank you Remco.
Looking forward to the new version.
Looking forward to the new version.
Post a reply
Log in to reply.