Bumping an old request - enhanced coverage.xml file

Hi Peter,

Since the old forums appear to be locked I will start a new thread here with a link to my previous request.

The timestamp of when the coverage report was produced is the "critical" thing I would love to have as this helps everyone trying to do any reporting of the results. Obviously I could try to incorporate that into the NCoverExplorer UI as well.

Have you had any thoughts as to other things you may or may not change in the schema? For instance more detail to help identify overloaded methods/constructors in the method name? Would love to hear of anything that you are thinking of doing just to make sure I keep NCoverExplorer in sync.

Regards,
Grant.

Re: Bumping an old request - enhanced coverage.xml file

I just added an excluded="true/false" attribute to track excluded sections. Other than that, I have a ton of work to do on the output side. I've been working on the core engine mostly lately. I plan to completely redo the way that the output is generated. However, I do plan to continue to support the old format so that tools like yours will still function.

Re: Bumping an old request - enhanced coverage.xml file

Here is a brainstorm list of items I'd like to return in the coverage report.

Date and Time of run
Syntax highlighted copy of covered code
Execution performance statistics
Different types of coverage

Sequence Point / Statement Coverage
Branch Coverage
Maybe others

Re: Bumping an old request - enhanced coverage.xml file

I've just released the latest NCoverExplorer version 1.3.2 which will properly handle this "excluded" attribute if it is present in the coverage file. Some great sounding features on your todo list - obviously I'm interested in adding support for them from an NCoverExplorer perspective as well where it makes sense.

You may want to consider some sort of "version" attribute in the coverage xml file if you start fiddling with the schema more to make it easier for those of us downstream to support the different NCover versions.

Regards,
Grant.

Re: Bumping an old request - enhanced coverage.xml file

Just a thought:

Perhaps NCover and NCover explorer can be merged one day into a single project?

Then surely these things would be more efficinet?

I like both tools, and think that they work very well as a pair.

Before the explorer came along, I was having a hard time digging through XML output (very slow for 10,000 line DLLs).

On the other hand, maybe you guys like the layering better.

Trev

Re: Bumping an old request - enhanced coverage.xml file

I'm open to the idea. I just haven't had much time to think about it lately.

Re: registry access error after instrumented process exits

I'm having the same issue.

I've run NCover with REGMON.EXE from SysInternals. After about a one minute delay NCover exists with the message "Requested registry access is not allowed.".

Below the entry in RegMon:
NCover.Console. OpenKey HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment ACCESS DENIED Access: 0x2001F

This hive contains all the environment variables.

Don't know what 0x2001F is. It probably want write access.

Re: registry access error after instrumented process exits

When run with administrator privileges the following not existing keys get deleted:

46.28390121    NCover.Console.:7852    DeleteValueKey    HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\Cor_Enable_Profiling    NOT FOUND
46.28393936    NCover.Console.:7852    DeleteValueKey    HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\Cor_Profiler    NOT FOUND
46.28396988    NCover.Console.:7852    DeleteValueKey    HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\NCover_PID    NOT FOUND

So... only try to delete when they exist will make this error be gone or remove the code because they aren't created at the start.

Re: registry access error after instrumented process exits

Good catch. I know what the problem is there. I'll fix it right away.

Re: registry access error after instrumented process exits

Still happening for me in the 1.5.1 beta 2 download. Let me know when it's in a release and I'll retest.

Thanks!

Re: registry access error after instrumented process exits

I didn't have a chance to fix it yet, I'll let you know.

Re: registry access error after instrumented process exits

This is fixed in the 1.5.2 release.

Re: registry access error after instrumented process exits

I don't get the registry error any more, but when not running as Administrator (but in the VS Developers, Deb ugger Users, and Power Users groups), the app doesn't connect to NCover.

I tested by opening a command prompt as admin and one as the non-admin user mentioned above. With identical commandlines, I ran

C:\Program Files\NUnit 2.2.6\bin>ncover.console nunit-console nunit.framework.tests.dll //a nunit.framework.dll

The admin user's finishes and generates good coverage output. The non-admin user halts at the end and eventually times out, saying "Profiled process terminated. Profiler connection not established."

