Thursday, 22 April 2010

Visual Studio 2010 and Team City (MSBuild 4.0 and NUnit)

I’ve recently started upgrading some of our projects to use Visual Studio 2010.  As we use Team City as our continuous integration environment I had to install .NET 4.0 on the server as the Visual Studio msbuild (csproj and sln files are msbuild files) won’t build using .NET 3.5 or below correctly.  Team city however can’t tell that you’ve upgraded, so you need to add an environment variable to each project you upgrade:

MSBuild set to %system.DotNetFramework4.0_x86_Path%

This does the trick (after much searching to find that), but once you’re done if you’re using nUnit then you’re in for another world of hurt.  Team City 5 will support .NET 4.0 but not the version that comes with Visual Studio 2010 (at the time of writing).  Visual Studio 2010 will install v4.0.30319 but nUnit will only work with up to v4.0.30128 (again at the time of writing, hopefully JetBrains release a new version soon).

You can TELL the dotNet plugin to work with the correct framework, it’s a pain in the ….. well it’s messy, but it works. 

Open the <server>\webapps\root\update\plugins directory and copy down the file.  Unpack it and open the dotnetPlugin\bin directory.  Open each file matching the wildcard JetBrains.TeamCity.PlatformProcessRunner.v4.0*.exe.config and modify the startup section to show the following:

<supportedRuntime version="v4.0.20506"/>
<supportedRuntime version="v4.0.21006"/>
<supportedRuntime version="v4.0.30128"/>
<supportedRuntime version="v4.0.30319"/>

You should probably already have the first three, I just had to add the last one.  Once you’ve done this your code should work after you tell the nUnit team city plugin to use .Net 4.0 instead of 2.0.

<Exec Command="$(teamcity_dotnet_nunitlauncher) v4.0 x86 NUnit-2.4.8  Project.Tests\bin\$(Configuration)\Project.Tests.dll" />

Underlined above.

Both those bits of information were available on the net, but hard to find and both found seperately.  Hopefully they help someone.

Friday, 9 April 2010

Code Bubbles – Spreading the hype

I came across something amazing today, Code Bubbles.



Andrew Bragdon should be commended for his work on this, it’s truly amazing and the amount of thought that has gone into it makes it very impressive.  Shame it’s a java IDE and I’m currently doing .NET development, but I plan on signing up to participate in the beta anyway.

Spreading the hype, this project deserves it.

Using ILMerge to Merge Several DLLS into a Single Library

We are building a shared library for our project and it includes a few references to other libraries as dependencies.  We don’t want to have to share all these, so I was hoping to use ILMerge to merge them into a single assembly that we could share.  I’ll use the continuous integration server to produce the dll and the projects can include it from the output location.  There’s relatively little information about how to use ILMerge, so I may as well blog about it.

Mind you, after a few tests I realised why.   After setting my system path to point to the installation of ILMerge, all you really need is the command line:

Ilmerge.exe /out:..\build\Publish\ProviderRedirection.dll ..\build\$(Configuration)\ProviderRedirectionSystem\ProviderRedirectionSystem.dll

So the next step is to integrate it into my MSBuild script.  Here we want to make sure that every DLL for the class library is merged into a single dll so we make an item group of the DLLS in the project and then pass them through to the command line.


<!--This group of files will be published as part of the website.-->
Exclude="..\**\.svn\**;..\**\*.pdb;..\build\Release\MySystem\MySystem.dll" />


<Target Name="PublishMySystem" DependsOnTargets="Clean;All">
<Message Text="Merging @(MyBinaries)"></Message>
<Exec Command="Ilmerge.exe /out:..\build\Publish\MySystem.dll ..\build\Release\MySystem\MySystem.dll @(MyBinaries->'&quot;%(FullPath)&quot;', ' ')" />