views:

241

answers:

3

I am having trouble getting NCover to properly cover a .dll. I have several test projects that use XUnit.NET and SubSpec to execute BDD-style specifications. All but one of these test suites runs perfectly in the version of NCover that comes with TestDriven.NET (1.5.8). However, I have one that refused to profile the actual tested assembly. I have verified that the assembly names for the /a option are correct, that the .pdb file exists, and that there are no exceptions being thrown during execution. All of the 8 tests pass, which can be seen when the NCover console app is executed.

The assembly references the WPF assemblies PresentationCore, PresentationFramework and WindowsBase. I am not sure if that might be causing problems, but I am completely baffled by NCover's refusal to profile this assembly.

Command line:

"C:\Program Files (x86)\TestDriven.NET 2.0\NCover\1.5.8\NCover.Console.exe" //reg //w "E:\Campus.Core\Specs.Campus.Windows\bin\Debug" //a Campus.Windows "E:\Campus.Core\ThirdParty\xUnit.NET\v1.5\xunit.console.x86.exe" Specs.Campus.Windows.dll /html Specs.Campus.Windows.html

NOTE:

Problem seems to have solved itself! I don't know what changed, but the assembly is now being covered properly, and its at 100% coverage! Thanks for those of you who threw in some input. I appreciate it!

+1  A: 

I am not sure how v1.5.8 works but are you sure the dll is loaded into memory?

Are you sure the pdb matches the dll? Every once in awhile, the dll is not in sync with the pdb. Was it built on the same machine?

What is the name of the assembly? Look in the app.config file and see if there are system exclusions.

If you are using NCover 3, feel free to contact support, they will help you out.

Thanks

Joe Feser

joe.feser
It is all being built and run on the same physical machine. I have done clean/rebuild, manually deleted all the files and rebuilt, etc. The .pdb definitely matches the .dll. The name of the assembly is Campus.Windows, a utility library that provides some WPF support types. It is very small and very simple. I am not using NCover 3. I tried it out, but it was hideously slow and the UI glitched and crashed a lot. I don't know exactly what they were trying to accomplish with v3, but despite its reporting enhancements, it feels like a step back from 1.5. :(
jrista
What version of NCover 3 was crashing a lot? Were you using the beta builds back in Nov-Jan? NCover 3 is 2-3x faster than NCover v1.5.8 in execution time.
joe.feser
+1  A: 

ncover 1.5.8 has a list of auto-excluded assemblies in its app.config file. perhaps one of those is excluding your assembly?

Stephen Ward
A: 

Problem seems to have solved itself! I don't know what changed, but the assembly is now being covered properly, and its at 100% coverage! Thanks for those of you who threw in some input. I appreciate it!

jrista