WCF and FitNesse - how to load the client's config file

Firstly, here is a great post on how to get started with FitNesse - http://schuchert.wikispaces.com/Acceptance+Testing.UsingSlimDotNetInFitNesse. This is what I used to get started. What I wanted to do was use FitNesse to perform integration tests for my web services - which means the assembly that the fitsharp runner loads, must also load the config file for that assembly (as it contains the service model configuration which is required when we create the client proxy within the loaded assembly).

Under the Create a page with necessary configuration heading in the above link, it defines how to setup your test fixtures to use the .Net test runner. The line we're interested in the one below.

!define COMMAND_PATTERN {%m -r fitSharp.Slim.Service.Runner,c:\tools\nslim\fitsharp.dll %p}

We need to update this line to include a reference to the our test project's config file. So an example would be:

!define COMMAND_PATTERN {%m -a c:\projects\someapplication\acceptancetests\acceptancetests.dll.config -r fitSharp.Slim.Service.Runner,c:\tools\nslim\fitsharp.dll %p}

This allows you to load the config where your acceptancetests.dll makes a call through a WCF proxy (i.e. acceptancetests.dll contains the type which Runner.exe will call - and this type calls the service)

MSDeploy, MSBuild and environment specific config files

MSBuild's property switch (/p:) allows you to override project-level properties. Using /p, you can specify which configuration you wish to build against - therefore if you have your environment specific config files transforming correctly (more details here http://blogs.msdn.com/b/webdevtools/archive/2009/05/04/web-deployment-web-config-transformation.aspx) – you can automate building environment specific deployment packages using MSBuild by using the target switch (/t:) and specifying Package - which results in MSDeploy being the deployment mechanism used.

So an example of this: MSBuild "[project name].csproj" /T:Package /P:Configuration=[environment configuration name i.e. Staging];PackageLocation="[zip file name & path]"

So the model would be - create a config file per (configuration) environment, and create a deployment package per (configuration) environment using the above command line. Therefore you have a deployment package per environment ready to go without have to make any environment specific changes to the config files. Nice and clean, plus with the added bonus that the package generated contains a deploy.cmd file which encapsulates MSDeploy to roll out the package.

More useful info on MSBuild and packaging: http://vishaljoshi.blogspot.com/2009/02/web-packaging-creating-web-packages.html

MSDeploy bug with config providers

Discovered a small but annoying bug when synching config files where the destination config file doesn't have the configSections element declared (which is common when synching the root web.config file), and the source config file does have this section (so in other words the configSections element will be added along with the new section/sectionGroup definition)

So assuming you have the required synching rules turned off (SchemaSection rule, or editing the MSDeploy config settings file), after the synching occurs, the new configSections element is created by MSDeploy... however, it's not placed at the top of the config as the first child element of the root configuration element.

If the configSections element is in a configuration file, the configSections element must be the first child element of the configuration element.

So the work around, is to manually add the configSections to the destination config file before performing the sync. Doing so means that new section/sectionGroup is added in the correct place in the config file.

MSDeploy 1.1 does not sync 4.0 assemblies

Doesn't seem to be a lot on info on this, hence I spent a while trying to sync some .Net 4.0 assemblies using MSDeploy - however, received confirmation today from the IIS team that version 1.1 of MSDeploy can't do this. Obviously this is on the feature roadmap since you can sync the 4.0 machine and web config files.

http://forums.iis.net/p/1168877/1949692.aspx