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.

Looking ahead, I’m not sure what the best solution for the PostSharp team is on this. I know it’s low priority compared to other functionality, but as an end user it is frustrating to filter rule violations based on what PostSharp generates. The easiest approach, in my opinion, would be for PostSharp to preserve the assembly the compiler produces. That way, Visual Studio Team Edition for Developers (or Visual Studio Team Suite) can perform static code analysis on those assemblies, and FxCop can have an assembly on disk to analyze.

Since there were some changes in the targets file that PostSharp uses, I had to make a new version of the targets file I showed last time. This time, however, I took the opportunity to fix a bug that the old targets file introduced, which ran code analysis on PostSharp-affected code in certain circumstances.

Last time after using the new targets file, if you ran code analysis (using, for example, the context menu commands “Run Code Analysis” or “Rebuild” if code analysis was enabled) on a project, then everything would run as expected. Code analysis would show only warnings from the assembly before PostSharp “touched” it. The problem was that Code Analysis (CA) would run, and then PostSharp would overwrite the assembly that it analyzed. If the project were built again without any modifications to any file in the assembly, then CA would see that the assembly changed (because PostSharp overwrote it during the last build), and thus would run again.

The new solution takes advantage of the fact that PostSharp also stores the assembly that contains AOP-processed code in the obj$(Configuration)PostSharp directory. This is new process:

1. Compiler runs and places assembly and PDB in obj$(Configuration) folder.
2. Code Analysis runs on obj$(Configuration) DLL.
3. PostSharp disassembles and reassembles DLL in the obj$(Configuration) folder, placing result DLL and PDB in the obj$(Configuration)PostSharp folder. Note that PostSharp does not ovewrite the obj$(Configuration) DLL and PDB.
4. CopyFilesToOutputDirectory copies files from obj$(Configuration) to bin$(Configuration), including the DLL and PDB. Obviously, we want the PostSharp code, not the code created straight from the compiler.
5. CopyPostSharpFilesToOutputDirectory (a new MSBuild target) copies the DLL and PDB from obj$(Configuration)PostSharp to the bin$(Configuration) folder.

This process leaves the obj$(Configuration) DLL and PDB as the one that the compiler created. This gives CA a chance to run on an “untouched” assembly, both inside and outside the build process.

The latest targets file is available here: (Remember to rename the extension to .targets instead of .targets.xml)

PostSharp-1.0 Targets (RC2) – Copy to your %PROGRAMFILES%MSBuildPostSharp directory.

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.

It can take a while to parse through all the targets in Microsoft.Common.targets, Microsoft.CodeAnalysis.targets, and PostSharp-1.0.targets, but here’s the general order of what’s happening with a fresh PostSharp installation.

