New for Visual Studio 2008 - Spelling rules
Surprisingly, one the biggest requests for Code Analysis in Visual Studio 2005 was to include the spelling rules that shipped with the FxCop standalone. We had Microsoft consultants tell us that they actually had trouble moving some customers from FxCop to Code Analysis because they were not included. Apparently teams care about spelling. :)
Well, we've listened and I'm glad to tell you that we are shipping the following rules in Visual Studio 2008:
IdentifiersShouldBeSpelledCorrectly
CompoundWordsShouldBeCasedCorrectly
ResourceStringsShouldBeSpelledCorrectly
ResourceStringCompoundWordsShouldBeCasedCorrectly
These new rules (along with the rest of the previously FxCop-only rules) now cause the analysis in Visual Studio 2008 to become a true superset of what is available in FxCop.
API Rules
By default, the IdentifiersShouldBeSpelledCorrectly and CompoundWordsShouldBeCasedCorrectly, which both fire on the naming of API members, use the installed language of Visual Studio to determine the locale to spell check the identifiers in. To customize this, simply add the <CodeAnalysisCulture> MSBuild property to your project with a culture representing the language of the API you are writing:
It is advisable to explicitly specify above when you have developers working on different languages versions of Visual Studio. Unfortunately, due to some complex licensing reasons, we were only able to ship the English lexicons so only the English-based (en-US, en-GB, en-CA and en-AU in particular) cultures actually affect the spell checker. All other cultures cause the rules to silently disable themselves.
Resource Rules
The <CodeAnalysisCulture> property is used to indicate the language of your API identifiers; it is not, however, used to determine the language of your ResX-based resources. Instead, for these we use the same mechanism that the runtime uses (or more correctly, what the ResourceManager uses) to locate resources; the AssemblyCultureAttribute and the NeutralResourcesLanguageAttribute attributes. The former is applied to satellitte assemblies and should never be placed on an assembly with code. Whereas, the later is applied to an assembly with code to indicate the neutral culture of the assembly. These attributes are simply applied at the assembly level and are usually placed in each language's associated AssemblyInfo.cs/AssemblyInfo.vb file. The same cultures as above are supported.
Without one of these attributes on your assembly, the resources contained within it will never be checked by ResourceStringsShouldBeSpelledCorrectly and ResourceStringCompoundWordsShouldBeCasedCorrectly. Luckily, If you forget to apply the attribute, Mark assemblies with NeutralResourceLanguageAttribute, a new performance rule we've added, will remind you.
As you start to running the spelling rules - you might find that you need to add to the list of words that it recognizes - in the next post I will talk about the new custom dictionary support that we've added to Visual Studio 2008.
