OK - sometimes it just to confess - I took a chance, or didn’t know what I was doing - call it what you want.

In TFS Build-scripts there are a much nicer way of calling MSTest than the Exec-task as I suggested. There is already a task for it, called TestToolsTask. With this task you can much easier reach all the properties you need. And it even contains some undocumented features such as the TestContainer-property.

Here is my updated version on how to call the task:

<TestToolsTask   TestContainers="$(BinariesRoot)\Debug\Company.Service.Host.Test.Integration.dll"
          BuildFlavor="%(ConfigurationToBuild.FlavorToBuild)"
          Platform="%(ConfigurationToBuild.PlatformToBuild)"
          PublishServer="$(TeamFoundationServerUrl)"
          PublishBuild="$(BuildNumber)"
          PathToResultsFilesRoot="$(TestResultsRoot)\..\IntegrationTestResults"
          TeamProject="Betalningsplattformen2"
          ContinueOnError="true" />

[UPDATED, see this]

I have created a task that runs some unit tests in a certain DLL and the publish the result to a TFS service. We use this task in our TFS MSBuild script in order to execute some integration tests in the last step of the build process. In order to get some value from the integration tests the solution needs to be deployed, for example.

The most tricky parts of figuring this out was:

• The path to MSTest.exe - as it turns out there are a environment variable to the root of the Visual Studio Tools - %VS90COMNTOOLS%. And via that we can reach MSTest.exe with %VS90COMNTOOLS%\..\IDE\MSTest.exe
• To publish a build you need the buildId to send to the publishbuild-parameter of MSTest. It can easily be obtained from the TFSBuild parameter $(BuildNumber)

So here you are - my task to run tests...

I had a quite strange experience today. I did a presentation about unit testing for another project. Nothing strange there. But the thing was recorded (via LiveMeeting, worked great after some initial confusing surrounding the mic) and then put out on the developer portal of my customer.

So later on I heard my lame jokes echoing through out the nearby workstation. Excruciating painfully… it’s just not funny the forth time you hear your own jokes…

Quite cool experience though. I like doing presentations.

In my current project we have reached a very good code coverage percent (98,7 %, yes we are proud) - but we are aspiring to take it a step further.

We are now constructing a series of integration test, used to run through the actual production code an verifying that everything works as expected.

Said and done - I implemented a few test that did that. Soon though some questions and problems arose;

• Integration test assumes that something is released and the that tests are executed against that release
• You don’t want the integration test to be executed when a developer is running the unit test on his development machine inside Visual Studio.

When looking around on the net it seems that many people are missing the Category-attribute from NUnit in MSTest. That looked like a very nice way to solve the problem but...

We have for several days now been chasing a bug for a couple of days now. Very, very annoying…

Here is how it goes:

We have a unit test on that calls an stored procedure in Oracle, using ODP.NET. On our local machine (and also on the test server) everything works fine. But when the build script is running the unit test, a out-parameter of the DATE-datatype was always returned as NULL.

This was so strange since it’s the same code against the same database instance. The difference was that is was another account, the TFS Build Service Account, that was running the tests.

The solution was to configure the regional settings for TFS Build Service Account to use Swedish (in our case) Regional Settings as the default user profile.

**[UPDATED] **That...

First and foremost- I love Resharper (4.0), but I think that some small flaws are still there and does bad things…

Two things are at the top of my list (in all honesty I must admit that I can’t be 100% sure that ReSharper has to do with this but both of them has occurred after I’ve installed ReSharper):

• ASPX-pages are very, very slow to load in design-mode. It can take about a minute to switch from the html-code to the design-view
• The Build supervisor (you know, the view where you stare at the progress of the build, keep your fingers crossed and hopes for only green dots…) crashes very frequently.

I have reported these bugs to ReSharper and hope that a fix will be available to fix this. I still love Resharper though.

Oh yeah - that’s right - I found that the Read More

One of the really cool features of WCF is the possibility to be able to change binding in the config… Of course the transport need to be supported by the host. For example you can’t use TCP/IP transport in a web-site hosted service.

So - you’ll have to create the host by yourself - selfhosting. However there are some nasty configuration to be done in order to get the service to work. Otherwise you’ll get this error message:

HTTP could not register URL http://+:[yourport]

Here is an article from Microsoft describing how to get it to work. And here is another article describing how to solve it

In my last post I mentioned the great WCF service/client configuration editor that ships with Visual Studio 2008. I haven’t used it much but rather done “it” by hand - which has been quite painful from time to time.

Here is a great introduction to the editor that shows off some of the great capabilities of it.

Another “tip”, if you like, that I found on my way through the configuration jungle is that the binding part is complete separated from the other part of the configuration. Also, the client and server binding should be configured the same way (at least for a single endpoint). This means, and is actually quite effective, that you can copy the binding part from one .config-file to another to get the same configuration. An easy but very helpful tip.

This area is (in the words of Juwal Löwy) “truly vast”. And as I read somewhere else most of the properties doesn’t make sense to the common programmer. We (yeah, I’m one of the common ones) just want it to work.

Also, when it comes to configuring WCF services Microsoft has gone the complete opposite way from their normal way of doing things; normally Microsoft hides everything you don’t need to know from you and you’ll have to dig to get to the advanced things. When it comes to WCF all the possible values are shown right off - scared the living daylights of of me. Just add a reference to a WCF-service and check your client .config-file.

So what to do - well I’m sorry but you’ll need to know quite a bit of information, here are some resources that I have found useful:

• The book...

Yes - I know that this is quite rare but if you want something really easy in place then this is how to use wsHttpBinding with no security:

<service name=”FaktureringsTjanst” <endpoint address=”” binding=”wsHttpBinding” bindingConfiguration=”myBindingConfigurationWsHttp” contract=”IContract” behaviorConfiguration=”FaktureringsTjanstBehavior” /> </service> </services>

<!– Bindings –> <bindings> <wsHttpBinding> <binding name=”myBindingConfigurationWsHttp” maxReceivedMessageSize=”500000” sendTimeout=”00:05:00” receiveTimeout=”00:05:00”> <security mode=”None”> <message clientCredentialType=”None” /> </security> </binding> </wsHttpBinding> </bindings>