I would like to propose a Developer's Hippocratic Oath that would start with: "First, do no harm". ¹ Too often, a developer makes a change to a system that later proves to be disruptive or harmful. Yes, humans will always find a way to introduce bugs into code; however, we can all strive to reduce the impact of those bugs by:

• Understanding the infrastructure and tooling support, and pledge to make it better by automating more of it. Time spent automating things here reduces the chances of manual error later.
• Adopting a culture of testing. Unit testing tools are ubiquitous at this point. Even if you can't test everything, you can start by testing something.
• Fostering a spirit of continuous improvement in both talent and code. Take the time to refactor that code that bothers you. If it bothers you, it bothers someone else. Remember, refactoring requires discipline and unit testing to be complete!
• Fixing a bug at the source of it's error, rather than applying a band-aid further downstream - regardless of the schedule pressure.

Anything else you care to add before we codify this?

Nitpicker's Corner²

¹Yes, I know that the exact phrase "First, do no harm" is not actually in the Hippocratic oath. However, it is pithy and memorable and serves the purpose and intent perfectly in this context of establishing a new oath for Developers. If we want to vote on just naming it the Misercratic Oath for Software Developers (thanks, Steve!), we could go that way, too.

²With apologies to Raymond Chen.

Moving from a legacy system, one needs to appropriately deal with bad data in the database. For example, in order to put a primary key on a table, the column(s) in that primary key must be able to uniquely identify one record. If you need to find rows with duplicate entries before adding a primary key, you can start with this query:

select Id
from MyTable
group by Id
having count(*) > 1

Here is the target that I used to generate an FxCop report and integrate it seamlessly into the CC.NET web dashboard.

<FxCop
  TargetAssemblies="$(TargetAssembly)"
  RuleLibraries="@(FxCopRuleAssemblies)"
  AnalysisReportFileName="FxCop.xml"
  FailOnError="False"
  ApplyOutXsl="False"
  OutputXslFilename="Vendor\FxCop\Xml\FxCopReport.xsl"
  Verbose="False"
  IncludeSummaryReport="True"
  WorkingDirectory="$(MSBuildProjectDirectory)"
  ToolPath="$(MSBuildProjectDirectory)\Vendor\FxCop"/>

The key here is to be sure that ApplyOutXsl is set to False. If it's set to True, then the output will not get logged into the CC.NET log, which means when the dashboard tries to find it, it won't be there.

The other thing of note here is that I have all of my third-party tools, like FxCop, Sandcastle, Enterprise Library, etc. in a Vendor subdirectory of my project. By doing this, I can pick up the one Vendor folder and get another project up to speed quickly (through copying or Subversion externals).

When customizing the appearance of the CC.NET Web Dashboard, you often need to modify the file c:\Program Files\CruiseControl.NET\webdashboard\dashboard.config. However, you won't see the changes you make there reflected back in the browser until that file is reloaded.

The easiest way to reload dashboard.config is to quickly modify web.config (add a space and delete it), and save. This forces IIS to reload the web application, which in turn causes dashboard.config to give up it's new settings. This is especially useful in a hosted environment where you don't have access to administration-level tools.

An alternative would be to just bounce the entire web server by stopping and starting the service, but that's not always feasible nor practical.

When you need to extract more information from the MSBuild script, you can use the following syntax:

  msbuild /v:diag build.proj

There are other verbosity options available, too. Very handy when you need to easily find out what's going on behind the scenes.

I'm working a lot on agile .NET project setup right now. One of the standards in this arena is CruiseControl.Net. We also use Subversion and MSBuild, which means we need to use MSBuild Tasks to use the custom Subversion tasks. The documentation for MSBuildTasks is, well, "Open Sourcey". For the Subversion tasks, not all tasks have example MSBuild fragments. In addition, the descriptions of most properties or classes are just one sentence circular summaries.

For example, if you need to commit just one file inside the MSBuild script, you would use the SvnCommit task. You might do this as part of a depoyment process where you set version numbers on files before creating an installer. This is the snippet that I finally settled on to update just that one file:

<ItemGroup>
  <CodeFiles Include="Properties\AssemblyInfo.cs" />
</ItemGroup>

<!-- Later on, inside a Target, use this -->
<SvnCommit
  Targets="@(CodeFiles)"
  Message="$(CCNetLabel)"
  Password="pwd"
  UserName="user"
/>

The reason for this is that SvnCommit descends from SvnClient, which is too generalized of a base class. For example, the SvnCommit.RepositoryPath property does not work as one might expect. Specifically, in my case, when I specified the RepositoryPath attribute in the msbuild file, I received the following error. It turns out that you should just not specify the RepositoryPath attribute at all (see the documentation for "svn help commit" to see that a URL is not passed in on the command-line, but rather, svn figures out the URL from the working copy).

    svn: 'svn://x.y.z/project/trunk' is a URL, but URLs cannot be commit targets


Also, SvnCommit.LocalPath should not be used. It ends up generating a command-line similar to the following, which ends up committing everything in the LocalPath and down. Remember, all I wanted was to update one specific file, so it turns out that the LocalPath attribute is getting in the way here.

svn.exe commit "full\path\to\my\working\directory" 

  "Properties\AssemblyInfo.cs" --username user --password pwd 

  --message "1.8.1.2" --non-ineractive --no-auth-cache

To sum up:

• Don't specify the RepositoryPath attribute in an SvnCommit task
• Don't specify the LocalPath attribute in an SvnCommit task
• Specify a ToolPath entry that points to the folder that holds svn.exe if it's not in the default location (c:\Program Files\Subversion\)
• Setting the Verbose attribute does not work because it is defined as a nullable boolean

Edited on 10/10/2007 for clarity due to comments made by Steve Trefethen. Thanks, Steve!

I used Altova's XMLSpy briefly back in the day, and it was a very well thought-out and implemented product. I haven't had a lot of need to look at the company for several years, until today when a co-worker pointed me to their (semi-)new product, DatabaseSpy 2008. It connects to many different databases and has a phenomenal UI (like all Altova products). It has a nice editor, designer, and browser, and has a very powerful import/export mechanism to easily move data between different databases.

It looks like I need to sit down and evaluate the other products that have appeared since the last time I looked.

Note: This post is unsolicited. I do not have a registered copy of any Altova product at this time.

This is a pretty nice summary about what to do to be able to share files between two mortal enemies.