How to disable live code compilation/analysis in Visual Studio 2017?

[LeonidVasilyev]

Version Used: 2.6.0.6232903 Visual Studio 2017 marks Bar() with red squiggle before project is built: Is it possible to alter this behavior to show errors only after manually triggered build?

In Error List I see that the error message is produced by IntelliSense. I tried to disable full solution analysis in Text Editor options, set HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\14.0\Roslyn\Internal\OnOff\Features\Squiggles registry to 0, alter analyzer Active Rule Set.

For more information see Disable 'Show live semantic errors' for C# in Visual Studio 2017 and How to disable real time compilation in Visual Studio 2015 discussions on Stack Overflow.

[CyrusNajmabadi]

But right now I have to map from an arbitrary config ID back to an error?

You shouldn't have to. All errors should be reported with the ID you would use to disable them.

[levicki]

You shouldn't have to. All errors should be reported with the ID you would use to disable them.

I meant when I am editing config file, not when I am getting an error.

[CyrusNajmabadi]

to an internal ID (such as IDE0060) and back, not the user.

This ID isn't internal. It's reported in every UI we give for an issue. For example:

And this will be in the console output if you have these set to higher severity.

[CyrusNajmabadi]

I meant when I am editing config file, not when I am getting an error.

When you're editing the config file, the UI will provide nice human readable explanations and examples for each ID.

[CyrusNajmabadi]

you might as well use a binary file

.editorconfig is already supported industry-wide. Inventing something new to take the place of something that exists and works is just not something i think is a good idea.

and save some space as well as time spent parsing strings.

In general, the editorconfig file will be a few K. And the time spent parsing is extremely negligible. It also fits into an ecosystem that understands these files, and is threaded through all our APIs (for example, the information in them is provided to analyzers/generators/etc.). I don't think we should reinvent a mechanism for configuring this sort of thing when it's precisely the domain that this format was intended to solve.

[CyrusNajmabadi]

If you decide to make bigger changes to .editorconfig may I suggest using TOML for the config file format, and making full use of arrays, tables, and other advanced features it supports?

I think it's important that we not try to do anything outside the norm or documentation of the format here: https://editorconfig.org/#file-format-details

If the community around editorconfig adopts and supports these, then i'd have no problem with us doing the same. However, until then, I would prefer to stick with what is simple and effective and easily tooled across the ecosystem.

[levicki]

This ID isn't internal. It's reported in every UI we give for an issue.

I think you are reading what I write too literally.

When I said internal ID, I didn't mean hidden -- I meant what analyzer is using internally.

When you're editing the config file, the UI will provide nice human readable explanations and examples for each ID.

Are you allowed to say in which version will this UI be released?

.editorconfig is already supported industry-wide. Inventing something new to take the place of something that exists and works is just not something i think is a good idea.

I guess file format itself is good enough, I just wish that the syntax for diagnostics message configuration was the same as the one for the editor formatting configuration.

I don't think we should reinvent a mechanism for configuring this sort of thing when it's precisely the domain that this format was intended to solve.

Me neither, I was just pointing out that IDE0060 = none in a config file is not much more descriptive than storing 3c 00 followed by 00 in a binary file :-)

If the community around editorconfig adopts and supports these...

Somehow I don't think that will happen soon. They seem to be happy with INI file format.

[CyrusNajmabadi]

Are you allowed to say in which version will this UI be released?

It should be in whatever the very next release of roslyn is. It's possibly already been released in preview form. @jmarolf do you know?

I meant what analyzer is using internally.

Sure. but the benefit of this is that there's no guess work. You just take whatever ID we're showing you anywhere, and you use that. I do agree that there should be something in the editorconfig to help make the ID understandable. Sam outlined an approach that i think would work well.

They seem to be happy with INI file format.

Then i would prefer to stick with that. I don't want us going and breaking with convention :)

[jmarolf]

Are you allowed to say in which version will this UI be released?

It should be in whatever the very next release of roslyn is. It's possibly already been released in preview form. @jmarolf do you know?

This is currently available in Visual Studio 16.10 Preview 2

[levicki]

This is currently available in Visual Studio 16.10 Preview 2

Good to know, given that release channels is on 16.9.4, I believe 16.10 is not that far away.

[simeyla]

Regarding the Live Code Analyzers options in a project property page:

@drvic10k Can you file a new issue for the behavior you are seeing? The features described above are widely available now so it's highly likely the behavior you encountered is a similar symptom but unrelated cause.

