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.

[sharwell]

💭 This may be a case where the feature was so infrequently used that it became prone to higher rates of regression bugs between releases (lack of use meant bugs in the behavior were not detected).

/cc @kuhlenh

[jmarolf]

Disabling full solution analysis does not disable analysis in the current file. In between VS 2013 and VS 2015 we removed the option to disable design-time analysis. Sounds like this is a request to bring that feature back.

[LeonidVasilyev]

I do not find syntax error squiggles that distracting because most of the time I pay attention to them only after I finish writing particular code snippet. But I can see where Stack Overflow OP is coming from. For experienced developer live error squiggles may look like false positives.

Is it correct that you can't disable design-time analysis using registry key? Can you do that using Language Service and Editor Extensions?

[jmarolf]

Is it correct that you can't disable design-time analysis using registry key? Can you do that using Language Service and Editor Extensions?

There is no way to disable analysis today.

[sharwell]

:link: I marked Bc42024 Visual Basic and VB.NET unused local variable as a duplicate of this issue.

[d4e666]

that is the worst issue with each new version of VS. the shitload of useless features that CANNOT be disabled. Your roslyn "experimantal" shit should be in the core, which is now an extension whilest a lot of "core components" like code analysis should be extensions. WHY DO YOU INSIS ON TAKING FEATURES FROM RESHARPER AND IMPLEMENTING THEM IN THE MOST CRAPPY WAY YOU CAN THINK OF??? is there a contest amongs your developers to create the most crappy version or something??? The fact that all your shit reaches us as end users means that your developers are aither too stupid to use VS themselves or to braindead to do their job propertly. I'M TIRED OF WASTING A SHITLOAD OF TIME WAITING FOR YOUR SHIT SOLUTION TO RESPOND AGAIN. A GENERATED file is a little too bijg and your shit hangs. even all your code generation tools keep on insisting to crap all out in a single file BY DEFAULT. How dumb can you be???

Thank god it's almost Haloween so your abominations become enjoyable, sarcasticaly speaking

[CyrusNajmabadi]

@d4e666 Would you be willing to collect some perf traces to help get to the bottom of any slowdowns you're seeing? Thanks!

[jmarolf]

As long as this does not interfere wothbmy active development sure

here is the guidance for getting a perf trace.

there are a lot of features I do not use

Under Tools -> Options you can disable CodeLens

Not a complete solution but hopefully it can get rid of some of the clutter for you.

[CyrusNajmabadi]

@d4e666 Here are the instructions on collecting and reporting perf issues: https://github.com/dotnet/roslyn/wiki/Reporting-Visual-Studio-crashes-and-performance-issues

This would be very helpful in terms of determining what is the root cause of the problem. Thanks!

and many "live detection" features like test code detection

'test code detection' can be disabled here:

and find thztvthis

Sorry... this is garbled. I don't know what this is referring to.

I don't like to pay for the 1 feature I do use whilst there are 10 I never use.

In general, the features which are costly can be disabled. If performance tracing reveals something that is an issue, but can't be disabled, we can add options for it. But without tracing, there's no way to know what the root cause is. For example, you mentioned you didn't like experiences pauses. However, there is no way to know (without a trace) what is causing that pause. It may be something in Roslyn. It may be something in Resharper. It may be something in some other extension you're using. If any of those end up using the UI thread in an inappropriate manner, you may experience pauses. We'll need the tracing data to know what's up.

Thanks!

[jaredpar]

@d4e666 your comment was hidden as it violates our code of conduct. Please keep future contributions in line with the COC or we may have to consider banning your account from this organization.

[CyrusNajmabadi]

@d4e666 Here are the instructions on collecting and reporting perf issues: https://github.com/dotnet/roslyn/wiki/Reporting-Visual-Studio-crashes-and-performance-issues

This would be very helpful in terms of determining what is the root cause of the problem. Thanks!

[terrajobst]

@d4e666

Since you ignored the warning I've blocked your account. We all have passion and want to see the right thing happen, but insulting and yelling at us isn't a productive mode of discourse. If you have any concerns, please contact conduct@dotnetfoundation.org.

[yotamoron]

Hi,

I'm running Visual Studio 2017 on a 32GB/i7/win10 machine.

Words cannot describe the slowness and frustration.

On each and every code change, it hangs. I see that the live code analysis is running in the background.

Is there a way to disable the live code analysis?

[jmarolf]

@yotamoron

here are some ways to disable features but there is no way to disable live code analysis.

