A while back I came across an excellent article from Robin Curry about integrating SourceMonitor into CruiseControl.Net using NAnt.  I wanted this for my team as well.  We use CruiseControl.Net, but have converted to the MSBuild camp.  So I started to look into what it would take to get SourceMonitor running with MSBuild.  I figured it would be easy, but I was amazed at just how easy it was.

The steps to integrate this are as follows:

1. Download SourceMonitor and add it to the path.
2. Write a project file for MSBuild.  (I have included a sample in this article that should work for everyone, or at least can be used as a template for modifications)
3. Add the file merge to the CruiseControl.Net ccnet.config file. (A sample is included in this article as well)

Here is the MSBuild file, we just called it SourceMonitor.csproj:

<?xml version=”1.0″ encoding=”utf-8″?>

<Project DefaultTargets=”Build” xmlns=”http://schemas.microsoft.com/developer/msbuild/2003″>

    <!– SourceMonitor Properties”/” –>

    <PropertyGroup>

        <SourceMonitorInput>SourceMonitor.xml</SourceMonitorInput>

        <SourceMonitorProject>SourceMonitorProject.smp</SourceMonitorProject>

        <SourceMonitorDir>$(MSBuildProjectDirectory)\</SourceMonitorDir> <!– be sure to end directory with a “/” –>

        <SourceMonitorSummary>SourceMonitorSummary.xml</SourceMonitorSummary>

        <SourceMonitorDetails>SourceMonitorDetails.xml</SourceMonitorDetails>

        <SourceMonitorCheckPointName>BaseLine</SourceMonitorCheckPointName>

        <SourceMonitorText> <![CDATA[

<?xml version="1.0" encoding="UTF-8" ?>

<sourcemonitor_commands>

    <write_log>true</write_log>

    <command>

        <project_file>$(SourceMonitorProject)</project_file>

        <project_language>CSharp</project_language>

        <source_directory>$(SourceMonitorDir)</source_directory>

        <include_subdirectories>true</include_subdirectories>

        <ignore_headers_footers>true</ignore_headers_footers>

        <checkpoint_name>$(SourceMonitorCheckPointName)</checkpoint_name>

        <export>

            <export_file>$(SourceMonitorSummary)</export_file>

            <export_type>1</export_type>

        </export>

    </command>

    <command>

    <project_file>$(SourceMonitorProject)</project_file>

    <checkpoint_name>$(SourceMonitorCheckPointName)</checkpoint_name>

        <export>

            <export_file>$(SourceMonitorDetails)</export_file>

            <export_type>2</export_type>

        </export>

    </command>

</sourcemonitor_commands>

        ]]></SourceMonitorText>

    </PropertyGroup>

    <Target Name=”Clean”  Condition=” ‘$(BUILDMACHINE)’ != ” “>

        <Exec Command=”del $(SourceMonitorSummary)” />

        <Exec Command=”del $(SourceMonitorDetails)” />

    </Target>

    <Target Name=”Build”  Condition=” ‘$(BUILDMACHINE)’ != ” “>

        <WriteLinesToFile

                File=”$(SourceMonitorInput)”

                Lines=”$(SourceMonitorText)”

                Overwrite=”true” />

        <Exec Command=”sourcemonitor.exe /C $(SourceMonitorInput)” />

    </Target>

</Project>

Note that the <SourceMonitorDir> tag is to contain the directory where the *.cs files can be found.  I currently have this set as the MSBuildProjectDirectory and have <include_subdirectories> set to true.  You may wish to modify this.

And here is a sample of how to modify the ccnet.config file:

<tasks>

    <msbuild>

        … Insert your msbuild solution information here. The SourceMonior.csproj file should be included in this solution …

    </msbuild>

    <merge>

        <files>

            <file>… Path …\SourceMonitorSummary.xml</file>

            <file>… Path …\SourceMonitorDetails.xml</file>

        </files>

    </merge>

</tasks>

Coding standards have consistantly been a source of pain for developers. Many are reluctant to accept them because they feel that the way the program is just fine. However when working in a agile environment or an environment where developers work on each other’s code, the need for standards becomes more evident. Money and time can be saved if any develper can quickly navigate code, figure out what is going on, and fix bugs.

On my team here at Interactive Intelligence we adopting more and more agile processes. A few months back I took it upon myself to come up with a standards document for our own coding. Everything we do is in C# so I naturally looked for what other people had put together and what Microsoft recommends. The overall goal was not only to make it easy to work on each other’s code more easily, but also to be able to pick up code snippets and samples from Microsoft and other parties and follow along. The end result has been the C# Coding Standards. This document is ever evolving as do most documents of this kind. It not only contains syntax suggestions, but also makes some developement recommendations.

Two of the biggest arguements about the standards doc are the use of tabs over spaces, and the prefix “m_” for private properties. At this time we prefer tabs as they are a symbol used to represent indention vs. other white spaces. As long as everyone follows the standards and sets all tabs to 4 spaces, then almost all of the benifets of using spaces become void. We prefer the prefix “m_” private properties because CLS compliance clearly states that variables can differ by no more than casing, using “camal case for private and pascal case for everything else” is not an option. The use of just a “_” prefix also isn’t CLS complaint.

Download: C# Coding Standards