3

Solved: Look at the bottom of this question for the working configuration


I am attempting to set up NCover for usage in my FinalBuilder project, for a .NET 4.0 C# project, but my final coverage output file contains no coverage data.

I am using:

All tools are the latest official as of today.

I've finally managed to coax FB into running my unit tests under NCover for the .NET 4.0 project, so I get Tests run: 184, ..., which is correct.

However, the final Coverage.xml file output from NCover is almost empty, and looks like this:

<?xml version="1.0" encoding="utf-8"?>
<!-- saved from NCover 3.0 Export url='http://www.ncover.com/' -->
<coverage profilerVersion="3.3.2.6211" driverVersion="3.3.2" exportversion="3" viewdisplayname="" startTime="2010-04-22T08:55:33.7471316Z" measureTime="2010-04-22T08:55:35.3462915Z" projectName="" buildid="27c78ffa-c636-4002-a901-3211a0850b99" coveragenodeid="0" failed="false" satisfactorybranchthreshold="95" satisfactorycoveragethreshold="95" satisfactorycyclomaticcomplexitythreshold="20" satisfactoryfunctionthreshold="80" satisfactoryunvisitedsequencepoints="10" uiviewtype="TreeView" viewguid="C:\Dev\VS.NET\LVK.IoC\LVK.IoC.Tests\bin\Debug\Coverage.xml" viewfilterstyle="None" viewreportstyle="SequencePointCoveragePercentage" viewsortstyle="Name">
  <rebasedpaths />
  <filters />
  <documents>
    <doc id="0" excluded="false" url="None" cs="" csa="00000000-0000-0000-0000-000000000000" om="0" nid="0" />
  </documents>
</coverage>

The output in FB log is:

...
***************** End Program Output *****************

Execution Time: 1,5992 s

Coverage Xml: C:\Dev\VS.NET\LVK.IoC\LVK.IoC.Tests\bin\Debug\Coverage.xml
NCover Success

My configuration of the FB step for NCover:

  • NCover what?: NUnit test coverage
  • Command: C:\Program Files (x86)\NUnit 2.5.4\bin\net-2.0\nunit-console.exe
  • Command arguments: LVK.IoC.Tests.dll /noshadow /framework:4.0.30319 /process=single /nothread
    • Note: I've tried with and without the /process and /nothread options
  • Working directory: %FBPROJECTDIR%\LVK.IoC.Tests\bin\Debug
  • List of assemblies to profile: %FBPROJECTDIR%\LVK.IoC.Tests\bin\Debug\LVK.IoC.dll
    • Note: I've tried just listing the name of the assembly, both with and without the extension.

The documentation for the FB step doesn't help, as it only lists minor sentences for each property, and fails to give examples or troubleshooting hints.

Since I want to pull the coverage results into NDepend to run build-time analysis, I want that file to contain the information I need.

I am also using TestDriven, and if I right-click the solution file and select "Test with NCover", NCover-explorer opens up with coverage data, and if I ask it to show me the folder with coverage files, in there is an .xml file with the same structure as the one above, just with all the data that should be there, so the tools I have is certainly capable of producing it.

Has anyone an idea of what I've configured wrong here?


Solved: The following configuration finally worked for me. It produces a code coverage basic statistics on the start results page for a build, with a link to a detailed report with everything.

Since I name my unit test projects the same as the project it tests, only with a .Tests suffix, I've excluded those from the code coverage. Also, I had to specifically include only my own assemblies (which all start with LVK.) otherwise I would get some assemblies loaded by the TeamCity runner, which slightly impacted my coverage statistics.

First, I installed latest of the tools (as of this edit):

  • NCover 3.4.8
  • TeamCity 5.1.2
  • NUnit 2.5.5

The configuration on the build-screen in TeamCity is then as follows:

  • Targets: Rebuild
  • Configuration: Debug
  • Platform: Any CPU
  • .NET Coverage Tool: NCover (3.x)
  • .NET Runtime: .NET Framework 4.0, Version: Native
  • Path to NCover 3: %system.ncover.v3.x64.path% (this is Windows 2008 Server R2 64-bit)
  • Additional NCover Arguments:

    //ias LVK.*
    //eas .*Tests
    //eas LVK\.CodeQuality
    //ea LVK\.CodeQuality\.IgnoreCodeCoverageAttribute
    
  • Additional NCover Reporting Arguments:

    //or FullCoverageReport:Html:{teamcity.report.path}
    
  • NUnit Runner: NUnit 2.5.5

  • .NET Runtime Platform: auto (MSIL), Version: 4.0
  • Run tests from: **\bin\Debug*Tests.dll
