igorbrejc.net

Simply remove (or rename) the Data/Reflection directory, so that Sandcastle cannot find the information about .NET Framework libraries. You will loose the ability to have MSDN help on .NET Framework classes links in your documentation, but I think this is not crucial for day-to-day builds, compared to the substantial increase in your build speed. And also, by deleting the contents of the Reflection folder you’ll gain some 200 MB of space on your disk.

A few months ago I was looking for some way of tracking activity on our new software project. What I wanted is a free and simple tool which could analyze Subversion logs and generate some statistics and graphs on lines of code, commits and similar stuff.

So I did a search on Google, SourceForge and some other search engines and I found two tools: StatSVN and (oddly enough) SvnStat. The latter generates a single HTML page with a collection of statistics graphs on daily commits (here is a sample report), while the former is more sophisticated and does analysis on lines of code, file and directory sizes, commit activity analyzed per hours of day and days of week and other things (see sample report). It even shows a repository heatmap - a clickable hierarchical map of your SVN repository with indicated increases or decreases of lines of code per directory or file.

The biggest difference between them is that StatSVN not only analyzes the SVN log file, but also goes through the latest version of your SVN repository. That’s how it calculates the lines of code in your project, for example.

I decided to use both of them, since they complement each other (SvnStat generates some graphs which the other one does not). I created a batch script and set it to run as a scheduled task on our build server. Here is a generalized version of the script, you have to fill in your specifics (see below):

<1> = a file path to your checked out repository

<2> = a place where you want to put the SVN XML log file (the whole file path including the name)

<3> = a place where the first (SvnStat) report will be generated

<4> = a place where the second (StateSVN) report will be generated

One warning: the reports also analyze activity for each SVN user, so watch out if you have members in your team that feel that this is a little too Big Brother-ish.

WSDLs are not very readable, so I wanted to have some sort of developer-friendly documentation for web services as part of our CI build. I found a simple but effective solution: WSDL viewer (by Tomi Vanek), which is an XSLT transformation file that produces nice HTML documentation.

I had to create a custom NAnt task for XSLT transformations since <style> task failed when I tried to do transformations using the WSDL viewer XSLT (it was complaining about some XML elements not being declared):

Now all you need is to use this task to create the documentation:

Development In General

• Continuous Integration anti-patterns - Make your life with CI easier by learning what not to do

.NET Development

• A list of FxCop rules dropped in VS 2008 and new version FxCop

OpenStreetMap

• Historic OSM animation

General

• A List of Amazon S3 Backup Tools

• Source Control for Micro-ISVs
• Ultimate Boot CD for Windows
• Physics in Crysis - watch 3000 barrels fall

On the project I’m currently working on we are struggling to have all of public classes and methods documented. Since we haven’t been very disciplined doing that, we still have around 400 warnings related to code comments, which can be problematic since some more important warnings could be overlooked in this mass.

Since we already have CC.Net Statistics set up on our build server, I decided to use it to track compiler warnings so that we make sure their number not increasing with new builds. So here are instructions on how to set it up on your CC.Net build server.

(NOTE: we are using the old version of CC.Net Statistics which came before the codeplex project, so I’m not sure the same procedure applies to the new MSI-based version. I couldn’t make the new version run on our build server, I think it is probably because our CC.Net was installed manually and not using the MSI installation).

Okey, so the first thing to do is to tell CC.Net that your project should collect statistics about compiler warnings. Open your CC.Net project configuration file and find the <publishers> tag for the project. Insert the following XML code inside the <publishers> tag (it should be after the any <merge> publisher and before any <xmllogger> publishers):

<statistics>
<statisticList>
<statistic name=’Compiler Warnings’ xpath=’count(//*[contains (text(),"warning CS")])’/>
</statisticList>
</statistics>

If you already have the statistics publisher, just add the warning statistics line.

After saving the file, CC.Net should reload the configuration and start recording the statistics for the future builds. Now we have to add graphs for compiler warnings in CC.Net WebDashboard. Open the webdashboard\javascript\GraphConfiguration.js file in the text editor and find “var _recentGraphConfigurations” array. There you have to defined a new “recent graph” by adding the following lines:

You can choose your own title and color, off course.

To include warnings graph in the summary graphs page, first an function calculating the average warnings has to be added to the “var _summaryConfiguration” array:

Now we have to add the summary graph to the “var _historicGraphConfigurations” array:

After saving the file, don’t forget to restart the WebDashboard application in IIS (the easiest way is just to “touch” its Web.config file). After the next build, you should be able to see new graphs on your project statistics page.