I posted almost a year ago about using custom dictionaries for spell checking in code analysis. At the time, it seemed like a good idea to modify the custom dictionary in C:\Program Files\Microsoft Visual Studio 9.0\Team Tools\Static Analysis Tools\FxCop so that any code on the machine will be evaluated against that dictionary. I’m now starting to swing away from this idea.

Having a custom dictionary in one spot on the machine is a good because any solution you use on that machine will adhere to that dictionary. The problem in a team environment is that the custom dictionary is not in source control. Any new dev machine will not have those changes and is likely to fail code analysis. Build servers will also suffer a maintenance nightmare with their custom dictionary as it will need to support all possible solutions being built, not just the ones on a particular dev machine.

If you swing to the other extreme, suppressing spelling failures in code is messy, but is in source control for other developers and build servers to benefit from.

I am working with a new model that is the middle ground of these two extremes.

I noticed a while ago that Visual Studio now contains more build actions for files in a project. One of them is CodeAnalysisDictionary. This becomes very helpful.

My new method of satisfying spell checking in code analysis is to have my custom dictionary checked into source control. This usually means that the xml file will be located in the same place as the solution file.

The first thing to do is add the custom dictionary as a solution item.

This makes it easy to open, check out, edit and check in this file without having to go through Source Code Explorer to do a manual check out, edit, check in cycle. It also means that it is part of the solution in the Pending Changes dialog when check in files are filtered by the current solution.

Next, we need to associate this single custom dictionary with all of the projects in the solution. We do not want to copy this file between the projects as this would still be a maintenance nightmare. Visual Studio is kind enough to have a file link facility. In each project, open up the Add Existing Item dialog, find the custom dictionary and add it as a link.

This will then add this file as a link to the project. You will notice that the overlay of the icon in Solution Explorer also indicates that this file is a shortcut to another location.

Open up the properties on this file, and select CodeAnalysisDictionary as the Build Action for this xml file.

As you compile the application and run code analysis, this custom dictionary will be referenced.

The advantages of this solution are:

• Under source control so it is accessible to all developers
• Under source control so it is accessible to team build servers
• It contains only custom dictionary entries that are related to the projects that reference it
• Common to all projects in the solution
• Common to all projects in a TFS project/branch depending on TFS project structure
• Easily updated and checked in
• Visible to developers who use the solution

The disadvantage of this solution is:

• The custom dictionary may need to be duplicated for each solution/TFS project