Post build event weirdness...

After checking out a Visual Studio 2008 solution from our Subversion repository to a new machine (and new physical location) I started getting failure on the post build event reporting an exit code of 9009.  As ever it was building fin on another machine (luckily for once this failure wasn't on the continuous integration server).

With an exception like that It would have been easy to go off on one!  This project had some post build processing running in batch file, including RegAsm!  Looking at the simple things first, it had been checked out to a location with long file names such that the batch file was not running correctly.

	$(ProjectDir)\Install\Install.cmd  

Just wrapping the command in quotes sorted it. 

	"$(ProjectDir)\Install\Install.cmd"  

Ridiculously simple I know, but I thought I would write this one up - the way this was reported you could easily burn an hour or so chasing your tail...

Debugging the XmlSerializer

So we all love the XmlSerializer right! Probably a lot more than the DataContractSerializer, but then we have had more time to get used to it's ways.  Most of the time we don't need to care what's going on, but sometimes (and usually when we are forced into doing some custom serialization) it doesn't do exactly what we expected and after the allowable "couple of minutes" of trial and error (or is that just me) we need to step through the serialization code to see what's up.

First thing needed is to add diagnostics switches on XmlSerializer in the applications config file:

   1: <system.diagnostics>
   2:       <switches>
   3:          <add name="XmlSerialization.Compilation" value="1" />
   4:       </switches>
   5: </system.diagnostics>

Then compile and run the application in debug to the point immediately after the XmlSerializer in constructed for the type:

   1: XmlSerializer ser = new XmlSerializer(typeof(MyType));

The dynamic assembly and c# source is created in c:\documents and settings\[user]\local settings\temp under XP or c:\users\[user]\appdata\local under Vista - open the latest created *.cs file in your debug visual studio instance and off you go!

Printing to MODI under Vista

Not sure how, but somehow I lost the ability to print to Microsoft Office Document Image Writer (MODI) delivered with Office 2003 under Vista - I was getting pretty ugly exceptions when trying and as ever needed to get it sorted 'cos I needed it quick!  The quickest way to resolve was to re-install MODI, which wasn't that painful:

  • Close all running applications - if you have any Office application running, the driver will not be installed properly
  • Go to the "Control Panel" and "Programs and Features"
  • Click on"Microsoft Office 2003" and then click on "Change"
  • Check "Add or Remove Features" and click "Next"
  • On the bottom of the page check "Choose advanced customization of applications." and click "Next"
  • Under Microsoft Office click on the + sign in front of "Office Tools"
  • Locate "Microsoft Office Document Imaging", click the icon and select "Not Available"
  • Click on "Update" - this will uninstall the broken MODI driver
  • Repeat steps to get back to the point of expanding "Office Tools"
  • Locate "Microsoft Office Document Imaging", click the icon and select "Run from My Computer"
  • Click on "Update" - this will re-install the driver

Not sure how this got broken - I have installed a bunch of software since I last used it...

Subversion with Windows authentication on Server 2003

Subversion is a powerful source code control repository, but getting it to authenticate using Windows users can be a mite tricky...

In this setup the aim is to have an Apache served repository allow author details to be recorded in the subversion repository (predominantly to allow you to find out who to blame) - so the setup will be simply to allow all users read access to the repository and ensure that domain authenticated users only are allowed to write to the repository.

First step is to install the Subversion repository and get it running with Apache; I find the CollabNet package really well put together (v 1.4.6 is what is used in this setup and can be obtained from http://downloads.open.collab.net/collabnet-subversion.html).  The CollabNet install is very simple just be sure to choose Apache, and make sure the repository is working unauthenticated before moving on.

Once its all running you need to download the mod_auth_sspi Apache plug in, there are various builds available, but the one I have found to be reliable is the sourceforge project available from http://sourceforge.net/projects/mod-auth-sspi.  You need to make sure you use the correct plug in version for the version of Apache, version 1.04 from the mod_auth_sspi-1.0.4-2.0.58.zip drop works with the v1.4.6 CollabNet package.  From the downloaded zip copy the mod_auth_sspi.so file into the httpd\modules in the CollabNet install directory (default is c:\program files\CollabNet Subversion Server\httpd\modules).  Then you need to edit the httpd.conf file in the CollabNet install directory http\conf (default c:\program files\CollabNet Subversion Server\httpd\conf):

Add

	LoadModule sspi_auth_module modules/mod_auth_sspi.so

after the mod_auth.so load:

	LoadModule auth_module modules/mod_auth.so

then add

	LoadModule authz_svn_module modules/mod_authz_svn.so

 

after the mod_dav_svn.so load:

 

	LoadModule dav_svn_module modules/mod_dav_svn.so

Finally add

	
	# authentication	
	AuthName "Subversion Authentication"	
	AuthType SSPI	SSPIAuth On	
	SSPIAuthoritative On	
	SSPIDomain DOMAIN.COMPANY.COM	
	SSPIOfferBasic On	
	SSPIOmitDomain On 	
	SSPIUsernameCase upper	
	<LimitExcept GET PROPFIND OPTIONS REPORT>		
		Require valid-user	
	</LimitExcept>

within the <Location> tag at the end of the file following the location defaults

	DAV svn	SVNParentPath C:/svn_repository

The settings are in the main self explanatory, AuthType SSPI is fairly obvious as are SSPIAuth and SSPIAuthoritative (turning it on).  The SSPIDomain define the domain to authenticate against, and must be the full domain name.  The SSPIOfferBasic, SSPIOmitDomain and SSPIUsernameCase settings ensure the user is correctly prompted for authentication when requesting an operation other than the basic read ones listed in LimitExcept. 

There are ways to finely control access rights at all levels of the repository - but frankly I find the simplest configuration of recording the user who made the change rather than locking down easiest to manage in the long run.

After making the config changes restart the Apache server in the services.msc control panel plug in.  If it starts then you have done everything and just need to make sure that authentication details are recorded when you make repository changes (if you are using TortoiseSVN don't try this test using the repository browser to create folders it just doesn't request the authentication!).  If the service doesn't start then you have to start trial and error!  My recommendation would be to add the config items piece by piece in the order listed above checking the Apache logs as you go.  The authentication block is usually the tricky bit, again commenting out the salient bits (like SSPIDomain and LimitExcept) until the service starts.

Once you are at this point you can start additional configuration as required to more finely control access to the repository - however now is when I normally leave it...

Getting started with CruiseControl.NET and Subversion

The mini tutorial is designed to show how easy it is to get started with CruiseControl.NET . The aim will be to get a continuous integration build of a Visual Studio 2005 solution including nUnit unit tests running as quickly as possible using Subversion as the source control provider.

As ever the first step is to download it - the version used with this is CruiseControl.NET 1.3, which can be downloaded from:

http://sourceforge.net/project/showfiles.php?group_id=71179&package_id=83198&release_id=517823

Grab the CruiseControl.NET-1.3-Setup.exe and CruiseControl.NET-CCTray-1.3-Setup.exe setup kits.

Run the CruiseControl.NET-1.3-Setup.exe installation on the build server - the install is really basic.  Install all the components (CruiseControl.NET Server,Web Dashbord and Examples) make sure to Install CC.NET as Service and also Create Virtual Directory for the Web Dashboard.

While you are downloading and installing grab the XML logger from:

http://ccnetlive.thoughtworks.com/MSBuildXmlLogger-Builds/

Copy the logger binary (ThoughtWorks.CruiseControl.MSBuild.dll) to the CruiseControl.NET install dierctory (by default C:\Program Files\CruiseControl.NET\server).

Now to configuration, starting with the server...

On the build server checkout a working copy of the Visual Studio 2005 solution to somewhere sensible.  You need to make sure that the build works using MSBuild.exe.  Tghis is best done from the command line - if you don't know msbuild.exe is in C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 and command line to test will be:

	msbuild path to solution file /t:Clean /p:Configuration=Debug
	

Make sure the build is successful before moving on!

Now you configure the CruiseControl.NET server...

Open the ccnet.config file found in the server install directory which by default is C:\Program Files\CruiseControl.NET\server.  You are going to create a basic project entry to get tested and running.

<project name="Basic Project">

 

 

      <sourcecontrol type="svn">

 

 

            <trunkUrl>url to solution directory in subversion</trunkUrl>

 

 

            <workingDirectory>solution working directory</workingDirectory>

 

 

            <executable>C:\Program Files\CollabNet Subversion Server\svn.exe</executable>

 

 

      </sourcecontrol>

 

 

      <triggers>

 

 

            <intervalTrigger seconds="60" />

 

 

      </triggers>

 

 

      <tasks>

 

 

            <msbuild>

 

 

                  <executable>C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe</executable>

 

 

                  <workingDirectory>solution working directory</workingDirectory>

 

 

                  <projectFile>solution file name</projectFile>

 

 

                  <buildArgs>/p:Configuration=Debug /v:diag</buildArgs>

 

 

                  <targets>Build</targets>

 

 

                  <timeout>15</timeout>

 

 

                  <logger>C:\Program Files\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MSBuild.dll</logger>

 

 

            </msbuild>

 

 

      </tasks>

 

 

</project>

 

 

 

 

 

Some points to note in the basic settings above; the sourcecontrol trunkUrl element is the subversion url to the solution, and working directory both in source control and msbuild task are to the local check out directory.  The msbuild element also has the solution file name and paths to the msbuild exe and the logger we downloaded earlier.  The trigger is what fires the build, in this case every minute (if there have been committed changes) the build will run.

The logger is referenced from the copied location, you can exclude the logger path, but you would need to put the logger dll in each project working folder.

 

Next step is to get the CruiseControl build running using the ccnet.exe (default location C:\Program Files\CruiseControl.NET\server) from the command line:

	ccnet.exe -project:"project name"

All being well (basically if you haven't set anything wrong in the ccnet.config) this should also successfully build.  If not you need to tweak until it does.

So finally to get the unit test running....

The simplest way to get nUnit tests running is to use the nunit task which you configure in the ccnet.config file after the msbuild.  The following is the basic config:

<nunit>

 

      <path>C:\Program Files\NUnit 2.4.3\bin\nunit-console.exe</path>

 

      <assemblies>

 

            <assembly>path to unit test binary</assembly>

 

      </assemblies>

 

</nunit>

 

 

So nothing complex here - the path is the path to the nunit-console.exe, and for each unit test assembly add a full path to the output binary.  Again make sure everything works with the ccnet.exe from the command line, make sure the unit tests pass too, tweaking as needed to get running.   Once its all running smooth then you can start the CruiseControl.NET service.

Finally to monitor the state of the build from the development client, install the CCTray application from the CruiseControl.NET-CCTray-1.3-Setup.exe on each development machine - again a really basic installer.

Following install run cctray and in the File Settings menu select the Build Projects tab and add a Build Server.  You have choices as to which way to monitor the build, I suggest using the "Connect directly using .NET remoting" option supplying server name of the build server - even though the install recommends against this this is the only option which will support the force build option, allowing you to demand a build from the development client.

You will be displayed a list of available project(s), select the available project to monitor - you now have a nice system tray notification showing status of your CI build...

If you want to know more there is plenty to read http://confluence.public.thoughtworks.org/display/CCNET/Welcome+to+CruiseControl.NET.

Vista bits

We all know that users reject change - they inevitably want the new bit of software (that you have spent ages on) to look and operate 'exactly' like their last bit of software!  Clearly being one of those annoying users I have spent some time looking to making Vista operate 'exactly' like XP - well at least replicating some of the shortcuts I have got used to using. 

The first one was Send To.  I have got used to having Notepad and Notepad++ (amongst other things) in the send to menu - I find it a really quick way to get stuff done.  To edit the Send To menu in Vista you need to run:

%APPDATA%\Microsoft\Windows\SendTo

either in the run dialog or in an explorer.  Then you can drop in whatever shortcuts you want...

The other one I have got used to is the command prompt from the context menu.  Under XP its an addition to the registry for the directory to open a command prompt:

[HKEY_CLASSES_ROOT\Directory\shell\CommandHere] 
@="&Command here..." 
[HKEY_CLASSES_ROOT\Directory\shell\CommandHere\command] 
@="cmd.exe /k cd %1" 

I was dead chuffed to find that in Vista you don't have to bother as its built in - just hold down shift as you open the context menu and you get an "Open Command Window Here" option. You also (as a double bonus) get get a "Copy as Path" option - a zero hassle way to get paths for files and directories into the paste buffer.

TortoiseSVN and DiffMerge

I have used subversion as a source control repository for some time (without getting into the religious argument - I find it does the job really well); and recently I have started to use the DiffMerge tool from SourceGear (http://www.sourcegear.com/diffmerge/index.html).  I know there are loads of tools out there, I have found that this one does a reasonable job of just about everything (that's pretty much why I use it!).  I particularly like the implementation of the three file view for conflict resolution.

conflict

It doesn't take too much setting up to use with TortoiseSVN.  Open the Settings dialog from the TortoiseSVN Settings menu.

settings

In the External Programs section select Diff Viewer and select the External radio and supply the command line argument:

path\DiffMerge.exe /t1=Mine /t2=Original %mine %base

Make sure you supply a valid path to the installed DiffMerge product! When displaying changes this will display your version changes in the left panel with base in the right. 

To get the three panel merge select the Merge Tool in the External Programs section, and as before select the External radio and supply the following command line argument:

path\DiffMerge.exe /t1=Mine /t2=Base /t3=Theirs /r=%merged %mine %base %theirs

This will display three columns with your version, followed by the base version followed by the repository version - allowing you to merge changes from both sides into the centre at your leisure...

Using Workflow Foundation Rules Engine beyond Workflow ...

Most people are aware that Workflow Foundation is a massively powerful flexible toolset to allow you to build workflow based applications.  In true golden hammer style, once you have used it you will be surprised just how many problems look like they need to be solved with workflow!  What you may have missed is that part of the delivery is a very powerful rules engine that can easily be used outside of workflow applications.

In an effort to keep this post short I will keep it very simple and demonstrate how easy it is to use the rules engine outside of the context of workflow activities.

Before you start make sure you have .NET 3.0 installed (http://www.microsoft.com/downloads/details.aspx?FamilyID=10CC340B-F857-4A14-83F5-25634C3BF043&displaylang=en), installed the Visual Studio 2005 extensions for WF (http://www.microsoft.com/downloads/details.aspx?familyid=5D61409E-1FA3-48CF-8023-E8F38E709BA6&displaylang=en) and finally make sure you have read the excellent introduction to the rules engine by Jurgen Willis http://msdn2.microsoft.com/en-us/library/aa480193.aspx.

The simplest way to create a RuleSet is to use the RuleSetDialog in the System.Workflow.Activities.Rules.Design namespace to create and edit a RuleSet. The dialog is supplied a context object on construction - basically the type is reflected to see what is available for the intellisense on the editor dialog.  To use the RuleSetDialog you need to reference the System.Workflow.Activities and System.Workflow.ComponentModel assemblies.

RuleSetDialogCode

The RuleSetDialog allows you to define rules which are constructs similar to a basic If-Then-Else programming structure, with the condition and actions defined in an expression language based on the CodeDom model (read Jurgens article for more description).  Basically you can access properties and methods on you context object, and static methods on any class referenced within the host assembly.

RuleSetDialog

The RuleSet is serialisable (to XAML), so dead easy to create persist and reload collections of rules - you can work this bit out for yourself.

To execute a RuleSet you use the RuleEngine in the System.Workflow.Activities.Rules namespace.  You supply it an instance of your object and then Execute and off it goes.

RuleEngine

As you can see in this somewhat traditional bogus example, the rule checks for a literal value on a property of the context object, setting it to a different value if true.

Bogus though the example is, it doesn't take much imagination to picture how the rules engine can be harnessed to create massively powerful and extensible apps - with rules persisted outside of the app and editable by users that are able to operate on and affect data within your objects!  Get me a nail I have a new hammer...

Draggy bags...

You know those bags with wheels and handles! Hate them.  Crowded places like railway stations and airports where we are all herded through like sheep are annoying enough without having to trip over the little draggy bags - suitcases are easy to avoid, but the little ones just get under your feet!!

CruiseControl.NET installation in 7 easy steps

I often find people are intimidated by CruiseControl.NET. One of the phrases I have heard before is that it is "only really sensible for new projects" - the explanation behind this usually being that it is too difficult to set up for existing solutions.  This guide is designed to show how easy it is to get started on any .NET solution, no matter where in the development phase. 

The primary goal of this guide is simply to create a nightly build of a project maintained in Visual SourceSafe 2005 with CruiseControl.NET - one of the simplest configurations you can imagine. Those of you doing continuous integration will already recognise this as the first in many baby step's that can be taken to improve existing process using CruiseControl.NET (hopefully the subject of a future article). Those of you who want more information on what continuous integration is and can do to help may find these articles useful:

http://www.martinfowler.com/articles/continuousIntegration.html

http://confluence.public.thoughtworks.org/display/CCNET/What+is+Continuous+Integration

Step 1 is to download and install the CruiseControl.NET application from http://sourceforge.net/projects/ccnet/ - pretty straight forward!  The version dealt with in the post is 1.3 which was released 21/06/2007.

Step 2 is to get the project(s) buildable using MSBuild from the command line, this is just a simple check to make sure the projects work! eg:

	msbuild c:\test\app.sln /t:Clean /p:Configuration=Debug
	

Step 3 create a VSS user specifically for CruiseControl.NET to log in as.

Step 4 configure the ccnet.config file which is found in the installation directory (default Program Files\CruiseControl.NET\server).  Simple config will require the a project with sourcecontrol section, an interval trigger and an msbuild, eg:

<cruisecontrol>
  <project name="TestCCNET">
    <sourcecontrol type="vss" autoGetSource="true" applyLabel="true">
      <executable>E:\Program Files\Microsoft Visual SourceSafe\ss.exe</executable>
      <project>$/TestProject</project>
      <username>ccnet</username>
      <password>ccnet</password>
      <ssdir>e:\vss\</ssdir>
      <workingDirectory>E:\work\LocalVSS\TestProject</workingDirectory>
      <cleanCopy>true</cleanCopy>
    </sourcecontrol>
    <triggers>
      <intervalTrigger seconds="60" />
    </triggers>
    <tasks>
      <msbuild>
        <executable>C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe</executable>
        <workingDirectory>E:\work\LocalVSS\TestProject</workingDirectory>
        <projectFile>TestProject.sln</projectFile>
        <buildArgs>/noconsolelogger /p:Configuration=Debug /v:diag</buildArgs>
        <targets>Build</targets>
        <timeout>15</timeout>
        <logger/>
      </msbuild>
     </tasks>
    <publishers>
      <xmllogger />
    </publishers>
  </project>
</cruisecontrol>

Don't be frightened - when you actually look at it - there is very little required, just the source safe details and solution location!  Note that we have set the build interval to 60 seconds - this will allow us to test the configuration easily in the next step.

Step 5 download the XML Logger for MSBuild from http://ccnetlive.thoughtworks.com/MSBuildXmlLogger%2DBuilds/ and copy to the the project workingDirectory (in the example above this is set to E:\work\LocalVSS\TestProject). This logger is used by CruiseControl as described in http://confluence.public.thoughtworks.org/display/CCNET/Using+CruiseControl.NET+with+MSBuild.

Step 6 is to check the configuration setting using the command line tool.  The ccnet.exe command line tool can be found in the server directory beneath the install directory (default Program Files\CruiseControl.NET\server).  The console will run the settings and attempt the build every 60 seconds (as configured previously).  The console output is good and it should not take you long to get a basic configuration like the example above working.

You can use the Web Dashboard to force through a build (so you don't need to make a change in SourceSafe!). The Web Dashboard will be available at http://server/ccnet and the Force button is available under the admin header for each server.

Step 7 finally change the ccnet.config to replace the 60 second interval trigger with a schedule trigger eg:

<scheduleTrigger time="23:30" buildCondition="ForceBuild" name="Scheduled">
</scheduleTrigger>

Which again is fairly straight forward and will run the build every day at 2330.

So that's it CruiseControl.NET up and running to run nightly builds in 7 steps! You can now use the service rather than the command line to listen for builds, and you can use the web dashboard on the CruiseControl.NET server (http://server/ccnet) to see status of builds and force builds (when the service is running).

Clearly there is loads more that CruiseControl.NET can do (notably run your unit tests) all of which you can find using the ThoughtWorks documentation site

http://confluence.public.thoughtworks.org/display/CCNET/Welcome+to+CruiseControl.NET