chevron-thin-right chevron-thin-left brand cancel-circle search youtube-icon google-plus-icon linkedin-icon facebook-icon twitter-icon toolbox download check linkedin phone twitter-old google-plus facebook profile-male chat calendar profile-male
Welcome to Typemock Community! Here you can ask and receive answers from other community members. If you liked or disliked an answer or thread: react with an up- or downvote.
0 votes
Hello everyone,

First, thank you for your patience, and thanks to all who posted tips/tricks on this subject. I have attempted most of them (the ones that seem to apply), but have had no luck yet.

We have a somewhat unique situation: our build server is not under our control. Our company is organized so that there is a separate SCM team and Development team, and the SCM team is also in a geographically different location. We are not, at this time, attempting to integrate Ncover/Typemock with our build server. However, our local management is interested in tracking code coverage statistics. It has fallen to me to make this happen.

Before we began using Typemock, I was able to generate all of the code coverage reports I needed with NCover through a simple command line. I developed a standalone console app that dynamically determines which of our apps-under-development I'm interested in generating statistics for. It then generates the proper command line text and shells out to a new process to perform the task itself.

This command line no longer works, because we now need to run NCover through Typemock runner. I've been experimenting with no luck whatsoever. Below is the command line code that is generated.

"c:\Program Files\Typemock\Isolator\6.0\TMockRunner.exe" -first -link NCover3.0 "C:\Program Files\NCover\ncover.console.exe" "C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\MSTest.exe" /testcontainer:C:\_Source\Libraries\_UnitTests\CommonApp.UnitTests\bin\Debug\CommonApp.UnitTests.dll //h "\\remotemachine\Data\CoverageReports\CommonApp" //at "C:\data\coverage\CommonApp\trends.trend" //x "C:\data\coverage\CommonApp\coverage.xml" //l "C:\data\coverage\CommonApp\coverage.log" //ll "Normal" //onlywithsource //pm "vstesthost.exe" //p "CommonApp Code Coverage" //ssp "Registry, SymbolServer, BuildPath, ExecutingDir"


The above code actually executes all of the tests as expected. However, it always results in "No data was collected", so I wind up with absolutely no coverage results.

Additionally, I get the infamous exit code #20000. I've repaired my installation a number of times, and used the Isolator Configuration to link the NCover 3.0 profiler (incidentally...it doesn't seem to persist this linkage from execution to execution....).

Any help you can offer would be greatly appreciated!

- Nat
asked by (840 points)

12 Answers

0 votes
Do you need to use a command line, or can you use MSBuild tasks? It may be a little more verbose, but it also may be easier to troubleshoot. I have an article about getting it to work with the build tasks here: http://www.paraesthesia.com/archive/200 ... build.aspx

Using the MSBuild tasks, it may also be easier to do that dynamic generation of assemblies to test/analyze, too - using <Item> elements.

If you have to use the command line, this article I posted talking about getting things linked up outside Visual Studio might help: http://www.paraesthesia.com/archive/201 ... tudio.aspx
answered by (6.7k points)
0 votes
At this point I don't have (convenient) access to our TFS build server, so I'm relegated to doing this, periodically, on my local development box. Once or twice a week my manager will expect code coverage reports. We're weeks away from moving on integration with our build server. At that point, this will be in the hands of our SCM team and I won't have to worry too much about it.

In the meantime, however, I'm going to be expected to generate these reports locally. My TFS administration experience is limited at this point (and somewhat removed in time...about 2 years ago was the last time I touched a build script. And prior to that my experience with it was sporadic at best.) Is there a way I can make use of the build script method on my local dev box? My instinct is telling me the answer to that question is "no", but I'm not a TFS expert by any stretch.

Looking back over the code I posted, it appears I have all of the necessary elements mentioned in your article. Is it possible I have them in the wrong order? For example, it appears that I'm making the call to MSTest immediately following the invocation of ncover.console.exe. If I read your article correctly (the section immediately prior to "Command Line Execution"), it appears I actually need to place the coverage/logging parameters *before* the parameter that invokes MStest.
answered by (840 points)
0 votes
Followup:

My suspicion about order-of-operations turned out to be incorrect. I moved the ncover-related parameters to immediately after the call to ncover.console.exe, but the result is the same.
answered by (840 points)
0 votes
Hi,

This may happen sometimes where the link between the two profilers gets broken. Can you please try and reinstall NCover and Isolator. It seems like you're using the correct command line on a x86 platform (correct me if I'm wrong).

Does it happen after reinstall?

Regards,
Elisha,
Typemcok Support
answered by (12k points)
0 votes
Hi,

This may happen sometimes where the link between the two profilers gets broken. Can you please try and reinstall NCover and Isolator. It seems like you're using the correct command line on a x86 platform (correct me if I'm wrong).

Does it happen after reinstall?

Regards,
Elisha,
Typemcok Support


I've reinstalled both, but so far the symptoms haven't changed.
answered by (840 points)
0 votes
MSBuild scripts aren't limited to TFS. You can run them from a VS command prompt using MSBuild.exe:

MSBuild.exe MyBuildScript.proj

In fact, .csproj files ARE MSBuild scripts. You can build them just like any other build script.

MSBuild.exe MyProject.csproj

Or you can build an entire solution (though .sln files are not in MSBuild format, MSBuild still understands them):

MSBuild.exe MySolution.sln

(This is how all build servers integrate with VS solutions/projects, not just TFS.)

I'd still recommend trying to get this working with a build script since it's easier to troubleshoot. Shelling from one command line (Typemock) to another (NCover) to another (MSTest) is sort of a tough row to hoe.
answered by (6.7k points)
0 votes
Thanks, Tillig. I wasn't aware of this. I'm going to go down this path today and see if I can get things working. I'll report back one way or another.

Nat
answered by (840 points)
0 votes
A couple of questions for tillig so far:

1. I noticed in your sample build script, it appears the purpose is to integrate NUnit as well. We're not using NUnit at this time, just mstest. Do I replace the path to NCover with the path to MSTest?

2. Batching: On my particular project, I'm going to end up with 3 different test assemblies, but they each live in their own separate output directories (we have a complex solution with many projects). It appears that you use a single "CreateItem" call to enumerate over multiple assemblies in a single directory. Would you use multiple calls to handle the multiple directory issue?

Thanks again,
Nat
answered by (840 points)
0 votes
You'd replace the call to NUnit with the call to MSTest. Leave the NCover call alone - you need that to generate your coverage report.

You can use CreateItem with semicolon-delimited lists to include multiple things.

<CreateItem>
<Output>
</CreateItem>
answered by (6.7k points)
0 votes
The forum appears to have eaten my CreateItem snippet. I'll write it again, but use square brackets instead of angle brackets.

[CreateItem Include="Path1\*.Test.dll;Path2\*.Test.dll;Path3\*.Test.dll"]
[Output TaskParameter="Include" ItemName="UnitTestAssemblies"/]
[/CreateItem]
answered by (6.7k points)
...