I would really appreciate it if you could report a trace by following the directions here.

[MarcelChirtes]

Everything is off, beside the code analysis on build, but code analysis run in background when open/edit/save file (.cs) some times runs on a single file other times on all opened files.

Before, I had same setup on same machine Win10 64 + VS 2017 no problem, after reinstalling windows this issue appeared.

[MarcelChirtes]

Found a workaround, Code Analysis still runs at any action on opened file but editor is quite faster.

Tools -> Options -> Text Editor -> C# (in my case) -> Advanced -> Perform editor feature analysis in external process (experimental) Explained here: https://github.com/dotnet/roslyn/issues/26076

Another place that can cause slow code analysis might be included analyses from nuget packages.

I removed those AWSSDK analyzers.

[effyteva]

Hi, Is there perhaps an update on this issue? Disabling the Live Analyzers seems to be pretty basic feature which is currently missing.

[twest820]

I'd appreciate an update as well. There's a number of questions about how to opt out of live code analysis on Stackoverflow and some frustration that it's not supported. On Google, the top searches triggered by typing "Visual Studio live code analysis" are

• visual studio live code analysis slow
• visual studio live code analysis hangs
• visual studio live code analysis disable
• visual studio 2017 live code analysis slow
• visual studio 2019 live code analysis slow

On Bing, the corresponding top searches are

• visual studio live code analysis slow
• visual studio disable live code analysis
• visual studio 2019 live code analysis slow
• stop live code analysis visual studio

I've had various exchanges with the Visual Studio team on a number of incarnations of this issue since 2006. While live analysis performance on VS 2017 was acceptable on the solutions I work with I'm finding it intrusive with the VS 2019 nugets, to the point where it interferes with fundamental operations like scrolling. There also seem to be problems with either thread leaks or infinite loops which require Visual Studio restarts to recover from in 16.1.3. These are particularly tedious as having the CPU pinned at 100% predictably makes VS slow to exit.

I like live code analysis and find it quite useful but, during its episodes of poor behavior, it's not a feature which adds value. As such it seems appropriate to offer some form of opt out. While Code Analysis is being deprecated, something I think it gets right is its ability to run the ruleset on demand and get out of the way the rest of the time. It seems like this is currently semi-supported in that one can make a .ruleset file with few or no analyzers, switch projects to reduced .rulesets to duck some of the compute cost, and switch the projects back later. This is awkward and doesn't appear to be getting discovered by users. It also has the less than ideal result of opting out of warning level issues while retaining the overhead for information level issues like changing "out Foo ignored" to "out Foo _". It'd be valuable to have a design which preferentially allowed opting out of live informationals but still caught the more significant coding time concerns (e.g. missing Dispose() calls and CurrentCulture/InvariantCulture risks).

VS has had a model somewhat like this for CodeLens for some time. Personally, I opt out of CodeLens completely as it's too much of a drag on UX responsiveness but use find all references as a pay as you need it alternative regularly. I wouldn't really want to do this with live analysis but it'd be great if there was a way quickly move an entire solution between live analyses levels to manage background compute costs.

[bernesto]

There seems to be a lot of pain around this feature online doing a simple search.

Is it really difficult to just add a flag to just disable code analysis until roslyn is a bit more performant for those of us who wish to do so? For me, it kills my productivity with missed keystrokes and an unresponsive UI. A simple reg entry to turn it off would be appreciated!

[lauxjpn]

Especially for the folks that use R# for productivity, Roslyn has a huge impact on general performance in VS. There are moments, where VS just hangs, mouse clicks take a second or two to get recognized, typing lags etc. (that's with Windows Defender already disabled). And it gets worse with every major version change.

I understand, that Roslyn is a needed feature for general VS users, but for Resharper users, Roslyn's analysis is just a nuisance, kills your productivity and brings nothing new to the table that Resharper doesn't at least provide as well.

Obviously, the VS team is well aware of the performance problems, because they implemented this nice little yellow info bar, that tells you every couple of seconds, that Resharper is to blame. The truth is though, that VS and Resharper worked fluently together until Roslyn came along. That Roslyn and Resharper are now competing for resources is obvious and it should be left to the user, which refactoring platform to use.

So until Roslyn can fully replace Resharper, the option to disabling as much of Roslyn's analysis as possible, is a highly needed feature.

Is this on the agenda of the team, or can the pros and cons or possibilities be discussed here @CyrusNajmabadi @sharwell ?

[sharwell]

