Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error
Rider: NCrunch causing temp files to be made in project directory
Options
Previous Topic Next Topic
willdean
#1 Posted : Wednesday, May 29, 2024 7:49:40 PM(UTC)
Rank: Member

Groups: Registered
Joined: 1/31/2012(UTC)
Posts: 27
Location: England

Thanks: 7 times
Was thanked: 2 time(s) in 2 post(s)
I'm using 5.7.0.3 but I've seen the same problem in earlier 5.x versions with Rider.

I'm running dotnet watch on a ASP.NET project, and it's fine with NCrunch under VS2022. But with Rider, NCrunch keeps making temporary (transient) files within the project directory, perhaps by triggering a build step. This triggers dotnet watch, and, even worse, sometimes NCrunch makes temporary .csproj (I think) files in the project directory, which particularly upsets dotnet watch and causes it to sulk. A typical (non-csproj) file which triggers a build might be: "\obj\Debug\net8.0\nCrunchTemp_539420b9-44b7-43d4-8d79-18ed369ada9c.GlobalUsings.g.cs"

Clearly this is NCrunch related - it's running at least some part of the build within the project's own directory, which is not how I've come to expect it to work. I don't want/expect NCrunch to write anything to my project directory at all other than config files.

I have set "Workspace Base Path" and "NCrunch cache storage path" to other directories on other drives.

Is this a known problem or is there some other setting which stops NCrunch/Rider from performing scratch operations in the project's own directory? I have run this sort of configuration for years in VS without this problem.

Obviously NCrunch shares its configuration between Rider and VS so it's not like I have them configured differently.

Thanks.
Back to top
Remco
#2 Posted : Wednesday, May 29, 2024 10:29:09 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,161

Thanks: 964 times
Was thanked: 1296 time(s) in 1202 post(s)
Hi, thanks for sharing this issue.

When NCrunch loads a project, it creates a temporary project file adjacent to the project it's loading. It then modifies this project to run a short truncated build that can retrieve critical information about the project so that we can later process it.

This happens when the engine starts, or any time files are added or removed from a project. It also happens when the project file itself changes (for example, properties are modified).

This is by design, and although it isn't as clean as we'd like, we are constrained here by the behaviour of MSBuild.

MSBuild does also produce other temporary files itself as a consequence of this resolution build, which should be cleaned up automatically by NCrunch (please tell me if you find any that aren't).

You'll find this behaviour is identical between both VS and Rider.

I recommend setting up an exclusion for dotnet watch to avoid it from triggering on _nCrunchTemp_* files. Unfortunately we can't avoid producing these files in NCrunch without disabling it entirely.
Back to top
willdean
#3 Posted : Friday, May 31, 2024 7:46:42 AM(UTC)
Rank: Member

Groups: Registered
Joined: 1/31/2012(UTC)
Posts: 27
Location: England

Thanks: 7 times
Was thanked: 2 time(s) in 2 post(s)
Thanks! There is clearly something about either the specific project or my Rider environment which is triggering NCrunch into doing this so frequently. I will investigate...
Back to top
Remco
#4 Posted : Friday, May 31, 2024 8:26:58 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,161

Thanks: 964 times
Was thanked: 1296 time(s) in 1202 post(s)
willdean;17401 wrote:
Thanks! There is clearly something about either the specific project or my Rider environment which is triggering NCrunch into doing this so frequently. I will investigate...


NCrunch's logs do contain the names of files that can trigger projects to be reloaded. The logs get a bit noisy, especially if a lot is going on, but this can be a good way to isolate the root cause. You might find there is something else adding or removing files in the project .. which then triggers NCrunch ... which triggers dotnet watch.
Back to top
Der-Albert.com
#5 Posted : Monday, June 10, 2024 1:43:42 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 5/17/2011(UTC)
Posts: 209

Thanks: 11 times
Was thanked: 55 time(s) in 51 post(s)
Because of the multiple .csproj file from NCrunch I have the following problem.

I can't use `dotnet watch` with a specific project because dotnet watch does not pass the supplied --project to the underlying build.

https://github.com/dotnet/sdk/issues/33674

We use `dotnet watch` normally in hour developer support scripts (Scripts in PowerShell), before NCrunch is was just possible todo 'dotnet watch` or other stuff direct in the project folder (scripted) this is not possible anymore, so i adapted the scripts to search for the project file (and exclude the NCrunch stuff).
So this is no a big issue. But then I have to dotnet run it, and not to watch it.

But we are used to `dotnet watch` because it watches. Now we can't watch anymore, only because of me while I use NCrunch ;).

And currently NCrunch is not in the official company tool chain (Working on that).

Not sure what you can do about that, this is more just for information.
Back to top
BLOG
1 user thanked Der-Albert.com for this useful post.
Remco on 6/11/2024(UTC)
Remco
#6 Posted : Tuesday, June 11, 2024 1:12:42 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,161

Thanks: 964 times
Was thanked: 1296 time(s) in 1202 post(s)
Der-Albert.com;17409 wrote:

Not sure what you can do about that, this is more just for information.


Thanks for sharing this. Having spent a good deal of time staring at this problem and trying to find ways of dealing with it, I'm going to reluctantly need to pass the buck here.

The design of the platform has really walled us in with this. We need to create temporary files to reliably load projects. Any other way is going to involve rebuilding MSBuild itself, which would be impossible to maintain even if we could justify doing it. We are, actually, not the only ones that do this either. Temporary file creation is commonplace in dev tools. VS itself makes about half a dozen file system changes every time you CTRL+S on a single source file.

We go to some pretty insane lengths to work around limitations in other software, but to me this problem feels like it belongs in dotnet watch. Any tool that monitors file system activity to trigger actions should have a reliable way to provide exclusions, otherwise this kind of problem is inevitable, regardless of whether NCrunch is being used or not.

I realise this is probably the answer everyone expects from me here anyway, so I'm not exactly adding anything useful ... but we really can't take responsibility for this one.
Back to top
Users browsing this topic
Guest
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

YAF | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.045 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download