Dave's Box : FxCop, Compatibility

BUG: Multi-targeting rule not firing on usages of 2.0 SP2 and 3.0 SP2

David Kean — Sat, 29 Nov 2008 15:00:09 GMT

Previously, I've spoken about the new multi-targeting rule that shipped in Visual Studio 2008 SP1 and FxCop 1.36. This rule helps to prevent users from inadvertently taking a dependency on a .NET service pack. Unfortunately, it shipped with a bug that when targeting .NET 3.5, prevented it from firing on usages of types and members only available in .NET 2.0 SP2 and .NET 3.0 SP2 (both installed by 3.5 SP1).

Luckily, the fix is rather simple.

In Visual Studio 2008 SP1:

From an elevated (right-click and Run as administrator) Visual Studio command-prompt, type the following and press <ENTER>:

devenv "%PROGRAMFILES%\Microsoft Visual Studio 9.0\Team Tools\Static Analysis Tools\FxCop\Repository\Compatibility\Desktop2.0SP2.xml"

In the <CompatibilityEntry> element in the file that opens, change the Priority attribute from 3015 to 3515:

<CompatibilityEntry Name=".NET Framework 2.0 Service Pack 2"
                    Platform="Desktop" 
                    Version="2.0.2" 
                    Priority="3515">

Save the file.
From the previously opened command-prompt, type the following and press <ENTER>:
devenv "%PROGRAMFILES%\Microsoft Visual Studio 9.0\Team Tools\Static Analysis Tools\FxCop\Repository\Compatibility\Desktop3.0SP2.xml"

Similar to above, in the <CompatibilityEntry> element, change the Priority attribute from 3020 to 3520:

<CompatibilityEntry Name=".NET Framework 3.0 Service Pack 2"
                    Platform="Desktop" 
                    Version="3.0.2" 
                    Priority="3520">

Save the file.

In FxCop 1.36:

Follow the above steps, changing the paths above from %PROGRAMFILES%\Microsoft Visual Studio 9.0\Team Tools\Static Analysis Tools\FxCop\Repository\Compatibility to %PROGRAMFILES%\Microsoft FxCop 1.36\Repository\Compatibility.

To verify the fix:

In Visual Studio, start a new C# WPF Application, and paste the following code in the code-behind of App.xaml:

public partial class App : Application
{
    System.ComponentModel.DateTimeOffsetConverter field1;
    System.Windows.Data.BindingGroup field2;
}

In Solution Explorer, right-click on the project and choose Run Code Analysis.
If the above steps were followed correctly, you should see warnings similar to the following:

This will be fixed in a future release of Visual Studio.

Thanks to Andrew Smith for bringing this my attention.

Breaking changes to the String class

David Kean — Wed, 12 Nov 2008 15:00:43 GMT

You may have already read Justin Van Patten's post about the upcoming breaking changes to the String class for .NET 4.0. This change will affect the behavior of the String.StartsWith, String.EndsWith, String.IndexOf and String.LastIndexOf methods by changing them to perform an ordinal (byte-for-byte) comparison by default instead of a culture-sensitive comparison using CultureInfo.CurrentCulture. In addition, the default overloads of String.ToUpper, String.ToLower, Char.ToUpper and Char.ToLower will be changed to use CultureInfo.InvariantCulture instead of CultureInfo.CurrentCulture.

How does this change affect me?

If you are using an overload of one of the above methods that does not take a StringComparison or CultureInfo as a parameter, then your application or library will be affected when you move it to .NET 4.0. String.Compare and String.CompareTo are not being changed.

An example of the kind of behavior change you could expect, is the following:

static void Main()
{
    int index = "encyclopædia".IndexOf("encyclopaedia");

    Console.WriteLine(index);
}

On versions previous to .NET 4.0, this will output 0 when the user's current locale is set to some cultures, such en-AU, English (Australia), and -1 when the user's current locale is other cultures, such nn-NO, Norwegian, Nynorsk (Norway).

However in .NET 4.0, the above comparison will always output -1, regardless of the user's current locale.

Why was this change made?

The comparison methods on the String class have always been a little schizophrenic; some methods, ==, String.Equals and String.Contains for example, perform an ordinal comparison by default, whereas the above methods, as well String.Compare and String.CompareTo, perform a culture-sensitive comparison. Because they use the current culture, the default culture-sensitive comparisons can also vary between systems, users and even during the same application session. Which, as pointed out in Justin's post, can lead to security vulnerabilities in applications that make security decisions using the default overloads. The planned breaking changes bring the majority of these methods inline with each other to have the same default behavior.

How do I find and fix these comparisons?

To start, you should run FxCop or Visual Studio Code Analysis over your code base. The rules Specify StringComparison and Specify CultureInfo will fire on call sites that do not explicitly specify a StringComparison or CultureInfo. Specify ordinal StringComparison will fire when you use invariant culture instead of ordinal to compare, which is almost always wrong.

To help determine the correct StringComparison or CultureInfo to use, you cannot go past the excellent article New Recommendations for Using Strings in .NET 2.0. In particular, the section under Choosing a StringComparison Member for Your Method Call provides a table detailing common operations and comparisons to use.

New for Visual Studio 2008 SP1 and FxCop 1.36 – Multi-targeting rule

David Kean — Mon, 25 Aug 2008 14:00:00 GMT

Update: Note there is currently a bug in this rule that prevents it from firing on .NET 2.0 SP2 and .NET 3.0 SP2 added APIs when targeting .NET 3.5. See BUG: Multi-targeting rule not firing on usages of 2.0 SP2 and 3.0 SP2 for more information.

