1

I've been struggling (not for the first time) to set up continuous integration on a project I've been working on. We use CruiseControl.NET, but that's not really been the problem - the majority of the problems have been to do with csproj + sln files and Visual Studio. After some mucking about I managed to solve them but thought I'd document what must be very common problems.

After getting the ccnet configuration up and running, the first problem I ran into was a compile error:

errorCS0234: The type or namespace name 'Gui' does not exist in the namespace 'NUnit' (are you missing an assembly reference?)

After resolving this another I got the familiar (and familiarly painful) 64 vs 32 bit problem:

System.BadImageFormatException: Could not load file or assembly '....' or one of its dependencies. An attempt was made to load a program with an incorrect format.
JonnyRaa
  • 7,559
  • 6
  • 45
  • 49
  • A few hints here: http://stackoverflow.com/questions/20427612/hudson-warning-msb3245-could-not-locate-the-assembly-nunit-framework/20433090#20433090 – granadaCoder Jan 02 '14 at 15:55
  • I'd suggest using NuGet to manage dependencies for you. Most of the time, It Just Works and your solutions work on any machine without having to manually install NUnit and the likes. – stijn Jan 03 '14 at 09:12
  • @stijn how does that work? most of the documentation/info on it makes the classic mistake of not introducing the program + what problem it solve and starts diving in with the details – JonnyRaa Jan 03 '14 at 13:30
  • @granadaCoder nice answer. no idea why they hide them from the properties window in vs2010 - one of the most important bits of info for a reference really. You also mention NuGet on there, could you expand a little on how that works + what it's for? – JonnyRaa Jan 03 '14 at 13:36
  • NuGet is a binary repository. One "publishes" and "retrieves" binaries there. See this for full explanation. http://lanyrd.com/2013/codemash/schedule/?topics=binary-repository,nuget – granadaCoder Jan 03 '14 at 14:44
  • @granadaCoder I might have missed something on that link but it just looked like an advert for a talk - are there some slides or something somewhere? so you can set things up to pull the relevant binary for a given point in history of a project? + also use to sort out dependencies at release time? – JonnyRaa Jan 03 '14 at 16:41

1 Answers1

0

The first problem was caused by 'hint-paths' being added by Visual Studio when I referenced the NUnit dlls. These paths were relative the Nunit install location on my local machine and the server isn't structured the same.

If you look at the properties in Visual Studio you wont see any mention of these hint-paths. Open up the relevant csproj in a text editor and you'll see something that looks like this:

  <HintPath>..\..\..\..\Program Files (x86)\NUnit 2.5.7\bin\net-2.0\framework\nunit.framework.dll</HintPath>

and replace it with something like this:

  <HintPath>$(ProgramFiles)\NUnit 2.5.7\bin\net-2.0\framework\nunit.framework.dll</HintPath>

In cruise control I was building against the solution file and not specifying what platform to target directly. This was causing the second problem. To fix this you can use Visual Studio. Open the solution and click Build=>Configuration Manager from the bar at the top. In the active solution platform I just had 'x86'. Select 'New' from the drop down and pick 'AnyCpu', then choose to copy settings from '', and leave create new project platforms ticked. Thats it! Click ok, close the config manager and then do a ctrl+shift+S to save all (including csproj + sln).

JonnyRaa
  • 7,559
  • 6
  • 45
  • 49
  • Was this a part of the "Console Apps default to x86" behavior? (Aka, is your unit-tests project an exe or dll) – granadaCoder Jan 02 '14 at 18:21
  • its an exe. You might be onto something there - I think the way I added it was as a console app but then changed the output type to WinExe instead of Exe. It's setup so F5 fires up the NUnit Gui-Runner – JonnyRaa Jan 03 '14 at 13:24