• …
• Compile
  • …
  • CoreCompile (Delegated to a specific language’s targets file; for example, C# runs csc.exe at this point.)
  • …
  • PostSharpInspectConstants
  • PostSharpInspectReferences
  • PostSharp (Where the actual post-compilation is done)
• …
• PrepareForRun (After build, but before running the application)
  • CopyFilesToOutputDirectory
  • RunCodeAnalysis
• …

So there are obviously a couple of steps between the PostSharp processing and CA. When building the project, the CoreCompile target will place the newly built assembly in the obj$(Configuration) folder. Afterwards, when PostSharp runs, it compiles a new assembly with PDBs in the obj$(Configuration)PostSharp folder. Finally, that is copied to the obj$(Configuration) folder, which overwrites what the CoreCompile task created.

CA waits until the files are copied to the $(OutDir) directory (which is by default bin$(Configuration)) before executing. Thus it would be great if we could now change the order of things to do the following when PostSharp is enabled:

• …
• Compile
  • …
  • CoreCompile (Delegated to a specific language’s targets file; for example, C# runs csc.exe at this point.)
  • …
  • RunCodeAnalysis
  • PostSharpInspectConstants
  • PostSharpInspectReferences
  • PostSharp
• …
• PrepareForRun
  • CopyFilesToOutputDirectory
• …

So the next question is how do we do that?

The first thing is we need to find the targets files for both CA and PostSharp. The former is located at %PROGRAMFILES%MSBuildMicrosoftVisualStudiov9.0CodeAnalysisMicrosoft.CodeAnalysis.targets, and the latter is located at %PROGRAMFILES%MSBuildPostSharpPostSharp-1.0.targets. At the end of the PostSharp targets file, you can see that it inserts itself into the chain of compilation targets I described above.

<PropertyGroup>

    <CompileDependsOn>

        $(CompileDependsOn);

        PostSharpInspectConstants;

        PostSharpInspectReferences;

        PostSharp

    </CompileDependsOn>

    <BuildDependsOn>

        $(BuildDependsOn);

        PostSharpVerify

    </BuildDependsOn>

</PropertyGroup>

Now perhaps we can trick code analysis into running before PostSharp just by re-ordering the dependencies, like this:

<PropertyGroup>

    <CompileDependsOn>

        $(CompileDependsOn);

        RunCodeAnalysis;

        PostSharpInspectConstants;

        PostSharpInspectReferences;

        PostSharp

    </CompileDependsOn>

    <BuildDependsOn>

        $(BuildDependsOn);

        PostSharpVerify

    </BuildDependsOn>

</PropertyGroup>

So we’ve said to run code analysis before the PostSharp processing. Unfortunately, this doesn’t work, as MSBuild reports the following error:

If we navigate to the Microsoft.CodeAnalysis.targets file, we can see that the RunCodeAnalysis target depends on the Compile target. But because we also overrode the CompileDependsOn property to include RunCodeAnalysis, we have two targets that are dependent on each other to run.

The next trick is to change what CodeAnalysis is dependent on. To do this, we need to change its semantics; instead of performing analysis on the $(OutDir)$(TargetName)$(TargetExt)  file (e.g. binDebugTarget.dll), we need to perform analysis on the obj$(Configuration)$(TargetName)$(TargetExt) file (e.g. objDebugTarget.dll). So instead of being dependent on Compile, the target is dependent on the step that generates the objDebugTarget.dll file: CoreCompile.

<Target

    Name=“RunCodeAnalysis“

    Condition=“‘$(RunCodeAnalysis)’==’true’ or ‘$(RunCodeAnalysisOnce)’==’true’“

    Inputs=“$(CodeAnalysisInputAssemblyForTask)“

    Outputs=“$(CodeAnalysisLogFileForTask);$(CodeAnalysisSucceededFile)“

    DependsOnTargets=“CoreCompile;SetCodeAnalysisProperties“

    >

We’re almost done. Unfortunately, now CodeAnalysis runs at the correct point, but it doesn’t run on the correct file. Remember we want it to perform analysis on the obj$(Configuration) assembly before PostSharp has overwritten it.  So how does Code Analysis know where to retrieve the assembly? Well, if we open the Microsoft.CodeAnalysis.targets file again and have a look at the properties, we can see:

<CodeAnalysisInputAssemblyForTask Condition=“‘$(CodeAnalysisInputAssembly)’!=”“>$(CodeAnalysisInputAssembly)</CodeAnalysisInputAssemblyForTask>

<CodeAnalysisInputAssemblyForTask Condition=“‘$(CodeAnalysisInputAssembly)’==”“>$(OutDir)$(TargetName)$(TargetExt)</CodeAnalysisInputAssemblyForTask>

<CodeAnalysisLogFileForTask Condition=“‘$(CodeAnalysisLogFile)’!=”“>$(CodeAnalysisLogFile)</CodeAnalysisLogFileForTask>

<CodeAnalysisLogFileForTask Condition=“‘$(CodeAnalysisLogFile)’==”“>$(CodeAnalysisInputAssemblyForTask).CodeAnalysisLog.xml</CodeAnalysisLogFileForTask>

So what this tells us is that the CodeAnalysisInputAssemblyForTask and CodeAnalysisLogFileForTask files can be overridden by a project file or another targets file by specifying either property in a <PropertyGroup> tag, like this:

<PropertyGroup>

    <CodeAnalysisInputAssemblyForTask>obj$(Configuration)$(TargetName)$(TargetExt)</CodeAnalysisInputAssemblyForTask>

    <CodeAnalysisLogFileForTask>$(CodeAnalysisInputAssemblyForTask).CodeAnalysisLog.xml</CodeAnalysisLogFileForTask>

</PropertyGroup>

When placed in a project file, this will instruct Code Analysis to analyze the assembly that we want and to produce the log file in the correct directory. This is a bit of a hassle when you have to change every single project, and there may be some cases where you want to keep the default behavior of Code Analysis (i.e. point at the binDebug folder when PostSharp is not run). There is one last tweak we can make to automate this change across all projects. Open up the PostSharp targets file and scroll down to the PropertyGroup that defines the CompileDependsOn property. Overwrite that single property group with the following:

<!– Introduces PostSharp in the chain of compilation targets –>

<PropertyGroup Condition=“‘$(RunCodeAnalysis)’==’true’ or ‘$(RunCodeAnalysisOnce)’==’true’“>

    <CompileDependsOn>

        $(CompileDependsOn);

        RunCodeAnalysis;

        PostSharpInspectConstants;

        PostSharpInspectReferences;

        PostSharp

    </CompileDependsOn>

    <CodeAnalysisInputAssemblyForTask>obj$(Configuration)$(TargetName)$(TargetExt)</CodeAnalysisInputAssemblyForTask>

    <CodeAnalysisLogFileForTask>$(CodeAnalysisInputAssemblyForTask).CodeAnalysisLog.xml</CodeAnalysisLogFileForTask>

</PropertyGroup>

<PropertyGroup Condition=“‘$(RunCodeAnalysis)’!=’true’ and ‘$(RunCodeAnalysisOnce)’!=’true’“>

    <CompileDependsOn>

        $(CompileDependsOn);

        PostSharpInspectConstants;

        PostSharpInspectReferences;

        PostSharp

    </CompileDependsOn>

</PropertyGroup>

<PropertyGroup>

    <BuildDependsOn>

        $(BuildDependsOn);

        PostSharpVerify

    </BuildDependsOn>

</PropertyGroup>

This final edit makes the targets a little more robust in that we (1) schedule Code Analysis to run before PostSharp only when CA is enabled and we (2) edit the CA Input Assembly property to target the desired location.

Here are the final targets files (Be sure to rename them to .targets instead of .xml):

PostSharp-1.0 Targets – %PROGRAMFILES%MSBuildPostSharp

Code Analysis VSTS 9.0 Targets – %PROGRAMFILES%MSBuildMicrosoftVisualStudiov9.0CodeAnalysis

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 FilesMicrosoft Visual Studio 9Team ToolsStatic Analysis ToolsFxCopImmutableTypes.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 ToolsStatic Analysis ToolsFxCop“ />

That will copy the ImmutableTypes.txt file from my project to the C:Program FilesMicrosoft Visual Studio 9Team ToolsStatic Analysis ToolsFxCopImmutableTypes.txt location. Problem (tentatively) solved.