Back in October of last year, Krzysztof Cwalina talked about the multi-targeting changes in Visual Studio 2008 and .NET 3.5. He mentioned the limitations in its design that could cause an application that explicitly targets .NET Framework 2.0 and .NET Framework 3.0 to accidently take a dependency on a new member or type that did not exist in the RTM version of that framework. As a workaround, he posted the source code of a Code Analysis/FxCop rule that could detect and fire on a member that took one of these dependencies.

A little while before he wrote that post, my team at the time, the Code Analysis team, was approached to see if we could ship a similar rule out of the box. Unfortunately, we ran out of time to get it included in Visual Studio 2008 RTM and FxCop Beta 2, however, I’m pleased to announce that we’ve added the rule, Use only API from targeted framework, to Visual Studio 2008 SP1 and FxCop 1.36 RTM release.

Note: The Visual Studio integration for this rule is only available in editions that support Code Analysis; Visual Studio Team Development Edition and Visual Studio Team Suite.

How this rule works

In Visual Studio, this rule reads the current targeted framework stored in the C# or Visual Basic project and fires on any usage of API that was not included in the RTM version of that framework. Whereas, in FxCop, the rule reads the targeted framework stored within the FxCop project or passed via the command-line.

The following table attempts to explain this:

	When Target Framework (in Project properties or in FxCop project options/command-line) is set to:
Code Analysis/FxCop fires on usage of:	.NET Framework 2.0	.NET Framework 3.0	.NET Framework 3.5^‡
.NET Framework 2.0
.NET Framework 2.0 SP1	•	•
.NET Framework 2.0 SP2	•	•
.NET Framework 3.0	•^†
.NET Framework 3.0 SP1	•^†	•
.NET Framework 3.0 SP2	•^†	•
.NET Framework 3.5	•^†	•^†
.NET Framework 3.5 SP1	•^†	•^†	•

^† MSBuild prevents a user from mixing these combinations in Visual Studio, so only FxCop can fire on this.
^‡Client-only Framework subset is not supported.

For example, when a user selects .NET Framework 3.0 as their project’s target framework, Code Analysis and FxCop will fire on any usage of members and types that were introduced in .NET Framework 2.0 SP1 and SP2, .NET Framework 3.0 SP1 and SP2, .NET Framework 3.5 and .NET Framework 3.5 SP1. This is because on a fresh install of .NET Framework 3.0 (such as on Vista RTM), none of these service packs or frameworks are installed.

Enabling in Visual Studio

By default, Visual Studio projects with the default Code Analysis settings will already have the rule enabled. To check this, do the following:

In Solution Explorer, right-click on your project and choose Properties
Choose the Code Analysis tab
Expand the Portability node and ensure that Use only API from targeted framework is checked

Once this rule has been enabled, you need to make sure that you targeting the framework that you plan to release your application on. To verify this, do the following:

For C# projects:

In Solution Explorer, right-click on your project and choose Properties
Choose the Application tab
From the Targeted Framework drop down, choose the framework that your application is targeting

For Visual Basic projects:

In Solution Explorer, right-click on your project and choose Properties
Choose the Build tab and click Advanced Compile Options…
From the Target framework (all configurations) drop down, choose the framework that your application is targeting

Once you’ve done the above, running Code Analysis (Analyze -> Run Code Analysis) should now fire on any service pack dependencies your project has taken on. For example, using DateTimeOffset in a project that is set to target .NET Framework 2.0, will cause the following warning to output.

Enabling in FxCop

In contrast to Visual Studio, Use only API from targeted framework does not fire by default in FxCop. This is because FxCop does not have access to the project (.csproj, .vbproj) of the assembly that it is analyzing, and hence cannot automatically determine the Framework your application is targeting. Because of this, you need explicitly specify it; either via the FxCop project or via the command-line.

Enabling using an FxCop project

By default, FxCop projects will already have the rule enabled. To check this, do the following:

Open your FxCop project in FxCop
Choose the Rules tab
Expand the Portability node and ensure that Use only API from targeted framework is checked

Once this rule has been enabled, it will not fire until you tell FxCop the framework you are targeting. To do this, do the following:

Open your FxCop project in FxCop
Choose Project -> Options and then choose the Spelling & Analysis tab
From the Target Framework drop down, choose the framework you are targeting. Typically this would match the value specified in your C#, Visual Basic or C++ project’s properties.
Click OK

Note: You can make this the default for all new FxCop projects and for the command-line by clicking Defaults… after you open the Project Options dialog and then following the rest of the steps above.

Once you’ve done the above, running analysis (Project -> Analyze) should now fire on any service pack dependencies your application has taken on. For example, using DateTimeOffset in a assembly that is set to target .NET Framework 2.0, will cause the following error to output:

Enabling via the command-line

While the preferred method to specify the target framework is by using an FxCop project as described above, you can also specify it explicitly via the command-line. The new /targetframeworkversion switch was added for this purpose. Its valid values are described below:

Argument	Description
/targetframeworkversion:2.0	Specifies .NET Framework 2.0
/targetframeworkversion:3.0	Specifies .NET Framework 3.0
/targetframeworkversion:3.5	Specifies .NET Framework 3.5
/targetframeworkversion:none	Disables the rule. This is the default. However, it can useful to specify this argument if you want to override the associated setting stored in an FxCop project that is passed on the same command-line.

Specifying any of these arguments on a command-line will override the target framework setting stored in the FxCop project.

An example command-line would be the following:

FxCopCmd.exe /file:MyAssembly.dll /console /targetframeworkversion:2.0

Disabling the rule or targeting specific service packs

Use only API from targeted framework does not have support for targeting specific service packs, such as .NET Framework 2.0 SP1. If you want to deliberately take a dependency on a service pack, simply disable the rule by unchecking instead of checking the rule in the Enabling in Visual Studio and Enabling in FxCop sections.