@lauxjpn We work hard to fix all cases that get reported with traces that we can investigate. You can find the instructions here: https://aka.ms/reportPerf. Unfortunately, the number of different user configurations is almost unimaginatively gigantic, so there is no realistic way for us to confidently address your specific scenario without the additional information. Each release tends to behave like this:

1. Most people get performance that is slightly better
2. A few people get performance that is worse (there are always new cases we didn't account for)
3. A few people get performance that is much better

Most people who move from the first category to the third category do so because they were able to capture the scenario in a way that allowed us to focus our investigation on it.

[sharwell]

This issue is likely to be addressed as part of #38429.

[ant-222]

I for one need to disable live code analysis not because it is slow (which it is) but rather because it is so annoying when VS complains about a missing return statement before I have finished typing the function. It makes me miss good old VS 2008 that checked my code when I told it to.

[CyrusNajmabadi]

It makes me miss good old VS 2008 that checked my code when I told it to.

vs2008 certainly checked many things in a live fashion. It didn't check more primarily due to limitations in the implementation which made narrow and incremental checking hard. But it would give live errors for all sorts of things :)

That said, i have no problem with an option to disable live editor squiggles. Either as a specific option, or as part of a larger "lightweight editing" mode. Tagging @mavasani for context as he's been looking into this.

[mavasani]

Yes, we are actively planning for some top level option(s) or a more fine grained knob with multiple settings which would allow users to customize their preferred mode of operation and background analysis.

[CyrusNajmabadi]

@mavasani Thanks!

[mavasani]

Update

This feature requested has been implemented for VS2019 16.5 release. Let me summarize a few things here for clarity.

What is "Live Code Analysis" for Managed projects?

Visual Studio executes a bunch of background analyses while you are editing source files in the editor. Some of this is required minimal analysis for acceptable IDE editing experience, some of this is to improve responsiveness for IDE features by proactively analyzing closed files in the solution and some of this is to enable additional rich functionality (such as IDE code style suggestions). Based on the functionality, the analyses can be bucketed as follows:

1. Background computation of diagnostics (errors/warnings/suggestions):
   1. Compiler diagnostics
   2. Roslyn analyzer diagnostics (built-in IDE analyzers for code style suggestions + analyzer NuGet packages installed for project)
2. Other background analyses: For example, background parsing of open files, background compilation of projects with open files to realize symbols for improved responsiveness of IDE features, building syntax and symbol caches, detecting designer association for source files (like forms, controls, etc) in projects, etc.

Feature requests

1. Allow me to configure if, when and how Roslyn analyzers execute in the IDE - this issue (https://github.com/dotnet/roslyn/issues/24513). By default analyzers always execute during live analysis + build. However, I would like to choose from one of the following workflows (there may be more):
   1. Execute analyzers only during build
   2. Execute analyzers only with an on-demand "Run Code Analysis" command, but not during live analysis and/or build.
   3. Execute analyzers with reduced scope for live analysis (i.e. only current document OR open documents) and execute them for a broader scope (specific project or entire solution) with an on-demand "Run Code Analysis" command whenever I wish to run analyzers.
2. Allow me to configure IDE to work at minimal background analysis - https://github.com/dotnet/roslyn/issues/38429.

Support added in VS2019 16.5

1. For https://github.com/dotnet/roslyn/issues/38429: Users can now explicitly change the scope of all Roslyn based background analysis to current document from Tools Options. This includes all diagnostics computation. Note that the default scope is "Open Documents and Projects"

2. For https://github.com/dotnet/roslyn/issues/24513:
   1. Users can now explicitly choose to opt out of analyzer execution during build and/or live analysis from the Code Analysis project property page. Starting VS2019 16.5, the Run on live analysis checkbox on that property page is a per-user option that gets written to a .csproj.user file and is also respected for built-in IDE analyzer execution. However, if the configuration is a repo preference instead of a personal user preference, you can configure this at a solution level Directory.Build.props with the MSBuild property RunAnalyzersDuringLiveAnalysis.
   2. Users can now execute Run Code Analysis command to perform on-demand analyzer execution from top level Build menu or top level Analyze menu or from the Analyze and Code Cleanup menu by right clicking the project/solution node in solution explorer. Prior to VS2019 16.5, this was used to run legacy FxCop analysis, but this command now runs Roslyn analyzers.

Combining the above features, users can choose any of their preferred code analysis workflows for analyzer execution OR configure scope for all the Roslyn based background analysis.

We will ensure that the above support is documented when VS2019 16.5 is released. We will look forward to any further feedback on code analysis configuration support once these features are available.

[Mrsevic]

@mavasani I've downloaded VS 2019 Preview and I do not see the selected options. Will they be available in one of the future builds?

Thanks

[mavasani]

@Mrsevic Yes, this is not yet available and will be first available in VS2019 16.5 Preview2, which is the next preview.

[Mrsevic]

Thanks.

[drvic10k]

@mavasani current build is 16.9 and this is still not in

but it looks like the live analysis was turned off by default somewhere, because from one of the recent updates I get warnings that the SuppressMessage is not needed although after removing it I get CA errors on build Also it's not possible to add suppress message from the error window or from the code (in the code it's not even whowing the error)

[sharwell]

@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.

[drvic10k]

@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.

ok, I created a new issue: https://github.com/dotnet/roslyn/issues/51884 but unfortunatelly I cannot specify any more details

[levicki]

Combining the above features, users can choose any of their preferred code analysis workflows for analyzer execution OR configure scope for all the Roslyn based background analysis.

To me the bolded part of the above statement doesn't seem to be true.

Not sure if this is still the case but if I have to customize analyzer execution per user, project, or solution every time I create a new project instead of having a global off switch in the Visual Studio preferences then I cannot really choose my preferred code analysis workflow.

Frankly, I conside live code analysis premature and very annoying because it suggests things that are outright retarded. For example "Remove unused function / variable" for a function / variable that was just added, not to mention that there were cases where it incorrectly suggests something is unused when it cannot properly deduce that it actually is.

If you really want this to be intelligent, then maybe give user some time to put the function / variable to use before saying it is unused. You are just pointing out the obvious because I know it is unused when I just added it. You are making noise which makes it harder to distinguish real cases of unused things in code against things that we didn't yet get to use.

What I fail to understand is why people designing Visual Studio user interface never thought of copying Adobe Photoshop workspaces? Why for example I can't have a set of workspace presets to choose from a dropdown menu like this:

1. Coding (I am writing code and I only want to be informed of problems when I hit Build)
2. Debugging (Hit me with all possible static code analysis and threading correctness checks you have)
3. Refactoring (Hit me with all possible recommendations for design and code security)
4. Custom (Allow me to choose my own combination)

What is important is for this to be global, not per user, not per project, not per solution -- there are still a lot of individual developers who don't have to conform to anything other than to their own standard. You just keep ignoring individual developers by only making all those feature controls suitable for teams.

[CyrusNajmabadi]

not to mention that there were cases where it incorrectly suggests something is unused when it cannot properly deduce that it actually is.

Please file issues on this. Thanks.

[levicki]

Please file issues on this. Thanks.

At least one such issue was already reported by someone else via VS Feedback. Granted, that was a while ago so maybe it was fixed by now.

What I sincerely hope is that the rest of my comment at least prompts you guys to evaluate future design decisions from the viewpoint of individual developers as well.

My personal pet peeve are software components that cannot be uninstalled, and features that cannot be globally disabled. Maybe, just maybe, try to be less forceful in your "one size fits all" pursuit in the future? That would be much appreciated.

[CyrusNajmabadi]

At least one such issue was already reported by someone else via VS Feedback. Granted, that was a while ago so maybe it was fixed by now.

It's still helpful to file, even in that case. It's possible it was missed, or there is something unique about your situation. If we have a repro we can find out. If it turns out it was fixed, in the worst case we dupe the issue. In hte best case, we find something unknown that we can fix!

[CyrusNajmabadi]

Maybe, just maybe, try to be less forceful in your "one size fits all" pursuit in the future? That would be much appreciated.

We're not unaware of this. We just have to balance a lot of complexity here. The matrix around around supporting all these configs is non trivial and will substantially impact our ability to deliver features that have broader value and more demand. We Have to make hard looks at all teh things requested, and it will often mean decisions and directions that are not ideal for some subset of the ecosystem.

[CyrusNajmabadi]

and features that cannot be globally disabled.

Note that we do support disabling these analyzers with several approaches. We don't have a totally global approach. But you can use .editorconfig at the root of your solution to disable there.

[levicki]

The matrix around around supporting all these configs is non trivial

I agree.

However, I fail to understand how providing a global switch in the user interface where it is more convenient for the user to just flip it is harder than providing three different ways to configure the same thing by said user having to edit a textual config file in 2021?

I understand that those config files are needed for CI/CO and automated builds, but manually editing config files shouldn't be a thing in 2021 in a productivity tool such as Visual Studio.

But you can use .editorconfig at the root of your solution to disable there.

Sadly, that approach often doesn't seem to be working very well (for example my VS 2019 install just doesn't do anything when I click to add a rule to my existing .editorconfig without showing any feedback whatsoever), you cannot even copy the name of the analyzer you want to disable and I am not aware of a page documenting them all, not to mention that I have no idea where to report bugs related to .editorconfig processing.