I think the confusion is that this option is not available for .NET Framework projects. And legacy .NET Framework projects are likely to be larger and more prone to performance issues that would cause someone to need this option in the first place :-)

The property page in Visual Studio really ought to include a note on how to disable Live Code Analyzers for .NET projects. It could just link here: https://docs.microsoft.com/en-us/visualstudio/code-quality/disable-code-analysis?view=vs-2019#net-framework-projects

It was very confusing and in fact I installed a whole different preview version of VS to try to get it working!

[AntonGrekov]

How happy i was using AMD Ryzen 7 5800x with 32gb of RAM quad-threaded along with Samsung EVO 970+ SSD on my home PC with 3 Chrome windows opened(30-50+ tabs each), with Ubuntu running VirtualBox, 5 messangers, IntellIj IDE running with zero latency or lagging

Until i get to know what is Roslyn Code Analysis is in Visual Studio.... That one program while everything other is shut down kills my PC completly in a way that i even get black screen blinking while video driver crashes to respond or something

That is worst experience i ever get by running a program. I read about advantages that this cool-great-feauture gives and i dont want ANY of it, no matter how great they are.

Can pls someone tell how to remove this thing out of my PC forever ?!?! PLEASSEEEEEEEEE It loads CPU to 97-99% for more than 4 hours !!! And simply doesn't stop on a small project

[CyrusNajmabadi]

while video driver crashes to respond or something

@AntonGrekov our server does absolutely nothing with the video subsystem. If you are having crashes there it is an issue with your hardware.

It loads CPUE to 97-99% for more than 4 hours !!! And simply doesn't stop on a small project

Please report an issue using visual studio and have it include a trace. We can see what has gone wrong. You can use the instructions here: https://docs.microsoft.com/en-us/visualstudio/ide/how-to-increase-chances-of-performance-issue-being-fixed?view=vs-2019#slowness-and-high-cpu-issues

[AntonGrekov]

@CyrusNajmabadi This thing is drains absolutly all my RAM memory. Due to this video driver crashes, because of memory lack. Today i even wasnt unable to open WIndows Task Mgr - it errored due memory lacking. All that just after Roslyn Code Ananlysis started to work with my project - i didn't even build or debug project, just opened project that was opened 10-20 times before and didnt had any changes at all......

I hardly made a screenshot because if i would try to make a screenshot 1-2 minute later ScreenShot software would also crash because of a memory lack due Rosly Code Memory RAM killer drainer software.

I tried reinstalling VisualStudio but that not seems to be an issue, the main problem is huge memory leak by Roslyn Code Analysis

How to fix it ? You can see at screenshot it drains 17 GB !!! of RAM and its just a beggining, in 10-20 secs later it drains 22 GB and then goes to max 24 GB limit (Just no more RAM in my PC, it could go even to 50 GB)

[AntonGrekov]

25 Gigs Of Memory and counting ....

[CyrusNajmabadi]

@AntonGrekov please see the comments in https://github.com/dotnet/roslyn/issues/24513#issuecomment-1168869574

This process is container where many components from many teams run in. We will need a reported trace to determine what the issue is here and which team will need to investigate.

[CyrusNajmabadi]

How to fix it ?

@AntonGrekov there is a link provided to get the appropriate diagnostic information and traces so that the appropriate team can fix it. Please follow the instructions there. Thanks.

[AntonGrekov]

I've reported a problem with wide detailed data range to microsoft team via Report a problem tool Meanwhile i installed brand new Windows 10 with latests updates from official Microsoft website to a new partition of my ssd drive, installed hardware drivers and just latests visual studio - just the same result, at first and later launches 23-25 gigs of RAM drained and counting........ waiting on issue resolving, meantime switch to Rider, impossible to work

[CyrusNajmabadi]

@AntonGrekov can you link me to your report?

[AntonGrekov]

@CyrusNajmabadi sure, https://developercommunity.visualstudio.com/t/RoslynCodeAnalysisServiceexe-drains-UPT/10091268 i still fighting this... i've tried already so many different solutions from stackoverflow or other sources - no help... disabled code analysis for all projects, disabled code analysis in studio settings, tried different analyzer versions, and around 10 other solutions....

even if all code analys is switched off and even if Roslyn Analyzer package is not installed via nugget it still kicks in for 25-27GB until it breaks whole OS. Fresh new Windows install just exact same behaviour

I found one way to counter this: if visual studio is started on some project file(not any source code file) RAM usage may grow at max to 10 GB or even stay at 2-5GB. After around 3-5 mins it drops to 1.5 GB and now i can open sources and work normally