This is on XP SP2 with both .NET 1.1 and .NET 2.0 installed. The NUnit 2.2.6 I am testing with was compiled against MS.NET 1.1.

Any help is greatly appreciated,
Thanks!

Re: registry access error after instrumented process exits

Actually, I can no longer reproduce this... must've been that bong of fruit loops I didn't inhale...

Re: Nant exec task error

The only thing I can see which may be "wrong" is that the path to your NUnit executable has a space in it. This means that NCover will probably not be able to find NUnit.

Also, you are using the "old" NCover syntax. If you want to try using the new beta version then something like this should work for you:

        <exec program="${ncover.executable}" verbose="true" timeout="600000">
            <arg value="//x" />
            <arg file="SchedulerInterfaces-Coverage.xml" />
            <arg value="//a" />
            <arg value="SomeAssembly;SomeAssemblyTest" />
            <arg file="${nunit.executable}" />
            <arg value="SomeAssemblyTest\bin\Debug\SomeAssemblyTest.dll" />
            <arg value="/xml=SchedulerInterfaces-Results.xml" />
        </exec>

Hope this helps,
Regards,
Richard

Re: Expose number of sequence points that were excluded

Hi Borys - you are talking about the bit at the bottom of the reports right? Yeah it is related to the other issue but is indeed on top of that, I'll add it to the list to look at as well.

Re: Can't run with several nunit test assemblies

Hi Romu,

Let me check it out tonight. It could be I have busted something in the latest changes but if so it should be fairly trivial to fix. If that's the case I will put a new build up tonight - sorry for the delay.

Re: Can't run with several nunit test assemblies

Romu,

It was indeed a bug - thanks for finding this for me. It was a last minute change I made from something I thought I spotted in the NCover 1.5.5 .settings files (it surrounded the command line args with quotes). Unfortunately this broke all the earlier NCover 1.5.x versions as you found out. I have removed the change I made and it seems to run ok for me now against all NCover versions.

Let me know if you have any more problems. You can download build 1.3.5.1797 from here:
http://www.kiwidude.com/dotnet/NCoverExplorer-1.3.5b.zip
http://www.kiwidude.com/dotnet/NCoverExplorer.Extras-1.3.5b.zip

Re: Can't run with several nunit test assemblies

Thanks a lot, what a quick fix !!

I confirm, NCover works now as expected.

Thanks again for your quickness.

Re: NCoverexplorer task

Hi Kordzik,

There doesn't look anything too wrong with the nant script you posted. The one change I made was that since my NAnt script and coverage files were not in the same folder as NCoverExplorer I specified a path to NCoverExplorer.

I suspect the problem is something to do with working directories? Where exactly do you have NCoverExplorer.Console in relation to the NAnt script?

Re: NCoverexplorer task

Second guessing your answer here, but are you relying on NCoverExplorer.Console.exe being in your path?

I think that what is happening is the NAnt task is creating the NAnt.NCoverExplorer.config file in whatever the "local" directory is at the time, which I guess will be your NAnt script folder. I suspect after running the script you will have a nant.ncoverexplorer.config file hanging around in that directory.

Then NCoverExplorer.Console is being launched, and as it is not being passed a fully qualified path to the .config file just created it is looking in the wrong folder for it.

I will make a change tonight to the NAnt/MSBuild tasks so it does pass a fully qualified path (and create it in a temp folder rather than where it does currently). In the meantime, what you should be able to do is set the "workingDirectory" attribute of the NAnt task. Alternatively a fully qualified path to ncoverexplorer.console.exe seemed to work for me above.

If I'm on the wrong track let me know (and let me know which workaround worked for you too).

Re: NCoverexplorer task

I've just pushed a new build up of the NAnt/MSBuild tasks which now write to the temp folder and pass the full path through to NCoverExplorer.Console. You can find the download links on my blog. Let me know if this does not resolve your issue.

Re: NCoverexplorer task

Hi Kiwidude,

sorry I didn't answer before, I was quite busy last days...

Exactly as you supposed, it was the case of having Ncoverexplorer on the Windows PATH and not passing absolute paths as arguments... I have just now seen your feedback (as I said, I wasn't able before) and tried the new version of tasks and, of course, it works perfectly:)

The speed of your feedback is really impressive! Keep it going!

Regards,

Kordzik