This time, I will write something about what new CA rules or modifications Visual Studio 2008 brings.
As a first topic, I will mention that CA engineers included four new rules concerning spelling, which actually existed in standalone FxCop. These four new rules fall into two sets : rules regarding resources and those regarding managed code. And also, they concern two aspects of naming conventions: spelling and casing checking:
- CA1704: IdentifiersShouldBeSpelledCorrectly
- CA1702: CompoundWordsShouldBeCasedCorrectly
- CA1703: ResourceStringsShouldBeSpelledCorrectly
- CA1701: ResourceStringCompoundWordsShouldBeCasedCorrectly
By default, spell checking for that purpose relies on installed version of Visual Studio 2008. For the sake of finding the proper language of your API identifiers, you are allowed to put the attribute inside project file (.csproj or .vbproj) in PropertyGroup section to enable your particular culture:
Visual Studio 2008 puts one assembly attribute automatically inside the assembly manifest file (AssemblyInfo.cs) regarding resource localization. It tells to code analysis that this specified language should be considered when doing the spell checking of resources.
The parameter value is empty by default, but you can change it as you like. Well, not exactly with the result if it is not english language, because all other cultures cause the rules to silently disable themselves ! (only en-US, en-GB, en-AU lexicons are currently supported). The same goes for the managed code checking.
There is one more rule which is added to enforce those the rules for resource checking:
- CA1824: MarkAssembliesWithNeutralResourceLanguageAttribute
It will remind you that you haven’t set your assembly’s attribute to the culture you need.
The point is, spelling checker is really great if the words are always in english (up to now there are no more supported languages) and you do want to enforce english language as your default. But, this is not always like that. Consider the case when you work on a really specialized software with dozens of words in some kind of engineering or financial slang. Or if you work on a project which actually ships to some foreign culture and bases on its phrases and words. Finally, I got a warning because my company name is used somewhere in the classes and this word was not recognized. In any case, you would wind up with lots of spelling warnings to solve. There is a way to avoid this, and this is to use your own custom dictionary. It is quite easy to do and I will explain it shortly.
First, create one empty XML file and add it to your project. Name it as you like. Make sure that it has a structure like this:
<?xml version=“1.0“ encoding=“utf-8“ ?>
Fill Words elements with your words unrecognized by CA engine. Don’t worry, the words you enter are treated as case-insensitive so just put it as you like. Right-click this XML file to display its properties and choose CodeAnalysisDictionary as Build Action. After building the project, CA warnings 1702 and 1704 should vanish.
Just to say, after you build your project, the following lines will be added to your project file:
<CodeAnalysisDictionary Include=“MyDictionary.xml“ />
There is a possibility to share these settings over multiple projects. Create a dictionary file as I’ve described you. Put the dictionary file to a shared location (e.g. inside the Solution Items folder). Add this file as a link to all required projects (when you adding an existing item from the project menu, you should select Add As Link option). After that, all these projects will consume your custom CA dictionary.
When LINQ appeared, it posed a great risk in terms of not obeying the standard rules of tidy coding. This is because it relies on anonymous types and lambda expressions which are, by default, are not CLS-compliant in terms of naming and style conventions. Nevertheless, they are underpinnings of Linq and provide simple and flexible sintax in writing code.
Actually, Visual Studio 2005 didn’t check them at all. After release of Visual Studio 2008, there are several bugs addressed to lambda expressions and anonymous methods, but they are scheduled to be fixed. Also, any project making heavy use of lambdas/anonymousse is not considered to be clean anymore (as CA team states itself).
The reason for adding this rule is that a bug was found on applications which explicitly targeted .NET Framework 2.0 and .NET Framework 3.0 to take a dependency on a new member or type which didn’t actually exist in the RTM version of that framework. As a workaround, the rule is added to warn a user that this is detected on a source code:
- CA1903: UseOnlyApiFromTargetedFramework (in Portability Rules)
To resolve this warning, a project’s Target Framework has to be selected on which you plan to release your application. You can change this setting by right-clicking the project in Solution Explorer, and then navigate to Application tab inside project’s properties. You can choose between: .NET Framework 2.0, .NET Framework 3.0, and .NET Framework 3.5:
For the end, I briefly summarize Target Framework and Service Pack Dependencies in the table below. You can find additional information about this on the MSDN.
|When target framework is||Fires on usages of members introduced in|
|.NET Framework 2.0||.NET Framework 2.0 SP1, .NET Framework 2.0 SP2|
|.NET Framework 3.0||.NET Framework 2.0 SP1, .NET Framework 2.0 SP2,
.NET Framework 3.0 SP1, .NET Framework 3.0 SP2
|.NET Framework 3.5||.NET Framework 3.5 SP1|