[CyrusNajmabadi]

However, I fail to understand how providing a global switch in the user interface where it is more convenient for the user to just flip it is harder

It was harder because it creates a lot of confusion to users about which system controls what, and what should have priority when specified in multiple places. We're moving primarily to editorconfig for pretty much all these cases as it allows for a singular file-based source of truth.

by said user having to edit a textual config file in 2021?

First, textual config is not a negative. It provides a lot of value that people understand and desire over registry-based-config. Second, we are making a UI for this which was added in https://github.com/dotnet/roslyn/pull/51069 and which will be in teh next version of VS.

but manually editing config files shouldn't be a thing in 2021 in a productivity tool such as Visual Studio.

It won't be. But, like all things, these things take time and engineering effort. The suggestions you have made would also take time and effort as well, so nothing is going to get to a better state without that happening.

Sadly, that approach often doesn't seem to be working very well (for example my VS 2019 install just doesn't do anything when I click to add a rule to my existing .editorconfig without showing any feedback whatsoever)

Please file an issue on this.

and I am not aware of a page documenting them all,

We have been trying to document all Roslyn-Analyzer cases over at https://docs.microsoft.com/en-us/dotnet/fundamentals/code-analysis/overview and https://docs.microsoft.com/en-us/dotnet/fundamentals/code-analysis/categories

