Wiring FxCop up to our build process

Earlier this week we decided to finally pull the trigger to have our automated build fail when the code violates the FxCop rules we use for code analysis. Previously we ran FxCop but rule violations didn't break the build. The code is a legacy application and so lots of rules were broken pretty much everywhere.

But yesterday I set all existing violations as exceptions so FxCop will basically ignore them. Today's effort was to figured out how to have the build break and still have the FxCop results appear in CruiseControl.NET (CC.NET). That second goal was a bit trickier than I thought it would be.

There were two changes that had to be made to enable this. First, was to have the NAnt script fail when FxCop finds a problem. This wasn't a big deal because FxCop only produces the XML output when there are violations. All I had to do was add a FAIL task that runs after the code analysis. If the output file exists we fail. This is what that task looks like:

<fail if="${file::exists(fxcop.output.path)}">FxCop rules violated, see FxCop Report for details.</fail>

Now the code analysis can build to break - awesome!

But doing this caused the FxCop Report in CC.NET to not display any results. This blog post by Leifw gave me the hint I needed to resolve the problem. Previously I had been doing my File Merge to get the FxCop results as part of the TASKS node of my CC.NET project configuration block. It turns out, though, File Merges done in the TASKS node won't occur if the build fails. I moved it to a PUBLISHERS node in the project and it all works ducky. That's because the PUBLISHERS node is processed even if the build fails. That looks like this:

<project name="MyWebGrocer.Gsa Trunk">

...

<publishers>

<merge>

<files>

<file>C:\BuildArtifacts\Project_Trunk\*.xml</file>

</files>

</merge>

<xmllogger />

</publishers>

</project>

Now if someone commits code that does something unforgivable - like neglecting to make a method static if it doesn't use any instance members - the build will break and they can check what the offense was via the CC.NET dashboard.

It's still a legacy application - but we won't be committing any more legacy code.

Mitigating web.config security vulnerabilities through scripting

After reading this post, .Net and Business Intelligence: Application Security Vulnerabilities in Web.config File, what occurred to me was all this could be mitigated by employing a strategy I refer to as composition scripting.

While I've done a bit with build automation I've also created NAnt scripts that I refer to as composition scripts. The purpose of a composition script is to automate all the tasks required to prepare an application for deployment. I've used them to create ClickOnce deployments, but for web applications a composition script generally grabs all the pages and binaries needed. But in addition to that, and this is the relevant bit, I make use of the XmlPeek and XmlPoke tasks to swap out web.config tags to use configuration values appropriate for the environment being composed.

You see, my script accepts a parameter called Target.Environment. The acceptable values for that parameter are QA, UAT, PROD - quality assurance, user acceptance testing and production, respectively. (Where's development, you may ask? Well, that's the default state of the web.config in the source code repository). Along side the web.config I have a few files named web.config.qa, web.config.uat and web.config.prod. These are not repeats of the entire web.config file, though, but rather are the configuration values that need to change from environment to environment. These are the values swapped into the config using XmlPeek and XmlPoke.

Note: I believe a composition script should not recompile the application. It should compose the application deployment using the same pages and binaries as the application progresses from QA testing to UA testing and into production. This ensures the application being deployed is the same application which underwent testing.

So using composition scripts it's easy to mitigate the 10 security risks identified in the article.