The code analyzer cannot add words to ignored words files or user dictionaries

[EWSoftware]

There don't seem to be any provisions for modifying files outside of the containing project of the file on which the code analyzer is running. While it may be possible to add support for ignored words files within the project using the Additional File Items feature, this is rather cumbersome as the ignored words file would have to be added to every project in the solution. Not a problem if there's only one or two but a real issue for large solutions with a large number of projects. The preferred approach is to put the ignored words file in Solution Items but it doesn't seem to be accessible there. Likewise, there don't appear to be any provisions for modifying files outside of the project system (an ignored words file in the global configuration and user dictionary files).

If anybody knows more about how this could be made to work, I would appreciate the help as I haven't been able to figure out a solution.

[djurodrljaca]

Is this the reason that there is currently no convenient way for adding words to the ignore list? From what I noticed you need to manually add the words you want to ignore to the spell checker settings...

[EWSoftware]

For identifier misspellings, yes. For strings and comments, it's done using the tagger so works as it always has.

[robertson-bauercontrols]

To rehash an already closed item, is losing the ability to add\ignore words in the source code worth the balance of having the errors show up in code analysis?

My question: Is it possible for me to disable the code analyzer stuff in my .editorconfig, and have it spell check the code in the same fashion it does with comments in the same files? That way my team can have a consistent user experience with spell checking comments vs code, and not have to do two different things.

Thanks!

[EWSoftware]

Turn off the code analyzer option in the general settings category. You can do it in the global configuration or by an .editorconfig in a specific solution or project.

[smaillet]

I'm late to this party, but I'm confused why this is considered a hard/difficult problem... It's not the analyzer at issue here, it's the "fixer". The fixer, ideally, would offer two options:

1. Change the spelling of the syntax element in question
2. Add the word in question to the ignored words list and move on.

Either option would result in updates to the results of the analysis.

For #2 the fixer can access the settings for the analyzer, which includes the location of the dictionary. (per project OR global) and then the fixer can manipulate that file. (See: https://www.mytechramblings.com/posts/configure-roslyn-analyzers-using-editorconfig/) for info on accessing the configuration file and settings for the analyzer.

[EWSoftware]

@smaillet "Analyzer" here is being used to refer to both the analyzer and fixer as a set. Finding the files isn't the problem. As noted in the original post modifying them is. At the time I originally implemented this, the usual .NET file I/O APIs were banned and the analyzer and fixer projects wouldn't even build if you tried to use them from within either. The only way to change files is through the code analysis APIs which only work on files in the current project. So, while you can find them through the configuration settings, files outside of the active project such as at the solution level or global ignored words/user dictionary files could not be modified. If that's changed in the past couple of years, I can revisit this.

[smaillet]

Ah, that explains my confusion as it wasn't clear what the problem was.

Hmm, well "banned" is a strong word (and one I think the Roslyn team has misused). You can of course suppress such a warning. It is generally important to "know the rules so you can decide when to break them!". I'd argue this is a perfectly legit thing to do in a fixer in this case. The rule exists to prevent non-deterministic output from the fixer as that makes things more difficult to process/test. But the whole point of this particular feature is to be non-deterministic in that sense. [The fix is to legitimately modify an external file].

[EWSoftware]

Thank you for pointing that out! The fact that it showed as an error and the wording made me think it was blocked and just couldn't be done. It seems obvious now but it didn't occur to me to just suppress it like a normal suggested fix since that didn't seem like an option at the time based on how it was presented. It makes sense for code changes but for this, it's a valid case for ignoring it. I'll see about adding support for it.

[EWSoftware]

So, I took another look at this and as it turns out, I was misremembering what the actual issue was. In short, it is a case of not being able to modify files outside of the project system but not because of the banned APIs. There is just no way to modify a non-code file within the context of a code action because they don't have a syntax tree that can be modified and applied later if the user choses to execute the action. You can't just write to the file directly in the called code action method as it is called to get a preview of the changes and there's no way to defer the actual update to the file in those cases.

I was able to get a partial implementation as long as the file is part of at least one project, but it requires it to be of a specific build action and has to remove and re-add the file to the project in order to make it work within the code action. Unfortunately, that has the side-effect of removing the required build action and it no longer sees the file for other updates to it.

So, back to square one.