Definition of attributes used to exclude classes, etc... in

Hi,

how about defining the attributes used to exclude classes, methods, etc... in a configuration file for NCover? This would help to use exclusion attributes with enable external applications using NCover.

Regards,
Mark

Re: Definition of attributes used to exclude classes, etc... in

You can start NCover with a settings file instead of putting the settings on the command line. I believe this file supports the exclusion attributes as well.

Re: Coverage for No-Op lines

"End Try" is another one.

Re: Coverage for No-Op lines

This is on my list to fix.

Re: Coverage for No-Op lines

Good to see that I'm not the only one having this problem.

Regards,
Mark

Re: NCover Release - version 1.5.1 beta 2 - Registry Keys

Those keys are there for reference only. They are not needed.

Re: Add not executed methods and namespaces

Hi Thomas,

My first instinct of the response if I understand your query correctly was using Reflection to generate "supplemental" coverage.xml information doesn't sound the right thing for NCoverExplorer to be doing.

I appreciate your frustration though and it's a relatively easy cop out on my part to say that the problem should be fixed in NCover instead. That certain methods don't appear in the coverage even though their assembly was loaded during the coverage run just sounds "wrong" and surely a bug in NCover.

However for assemblies that dont get loaded/executed during the coverage run, and hence don't appear in the coverage - now that's a more tricky one I hadn't thought much about. I guess its possible (particularly with legacy codebases) that a project will be in such a situation.

For that particular scenario it sounds nice in theory that "some" tool could parse the .dll and produce a bunch of statistics on the contents, even though no actual code is executing against it.

The practicalities of that though are fairly initimidating without it being done by NCover. Its not simply a case of just reflecting against the dll and listing out all the types in the coverage.xml format. You also need all the sequence point information - which I'm guessing could only be gained by processing the .pdbs like NCover itself does.

That really does lead back to it being a feature request for NCover...

Of course if you have a bright idea or willingness to knock this part of it up then provided it's done in .Net 1.1 code I will happily integrate it with NCoverExplorer. Alternatively it could be a standalone tool (maybe even using the NCover framework assemblies) which produces a coverage.xml file. Then you can just merge that into the NCoverExplorer results like any other coverage xml file.

Re: Add not executed methods and namespaces

An update on this - this is indeed a bug in NCover which has been addressed for the next NCover 1.5.7 release. The issue was that types that were not loaded in the default AppDomain were never added to the profile output.

Re: assembly names should be case insensitive

Are you using the NCoverExplorer task or <exec> to run NCoverExplorer.Console? If the task, which version are you using? Exactly which build number of NCoverExplorer?

I will take a look at this tonight to check what's going on. It should be a case insensitive comparison with the latest builds of NCoverExplorer but could be I've missed a spot.

Re: assembly names should be case insensitive

Hi Grant,

I'm using NCoverExplorer task from the NCoverExplorer.Extras version 1.3.5.1761

Thanks,
M

Re: assembly names should be case insensitive

Hi mate,

Sorry I was at work and didn't read your message closely enough (confusing myself with a statement about case insensitive exclusions on assemblies for the NCover NAnt/MSBuild tasks).

The assembly exclusions have always been case sensitive - however I agree that they should be insensitive and have made the change. You can get this in NCoverExplorer v1.3.5.1808 or higher from this thread when I push it up later tonight:
http://ncover.org/SITE/forums/574/ShowThread.aspx

Re: assembly names should be case insensitive

Quick reply as always... Thanks for taking care of it, it does make sense that they be insensitive.
I will wait for the fix.

Re: assembly names should be case insensitive

No problem, thanks for the feedback. I've just pushed the build up now for you. I've got one more thing to resolve in this release (a nasty memory leak that's been around for a while I suspect) before this release goes final unless anything else is reported.

Re: assembly names should be case insensitive

Thanks a lot! it works great :-)

Re: relative paths

Hi Rob,

I will have to debug the code to figure out the "why" but I would suggest turning the relative path in your ncoverexplorer.dir property into an absolute one by doing this which should work:

Re: relative paths

Thanks man. Works for me.