David DeWinter

Gael Fraiteur has released another release candidate of PostSharp, an Aspect-Oriented Programming solution for .NET. In my previous post on PostSharp, I discussed a way to work around some pesky Code Analysis errors that PostSharp incurs as a result of its post-compilation processing.

Unfortunately, I don’t believe adding the CompilerGeneratedAttribute (CGA), which was done before RC2’s release, to PostSharp-specific code fixed all of the Code Analysis warnings that our team received. After upgrading to RC2, Code Analysis warned us specifically about initializing our static fields inline in many of our classes and removing the explicit static constructors, as well as the cyclomatic complexity of some of our methods. It was the fact that we did initialize our static fields inline that tipped us off about the same problems that caused me to write my first PostSharp and Code Analysis post. The problem is that adding the CGA is not comprehensive enough to suppress all code analysis violations. For example, PostSharp effectively injects code at certain points in a program execution (join points in a method). You wouldn’t want the CompilerGeneratedAttribute applied to that code, because it could suppress other rule violations that come from your code, not PostSharp’s code. Fortunately PostSharp does not apply the CGA in those circumstances, but there needs to be a middle ground such that PostSharp code is totally ignored by code analysis.

(more…)

(If you just want the targets files, click here.)

Are you using PostSharp for your .NET development? Do you get frustrated when code analysis within VSTS reports warnings like these:

Now PostSharp is a superb AOP tool for .NET, but it is annoying to see these issues in code analysis again and again; what would be great is if we can edit the build process to make Code Analysis (CA) run before PostSharp processes the assembly. That way, code analysis errors on PostSharp-generated code is ignored, and everyone is happy.

(more…)

If you’re not familiar with the code analysis rule mentioned in the title of this post, I recommend you check out David Kean’s FAQ post here for some background.

In summary, a violation of this rule may be fired even if you declare a read-only variable of a type that’s immutable, because the code analysis engine won’t know that that type is immutable. To get around this, you can follow David’s suggestion of putting an ImmutableTypes.txt file in the same directory as your FxCop project file.

But if you’re using Visual Studio Team System to execute your Code Analysis, it’s a different story because you don’t have an FxCop project file. Fortunately, this ImmutableTypes.txt file can be placed in the C:\Program Files\Microsoft Visual Studio 9\Team Tools\Static Analysis Tools\FxCop\ImmutableTypes.txt location to be picked up.

What would be great is if there was an MSBuild task that allowed developers on a project to make an ImmutableTypes.txt file directly in a VS project and have that merged with the existing ImmutableTypes.txt at the target location. That way, individual projects can build their ImmutableTypes without worrying about CA2104 violations. In fact…I may just build that task. Right now I have a centralized project for gathering Immutable Types and I do this as part of my build:

<Copy SourceFiles=“ImmutableTypes.txt“ DestinationFolder=“$(VS90COMNTOOLS)..\..\Team Tools\Static Analysis Tools\FxCop\“ />

That will copy the ImmutableTypes.txt file from my project to the C:\Program Files\Microsoft Visual Studio 9\Team Tools\Static Analysis Tools\FxCop\ImmutableTypes.txt location. Problem (tentatively) solved.