David DeWinter

Yes, I am back from the grave. The past two months have been infuriatingly busy for me (and you’ll see why in a later post), but I finally have some time to write again. The topic? Generating serialization classes as part of your build process (Part 1) and in your own way (Part 2).

I might reach only a niche of .NET developers with this post, but it’s something that niche should be aware of. There is a tool in the .NET framework called xsd.exe, and one of its functions is to generate code, specifically .NET classes, from an XML Schema file (XSD). The tool decorates these classes with XML serialization attributes such that when .NET serializes an instance of the generated class that represents the root element, the output conforms to that XML schema. Often, developers using XML schemas will need to change them throughout the course of a project. Leveraging xsd.exe in a project thus requires the generated classes to be updated when an XML schema is updated. This is a bit dangerous in larger projects because not all developers may realize that the tool must be re-run, especially in the case of extremely minor changes to the schema.

Wouldn’t it be better to have a tighter integration among the XML schema, the generated classes, and the build environment? Fortunately, we can achieve this with a few simple steps, thanks to the MSBuild system for projects inside Visual Studio.

(more…)

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…)