However, we also just support simply disabling any rule just using it's ID in editorconfig. So given the ID (what you see in the error message like IDE1234) you can just ask for that entire rule to be disabled.

[CyrusNajmabadi]

not to mention that I have no idea where to report bugs related to .editorconfig processing.

Please file them here. Either they apply to us, and we can fix, or we can forward to whatever other team owns that scenario.

[levicki]

It was harder because it creates a lot of confusion to users about which system controls what, and what should have priority when specified in multiple places.

That's the problem with having the settings strewn about in different places to begin with. It is as if the features were just being tossed in without consideration of logical organization.

We're moving primarily to editorconfig for pretty much all these cases as it allows for a singular file-based source of truth.

Really? That's good to hear.

First, textual config is not a negative.

Not on its own I agree.

However, can you tell at a glance what this line from .editorconfig does?

dotnet_diagnostic.IDE0058.severity = none

You understand it is changing severity of some diagnostic, but you have no idea which one unless you memorized the numbers. That's not user friendly or human readable at all.

It provides a lot of value that people understand and desire over registry-based-config.

Funny that you mention this, when Visual Studio insists on having its hidden app registry which is not accessible using normal registry editor in Windows. I hope that gets changed as well, it's just needless obfuscation at this point.

Second, we are making a UI for this which was added in #51069 and which will be in teh next version of VS.

That is also good to hear. Hopefully I will soon be able to edit one single .editorconfig in my projects root folder if I so desire.

We have been trying to document all Roslyn-Analyzer cases...

Thanks, I will check it out. What I find curious is that you don't provide an empty set of code analysis rules so we can select that to disable analysis in the project. That would be a trivial thing to add I guess.

However, we also just support simply disabling any rule just using it's ID in editorconfig.

I never heard that is possible and I do read Release Notes for each update and blog posts occasionally, what is the exact syntax for this? Please provide an example.

[CyrusNajmabadi]

That's the problem with having the settings strewn about in different places to begin with.

That's why we're unifying on editorconfig as it's what the ecosystem as a whole seems to be converging on.

However, can you tell at a glance what this line from .editorconfig does?

Yes. It sets the severity for the ID to none.

You understand it is changing severity of some diagnostic, but you have no idea which one unless you memorized the numbers. That's not user friendly or human readable at all.

This is what we have teh UI for. To give human readable names here. It's also something you could put directly in the file as a comment if that's really critical for you. i've also suggested that the UI tool do this.

[CyrusNajmabadi]

What I find curious is that you don't provide an empty set of code analysis rules so we can select that to disable analysis in the project

I'm not sure what you mean by that. Can you clarify?

[CyrusNajmabadi]

