This topic covers some common problems that you may encounter while using the solution/project spell checking tool window.
If a file is currently open in an text editor, the spell checker will make an attempt to get the file's current content from the text editor rather than using the content on disk. This allows it to spell check the active content including any unsaved edits. However, custom file editors such as form designers, XAML designers, resource file editors, etc. may not provide a means of obtaining the current text content for the file. In such cases the file's content will be read from disk and spell checked. Any spelling issues in unsaved content will not be detected until the file is saved and the spell checking process is ran again.
As mentioned, when an issue is corrected, the tool window will open the file in a text editor window. If a custom editor is open for the affected file and it does not support opening a related text editor view, you will be prompted to close the custom editor first. If you choose not to do so, the correction operation is canceled. Some editors such as the resource file editor do support opening a related text editor view of the file. In such cases, making changes to the text editor will update the related custom editor.
In cases where the content on disk contains issues but differs from the unsaved content, you may be told that the issue cannot be corrected because the text has been changed at the issue's location. Save any pending changes to open files and rerun the spell checking process to obtain accurate results based on the up to date content.
When an issue in the solution/project spell checking tool window is corrected, it will automatically adjust the location of any other issues in the same file based on the change made. If you make any other changes to the file's content or use the active document tool window or smart tags to fix issues, the solution/project spell checking tool window will be unaware of those changes. If you subsequently attempt to correct an issue in which the text at the issue's location no longer matches the word, you will be notified that the change cannot be made. The file will be opened and the cursor positioned at the issue's prior location. If you can find the issue relative to the old location, you can correct it manually. To get the solution/project spell checking tool window back in synch, rerun the spell checking process.
The solution/project spell checker uses a different method of classifying text to find items that it needs to spell check. The spell check as you type and active document spell checking tool windows rely on the classification spans provided by the text editor. The solution/project spell checking tool window relies on its own internal text parsers to classify text based on the file type. As such, this may result in differences between what is reported by it and the spell check as you type and active document spell checking tool window.
A common difference is doubled word detection. The interactive spell checkers cannot detect doubled words across line breaks as typically, the spans provided by the editor are limited to a single line of text. However, the solution/project spell checker can detect doubled words across line breaks. As such, you may see a reported doubled word issue in which there doesn't appear to be a doubled word in the text column. In such cases, the doubled word is typically at the start of the line and the first word is at the end of the prior line which is not shown. You can use the Go To Issue option to verify that this is the case and handle the issue accordingly.
The solution/project text parser may report issues incorrectly under certain conditions. For example, it relies on a series of regular expressions to find text that appears to be comments and literal strings. If the text in a source code file is formatted in such a way that a mismatch occurs and it is classified as something that it is not, you may see incorrect issues reported. An example may be a comment delimiter sequence that appears withing a literal string. See the closed and open issues lists to see if the problem has been reported as noted above. It may be possible to adjust the classifiers to handle some cases.
In many cases, a large number of non-words will be reported as misspellings. Examples include format strings in designer files, CSS class names, control names, etc. You can sometimes reduce the number of misspellings for such non-words by defining exclusion expressions in the spell checker configuration file. See the Exclusion Expressions topic for more information and some examples.
A common occurrence in designer code, especially in Windows Forms projects, is words that get split across string literals (i.e. "A string of text that gets separ" + "ated by the designer"). When spell checking the solution or a project, such occurrences are joined to form a proper word before spell checking to reduce the number of false reports caused by the separate parts. If a split word is genuinely misspelled, it will get reported. However, the tool window will not allow the word to be fixed from within the tool window. Instead, navigate to the issue and fix it manually. This is done on purpose to prevent the tool window from altering the layout of the string in the designer file.
As mentioned, the solution/project spell checking tool window uses its own set of classifiers to parse each file's content accordingly based on the determined file type. An attempt has been made to provide support for as many common file types as possible. However, the Visual Studio ecosystem is quite large and there are many languages and/or file types that may not be handled at the present time. As a fallback, the parser will attempt to treat any unrecognized file types first as XML if they appear to contain XML or, failing that, as plain text.
If you see a file in which a large number of issues are reported that appear to be code or other such elements, it is quite possible the file or at least part of its content is being treated as plain text because it was not recognized. See the closed and open issues lists to see if the problem for the given file type has been reported as noted above. You can also use the information found in the Defining Solution/Project Spell Check Classifiers topic to define a new classifier for any unknown file types. If you do so, feel free to submit these new classifications by opening a new issue so that they can be included in a future release.
The current HTML classifier should handle most HTML content without issue. In addition, it attempts to parse server-side script elements (i.e. PHP code, ASP.NET and Razor script blocks, etc.) as well as client-side inline script elements using the appropriate language classifier. If you find that it is not reporting issues in some content or is not handling certain sections of a file appropriately, please open an issue and provide as much detail as possible along with example content. An attempt will be made to handle issues as they occur and include fixes in subsequent releases. Please bear in mind that web development is not my area of expertise so help may be required in resolving some issues.