WPF designer gotcha when setting TextDecorations in triggers

I just came accross a nasty gotcha with the Visual Studio 2008 WPF designer (Cider). When setting the TextDecorations property for a control using a trigger, the following code will work at runtime, but the designer will complain with “Must specify both Property and Value for Setter. Error at object ‘System.Windows.Setter’, Line 1 Position 737″.

<ControlTemplate.Triggers>
<Trigger Property=”IsMouseOver” Value=”True”>
<Setter TargetName=”contentSite” Property=”TextDecorations” Value=”Underline”/>
</Trigger>
</ControlTemplate.Triggers>

To prevent the designer complaining, you have to use the full syntax for setting TextDecorations, as below:

<ControlTemplate.Triggers>
<Trigger Property=”IsMouseOver” Value=”True”>
<Setter TargetName=”contentSite” Property=”TextDecorations”>
<Setter.Value>
<TextDecorationCollection>
<TextDecoration Location=”Underline” />
</TextDecorationCollection>
</Setter.Value>
</Setter>
</Trigger>
</ControlTemplate.Triggers>

This seems to keep the designer happy and behaves the same at runtime as the first example - looks like there’s a bug in the converter for TextDecorations somewhere that’s causing this…

JSUnit MSBuild task

This is just a quick post to describe how to use the JSUnit MSBuild task (which you can download here). JSUnit currently ships with JUnit fixtures and ant wrappers to call these - this is essentially an MSBuild task wrapper around the StandaloneTest JUnit fixture (and so requires Java as well). Also there are a few things to bear in mind if you use this in a continuous integration scenario, namely that the process will need to fire up your browser of choice and so will need to interact with the desktop, and that with the current state of JSUnit it is best to access the test runner / pages over http (instead of using file://). Don’t forget you can’t mix and match file: and http: otherwise you’ll get x-site scripting errors in certain browsers.

Anyhoo, to use the task, first include it in your build file like so:

<import project=”$(MSBuildJSUnitTasksPath)\MSBuild.JSUnit.Tasks.Targets”></import>

I’ve previously defined the MSBuildJSUnitTasksPath property to point to the directory where the MSBuild.JSUnit.Tasks.Targets and MSBuild.JSUnit.Tasks.dll are located. Having imported the targets you can then call the task using:

<StandaloneTest
JSUnitDir=”$(JSUnitDir)”
TestRunnerLocation=”http://localhost/JsUnit/TestRunner.html”
TestsPageLocation=”http://localhost/TestPages/Foo.html”
LogsDirectory=”$(JSUnitLogDir)”
Port=”3333″
BrowserFileNames=”c:\program files\Internet Explorer\iexplore.exe”
ContinueOnError=”true”>
<Output TaskParameter=”TestsFailed” PropertyName=”JSUnit_Failed” />
<Output TaskParameter="TestsPassed" PropertyName="JSUnit_Passed" />
<Output TaskParameter="TestsRun" PropertyName="JSUnit_Run" />
</StandaloneTest>

A few things are going on here. This task will attempt to call the JUnit test provided by JSUnit. This fires up a results server on port 3333 and then loads IE with the specified test runner / test page causing the results to be submitted to the results server and an xml report generated. This report will be placed in the location specified by LogsDirectory along with an HTML report generated by the MSBuild task. The output parameters capture the test statistics if you need to use them later (e.g. for TeamCity reporting ) but remember these only work if the tests succeed (hence the ContinueOnError=”true”). You can then cause the build to fail by looking at the output parameter if you need to.

TeamCity MSBuild tasks

For our latest product, we’ve switched over from CC.NET to the excellent TeamCity continuous integration server from JetBrains, which, as of version 3, is free for small projects like ours. One of the nice aspects of TC is that it’s very easy to publish data from your build (such as number of unit test passes / failures) so that it gets picked up by the TC server.

To help us along, we’ve written a few simple MSBuild tasks which do just that. We’ve created a sourceforge project for them, but until that’s activated, you can download them here.

There are currently 3 tasks:

MSBuild.TeamCity.Tasks.TeamCityAppendStatusText

Appends text to be displayed in the build status when the build is complete - e.g. “Tests Passed: 3, Tests Failed: 1″

Example usage:

<TeamCityAppendStatusText TeamCityInfoPath="$(teamcity_build_checkoutDir)\teamcity-info.xml" Value="Tests Passed: 3" />
<TeamCityAppendStatusText TeamCityInfoPath="$(teamcity_build_checkoutDir)\teamcity-info.xml" Value="Tests Failed: 1" />

MSBuild.TeamCity.Tasks.TeamCityAddStatistic

Adds a build statistic that can be picked up for graphing by configuring TeamCity’s main-config.xml (see here).

Example usage:

<TeamCityAddStatistic TeamCityInfoPath="$(teamcity_build_checkoutDir)\teamcity-info.xml" Key="TestsPassed" Value="3" />
<TeamCityAddStatistic TeamCityInfoPath="$(teamcity_build_checkoutDir)\teamcity-info.xml" Key="TestsFailed" Value="1" />

MSBuild.TeamCity.Tasks.TeamCityAddStatisticList

Variation on the above which allows you to add multiple statistics at once. Each key/ value pair is delimited by ‘;’

Example usage:

<TeamCityAddStatisticList TeamCityInfoPath="$(teamcity_build_checkoutDir)\teamcity-info.xml" KeyValuePairs="TestsPassed=3;TestsFailed=1" />

Thats pretty much it for now as  that’s all we’re using. I’ll post a follow up shortly to show how you can use these to pull in results from MbUnit tests.

If you missed the link above, you can download the tasks here.

Microsoft don’t get it

This post from Jamie Cansdale, the author of TestDriven.NET, just goes to show how much MS misunderstand about how to treat their developer community. I realise they provide a huge amount of their own development material and resources to us, but moves this like just illustrate the attitude I was writing about in my previous post.

Seems like a pretty good way of discouraging innovation around the VS express editions…