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 FilesTypemockIsolator.0TMockRunner.exe" -first -link NCover3.0 "C:Program FilesNCover
cover.console.exe" "C:Program FilesMicrosoft Visual Studio 10.0Common7IDEMSTest.exe" /testcontainer:C:_SourceLibraries_UnitTestsCommonApp.UnitTestsinDebugCommonApp.UnitTests.dll //h "\remotemachineDataCoverageReportsCommonApp" //at "C:datacoverageCommonApp	rends.trend" //x "C:datacoverageCommonAppcoverage.xml" //l "C:datacoverageCommonAppcoverage.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 ( doesn't seem to persist this linkage from execution to execution....).

Any help you can offer would be greatly appreciated!

- Nat
asked by nrusso (840 points)

12 Answers

0 votes
Thanks again! I think I'm getting closer now.

I'm getting an error now that reads "NCover can't read the given settings file. Is it a valid NCover 3 settings file?"

A little more info: I've saved the modified version of the build script in your blog as "CodeCoverageBuildScript.xml". I'm invoking the entire process from a Visual Studio command prompt with a simple "msbuild CodeCoverageBuildScript.xml" (which appears to begin the process).

Now I did notice that for some strange reason it appears to be looking in the users directory, under my profile, in the temp directory, for a file called tmp538.tmp.ncoversettings", which does not appear to exist. But I don't see where, in the script, it calls for this settings file, so I'm not sure where to change the call.

In fact, strangely enough, I searched my entire hard drive for ANY *.ncoversettings file and found none. So I'm sure I missed a step somewhere along the way.
answered by nrusso (840 points)
0 votes
Unfortunately, that sounds like something you may need to contact NCover support about. I've not seen that message. It may be a misconfiguration in the NCover installation.

In GENERAL, my troubleshooting for things like this is to get small bits working one at a time.

First, get the script running some very simple MSTest tests that don't need mocking or anything, just to get the command line for MSTest down right. These shouldn't be your real tests, just some very simple known good tests. This is so you can isolate the script from any issues with test setup that may be going on.

Next, add NCover to the mix. See if you can get those simple MSTest tests running without mocking but with coverage.

Once you have that, add Typemock in and run some simple (not your real tests) MSTest tests that use mocking. Verify you can get coverage still.

The last step is to actually run your real tests in that full stack.

The reason I recommend doing it this way is that if, in adding another layer to the script you start running into these weird issues, you know what part of the stack works and what part doesn't. That way you know what to start looking at and which resources might be best able to aid you in the effort. I, personally, have a heck of a time figuring things out if I don't know what part is actually working correctly and what part's not. :)
answered by tillig (6.7k points)