Lasse V. Karlsen
  • 380,855
  • 102
  • 628
  • 825
  • I have the same problem with the same settings, even using the latest NCover (3.4) that supports .NET 4.0 – Ray Apr 27 '10 at 13:54
  • I've stopped looking at this for now, I've tried integrating NCover with NUnit for TeamCity 5.1 as well, but it invariably fails, and the documentation on any of the tools involved in this is below par on these topics so it's trial-by-error and I frankly have no time to meddle with it. For the time being I will run my code coverage from within Visual Studio instead. – Lasse V. Karlsen Apr 27 '10 at 14:30
  • @Lasse, did you manage to get anywhere with this? I have exactly the same problem. works with TD.NET for me too. Also works in the cmd.exe. No joy wtih FinalBuilder though. – Damian Powell May 29 '10 at 16:17
  • I'm sorry, I actually gave up, I split the job into several TeamCity steps so that I could run the important parts with just TeamCity configuration, thus allowing me to run NCover. The rest I placed into FinalBuilder, but I didn't have time to figure out this, I just had to get something working. It cost me 3 build steps in the TeamCity server, and since I'm using the free "max-20-build-steps" version, I will eventually have to deal with this, but for now I can't justify the time. My apologies. – Lasse V. Karlsen May 29 '10 at 19:44
  • I accepted the specific answer because that is documented to be supposed to work. It actually doesn't in my case, but I don't actually know if that is a problem specific to my case or a general problem. I have been a fan of FinalBuilder for quite some time now, but lately I've been hitting a wall with some things with it, **and since the documentation is basically written by an automated version of GhostDoc**, it is unhelpful to say the least so I'm trying to avoid it for the time being. – Lasse V. Karlsen May 29 '10 at 19:46
  • No problem. It's tricky. I sent an email to Jamie Cansdale to ask him how he managed to do it in TestDriven.net. If he replies to me, I'll post an answer. I'm fairly convinced the issue is something to do with .NET 4 and multiple App Domains though. – Damian Powell May 30 '10 at 07:48
  • Updating to TeamCity 5.1.2 and NCover 3.4.8 (latest as of this post) made it work, I'll update my question with the working configuration for future reference. – Lasse V. Karlsen Jun 11 '10 at 19:29

2 Answers2

1

As far as I know, NCover is not capable of covering tests for .NET 4.0. They announced a new version for .NET 4.0 but it is not there yet.

Find info on the subject here. Personally I have no experience with this task...

Update: They released NCover 3.4 with .NET 4.0 support. Perhaps You give it a try.

The Chairman
  • 7,087
  • 2
  • 36
  • 44
  • 1
    Well, it works perfectly from within Visual Studio when invoked through TestDriven, then it runs NCover, NUnit, and presents the coverage data in the NCoverExplorer program just fine. – Lasse V. Karlsen Apr 22 '10 at 21:12
  • The issue is where you have a mixture of .net 4.0 and 3.5 or 2.0 as it will switch to only tracing the 3.5 and 2.0 assemblies. – Nigel Thorne Jun 01 '10 at 06:02
0

I've found your answer from this thread: NUnit isn't running Visual Studio 2010 code

To the nunit-console-x86.exe.config file, under <configuration> add:

<startup>
  <requiredRuntime version="v4.0.30319" />
</startup>

Under <runtime> add

<loadFromRemoteSources enabled="true" />

Fixed it for me. I'm using TeamCity not FinalBuilder though.

I'm also using NCover 3.4.

Community
  • 1
  • 1
Ray
  • 45,695
  • 27
  • 126
  • 169
  • No, that's not the problem. Without those things, NUnit won't even run and NCover won't produce a file at all. I've already done this to make NUnit work on .NET 4.0. – Lasse V. Karlsen Apr 28 '10 at 09:36
  • Okay, well before I made those changes nUnit was running, but with the same problems you had, afterwards it works properly. – Ray Apr 28 '10 at 10:14