Empty Output file when using assembly list from variable!

Empty Output file when using assembly list from variable!

I am using NCover 1.4.6 (Can't switch a couple of dozens of developpers to .Net 2.0 in mid-project).
I am trying to get the coverage results for a list of assemblies defined in a variable (Nant build script).

The following works perfectly:

        <exec
        program="${NCover_path}\NCover.Console.exe"
        commandline='/c "${NAnt_path}nant.exe" "unittest" /l "${Common.builddir}\${comp.name}.ncover.log" /o "${Common.builddir}\${comp.name}.ncover-report.xml" /a "ASM1;ASM2;ASM3"'
        failonerror="false"
        verbose="true" />


Wheresas the following gives a miserably empty output file:

    <property name="assembly.list" value="ASM1;ASM2;ASM3" />
        <exec
        program="${NCover_path}\NCover.Console.exe"
        commandline='/c "${NAnt_path}nant.exe" "unittest" /l "${MSLite.Common.builddir}\${comp.name}.ncover.log" /o "${MSLite.Common.builddir}\${comp.name}.ncover-report.xml" /a "${assembly.list}"'
        failonerror="false"
        verbose="true" />

I don't want to use the literal assembly list as a parameter since the assemblies to profile vary with each build.

Any help is highly appreciated.
Thanks,

Zak

---

Re: Coverage.xml is empty even after copying the pdb files

A few things - firstly what OS/versions of NCover/NCoverExplorer/.NET are you running. Are you profiling running unit tests via nunit or just a standalone exe?

When you say you are using NCoverExplorer do you mean you are using the "Run NCover" option? Try the generate command line option on that dialog, then run that from a command prompt so you can examine the console output. If you are using NCover 1.5.7 you should add the //reg argument to the ncover command line (my latest build does this automatically but can't remember if that is on my download page yet). Otherwise you will likely need to register coverlib.dll manually.

Is there any indication of a failure from the command line of whatever your application is not starting or running as expected?

Other reasons off the top of my head why it can go wrong:

• Assemblies installed into the GAC (NCover cannot locate the pdbs).
• No application .pdbs being present obviously but sounds like you covered that.
• Are you by chance specifying a list of assemblies to profile (the //a argument) - if so then getting this wrong will give you no output as well. See the latest NCover FAQ for details on this.

You could also look at the coverage.log being generated by NCover. If it isn't horrendously large post the content on here - if it is you could zip and send it to me via e-mail and I will take a look tonight (send your command line and any other output/details you have as well).

---

Re: Coverage.xml is empty even after copying the pdb files

Thanks a lot for your reply. Find below my answers to your questions.

 

---

Re: Coverage.xml is empty even after copying the pdb files

Hi,

I e-mailed the coverage.xml to grant_drake@hotmail.com. Can you please have a look at the files and let me know where am I going wrong?

---

Re: Coverage.xml is empty even after copying the pdb files

For anyone reading the thread and wondering - I have replied to Srinu by e-mail.

The cause of the problem is that the assemblies were compiled on one machine and then profiled on another. Due to the default behaviour of nunit to shadow copy assemblies, it seems when the pdb files were compiled on a different machine .NET decides not to copy the pdb files to the shadow cache location. Anyone know why this is???

Without any pdb files present in the folder where the assemblies are executing from, NCover quite rightly assumes they are not intended to be profiled - hence the empty coverage file.

The workaround is to use nunit-console with the /noshadow argument (or do your profiling on the same machine as the assemblies were built on). NCover is then able to find the .pdbs and a coverage file is produced.

I have asked the question on the nunit forums here as to whether anyone knows why the shadow cache has this limitation. Is it some sort of security mechanism, something to do with strong naming (in my tests they were not), machine.config setting or ???

---