MSBuild.exe Running constantly Resharper 2019.3.4 Ultimate

Since installing resharper I've noticed that MSBuild.exe is very active in the background hitting 30 - 40% cpu. Even after the solutions been open for a long time and not been touched.


Suspending resharper stops this behaviour.

Any idea as what whats going on and how to stop it?

6 comments
Comment actions Permalink
Official comment

Hello Gary,

 

We use MSBuild to load project model in the background. It is normal for it to utilize CPU. This process should not affect the responsiveness of Visual Studio.

Thank you.

Comment actions Permalink

Sure it can affect Visual Studio responsiveness.

According to ReSharper's own logs, it runs these targets on (some of the?) projects:

16:19:51.302 |I| Build | :30 | Targets for build: _CheckForInvalidConfigurationAndPlatform;ResolveReferences;ResolveProjectReferences;ResolveAssemblyReferences;ResolveComReferences;ResolveNativeReferences;ResolveSdkReferences;ResolveFrameworkReferences;ResolvePackageDependenciesDesignTime;DesignTimeMarkupCompilation;Compile;CoreCompile;XamlMarkupCompilePass1

Looks like if any of these cause (maybe indirectly through dependencies) code generation, it may cause a "massive file system change" even when you are not actively doing anything. I am just staring at the visual studio, observing autogenerated code in obj folder get constantly updated and CPU occasionally dropping down from 100% to 50%. Luckily, it stops all activity when I alt-tab from visual studio, so it doesn't affect other applications responsiveness.

(this message doesn't ever go away)(this one pops in an out every few seconds)

It would definitely be good to know how to make custom targets ReSharper friendly so they don't get executed (or don't get executed more than I need them to). Is there a way to tell a build is being run for ReSharper's benefit, so I could put some conditions on the targets and what not?

0
Comment actions Permalink

We also have this problem on a large solution that is used by our global team of developers. 

I get the "Massive file system change" message and Visual Studio performance is awful.  

0
Comment actions Permalink

Workaround would be to disable targets generating code from design time builds. Of course, normally, you DO want them to run in design time. One option is to make these targets check whether the input was changed since last generation and avoid touching the output files in such cases. Ensuring that improved our VS performance a lot.

Would still be nice to detect design time builds run by ReSharper specifically.

0
Comment actions Permalink

Vladimir, you mentioned that you did the following fix:

One option is to make these targets check whether the input was changed since last generation and avoid touching the output files in such cases

How did you do it?

0
Comment actions Permalink

Itai Yacar

Well, we have targets using our own custom generation tasks, so it's not difficult to make modifications to them. Before actually generating code we compare the modification time of the source file (kind of an xml) to the output file (a cs we generate in obj folder) if it is present. And we only re-create the output file if the source is newer or if the output is not present.

0

Please sign in to leave a comment.