If project is opened with any source file at start - RoslyCodeAnalysisService kicks in and drammatically grows in RAM usage to 14GB in around 30 secs, and keep growing until it errors itself or OS hang on.....

Also that happens only on my project, which i won't say big. It has a lot of migrations, and some logic. I can't upload that project since it is commercial one

Also, i am already thinking on buying 32 GB more, but that might not help, it could just take 57GB's and still crash

UPDATE: even with "working" method when you start working with sources it still drains 23-25 GB's and crashes....

[CyrusNajmabadi]

i still fighting this... i've tried already so many different solutions from stackoverflow or other sources - no help... disabled code analysis for all projects, disabled code analysis in studio settings, tried different analyzer versions, and around 10 other solutions....

As mentinoed, this is a generic component host. Your issue may have nothing to do with code analysis. That said, thanks for the link, i'll look at it immediately.

[CyrusNajmabadi]

@AntonGrekov i don't see any perf traces included with your report. Did you follow the instructions linked previously (https://docs.microsoft.com/en-us/visualstudio/ide/how-to-increase-chances-of-performance-issue-being-fixed?view=vs-2019#slowness-and-high-cpu-issues)? Specifically, we need you to include the information related to "Provide a trace..."

[AntonGrekov]

@CyrusNajmabadi I dont quite remember but probably i did Report a problem, because i remember of many log files that were submitted while creating new issue. Anyway i followed suggested link and made a new recording, now for sure.

https://developercommunity.visualstudio.com/t/RoslynCodeAnalysisService-drains-upto-25/10093330

[CyrusNajmabadi]

Looks like it's still uploading and processing the data. Can you ping me tomorrow on this and i can look?

[AntonGrekov]

@CyrusNajmabadi Sure, tomorrow i need to work on project that requires me to use VS, so i won't forget.

Some more info: launching proejct with any file opened rather than sources seems to help as i mentioned above. open solution with initial project file(not source) - wait for 5-10 mins - ram rush seems to calm down and stops - now you can use VS

At some point ram taken freezes at 10-12 gb, sometimes 2-4 and after launching debug it resets to 1.4gb and stays there

[AntonGrekov]

@CyrusNajmabadi MS requrested record problem in first issue, did that as well

[CyrusNajmabadi]

Hey @AntonGrekov i don't see a trace attached to https://developercommunity.visualstudio.com/t/RoslynCodeAnalysisService-drains-upto-25/10093330. But i do see one attached to https://developercommunity.visualstudio.com/t/RoslynCodeAnalysisServiceexe-drains-UPT/10091268. Will look asap.

[CyrusNajmabadi]

Trace shows teh entirety of the time in:

Interestingly the memory allocation hit is here:

as a massive single outlier in the total memory allocated here:

This indicates one of a few possibilities here:

1. You have a truly MASSIVE anonymous-type e.g. new { ..... OMGHUEG ... }.
2. You have a truly MASSIVE number of anonymous-types. e.g. new { ... } ... new { ... } ... ad infinitum.
3. The compiler has a bug where it's effectively getting into an infinite loop while parsing anonymous-types due to some construct it doesn't understand. This infinite loop is what is causing the huge spike in CPU and the massive memory allocations as we spin forever, making no progress, constantly allocating nodes for the body of that anonymous type.

'3' seems very likely, but i can't rule out '1' or '2'. Would you be willing to zip up all your sources and send them to me? I could then do a simple parsing analysis to see what is likely causing this.

In hte meantime. @333fred @jcouv do you know of any existing issues with parsing anonymous-types, or anything we have fixed in this area that could be causing '3'? Looking at the code, i can see we do have a loop that does while (IsMakingProgress(ref lastTokenPosition)). However, i personally am not familiar/comfortable with the parser's idioms for loop parsing while ensuring progress to know if this is written correctly. This will likely take further investigation from compiler team here.

[CyrusNajmabadi]

@AntonGrekov I'm going to open a new issue on this and migrate this information there.

[CyrusNajmabadi]

Issue opened as: https://github.com/dotnet/roslyn/issues/62603

[CyrusNajmabadi]

Marking as 'need more info'. We will need information from @AntonGrekov to make progress on this. See: https://github.com/dotnet/roslyn/issues/62603

[edaqa-uncountable]

This was closed based on the discussion of performance it seems, not based on the original issue: to disable live code analysis. There is no resolution for that.