I never heard that is possible and I do read Release Notes for each update and blog posts occasionally, what is the exact syntax for this?

https://docs.microsoft.com/en-us/visualstudio/code-quality/use-roslyn-analyzers?view=vs-2019#configure-severity-levels

The relevant value is:

[levicki]

Yes. It sets the severity for the ID to none.

Yes but you cannot infer from the ID that it controls "Use discard" rule.

Why not just use lowercased rule names instead of IDs like you use for style rules already? For example, instead of:

dotnet_diagnostic.IDE0060.severity = none

Use:

dotnet_diagnostic.remove_unused_parameter.severity = none

And instead of prefixing a bunch of lines with dotnet_diagnostic:

dotnet_diagnostic.remove_unused_parameter.severity = none

Why not just make a section / table in the config file?

[dotnet_diagnostic]
remove_unused_parameter.severity = none

You could also drop the .severity qualifier unless there are other qualifiers I am not aware of. Here is how the .editorconfig would look if I were designing it:

[dotnet_diagnostic]
remove_unused_parameter = none

I'm not sure what you mean by that. Can you clarify?

What I mean is to provide an empty ruleset in C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Team Tools\Static Analysis Tools\Rule Sets by default so we can select it in project properties as a quick way of suppressing all rules in the project:

<?xml version="1.0" encoding="utf-8"?>
<RuleSet Name="Empty Ruleset" Description="" ToolsVersion="10.0">
</RuleSet>

The relevant value is...

Yes, but that page does not seem to suggest that it is possible to just write:

IDE0060 = none

Or did I misunderstand what you were saying?

[sharwell]

Yes but you cannot infer from the ID that it controls "Use discard" rule.

All of our tools should be generating a comment for this:

# IDE0060: (message)
dotnet_diagnostic.IDE0060.severity = none

We're acutely aware that this is not perfect and are considering alternatives. We have to carefully weigh each option because this will not be the first or second time this has changed, and the more times we change it the more confusing the whole thing is.

[CyrusNajmabadi]

Yes but you cannot infer from the ID that it controls "Use discard" rule.

As mentioned above, the UI we have has this. Furthermore, i've pushed heavily that we should ensure the editorconfig is self documenting by way of things like comments stating what this applies to.

it's just needless obfuscation at this point.

I'm not sure what this is referring to. It may be the separate hive system that exists to make it possible to ahve VS instances run SxS without issue. But in that case it's not needless :)

Why not just use lowercased rule names instead of IDs

From teh compiler perspective, these IDs are all it sees and knows. The API around diagnostics is built around these IDs, not necessarily the multiple potential named strings that could affect them.

The ID is actually a benefit here as the moment you get a diagnostic from any source, you can disable purely based on that. Otherwise, you'd have to map back from an error to the arbitrary config string needed to disable it. :)

Why not just make a section / table in the config file?

I don't think this is in scope for this discussion. The particulars of the file format aren't that relevant IMO. Furthermore, it would be problematic to change that now as this has already shipped as a first class mechanism that is documented for this purpose.

Yes, but that page does not seem to suggest that it is possible to just write:

Yes. I think you'd need to write the longer form. I think that is acceptable, esp. as there is a UI now that will generate that for you. :)

[levicki]

I'm not sure what this is referring to. It may be the separate hive system that exists to make it possible to ahve VS instances run SxS without issue. But in that case it's not needless :)

It is referring to the fact that some other configuration options are also apparently stored in that separate hive system (such as option to control extension updates, etc) -- that's what is obfuscated and what could be in the regular registry.

The ID is actually a benefit here as the moment you get a diagnostic from any source, you can disable purely based on that. Otherwise, you'd have to map back from an error to the arbitrary config string needed to disable it. :)

But right now I have to map from an arbitrary config ID back to an error? How is that better?

It's the Visual Studio who should be mapping a human readable identifier (such as remove_unused_parameter) in the config file (and in a diagnostic message) to an internal ID (such as IDE0060) and back, not the user.

As long as the ID is what is stored in the config file and as long as said file is meant to be edited by users it is the user who is doing the mapping in their head.

If you are storing non-descriptive error IDs in the textual config file you might as well use a binary file and save some space as well as time spent parsing strings.

We're acutely aware that this is not perfect and are considering alternatives.

Good to hear it.

We have to carefully weigh each option because this will not be the first or second time this has changed, and the more times we change it the more confusing the whole thing is.

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? There is an excellent TOML parser library written in modern C++ available here.