SyndicationPostSharp RC2 Released (And Code Analysis…)
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.
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:
- Compiler runs and places assembly and PDB in obj\$(Configuration) folder.
- Code Analysis runs on obj\$(Configuration) DLL.
- 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.
- 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.
- 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%\MSBuild\PostSharp directory.
February 24th, 2008 at 9:51 pm
Sorry to hear that CGA does not solve everything.
It seems like I will have to integrate some MSBuild-based solution as well. However, I would prefer the approach of making a copy of the original assembly and redirect only the Code Analysis task to this copy. Copying back modified files to original files at the last moment is maybe a little brittle, because other tasks may rely on the “final” assembly lying in obj\$(Configuration).
I guess Microsoft should donate me their expensive VSTS so that I can test the solution… Anyway, instead of waiting for the improbable, I will do it with a trial edition ;).
Gael