Is the .Net 2.0 dependence on NCover v1.5.x only or also on

Hi there,

My application being tested is built on .Net 1.1. Is the .Net 2.0 dependence on NCover v1.5.x only or also on the application being tested?

Thanks,

Erica

Re: Is the .Net 2.0 dependence on NCover v1.5.x only or also on

.Net 1.5.x requires .Net 2.0 present so it can run, however the intent is that it can profile all of 1.0/1.1 and 2.0 applications.

However as you may see from the blog/posts there is a bug in the NCover 1.5.5 release which means it will not profile 1.0/1.1 applications.

So your best bet is to either use NCover 1.3.3 or NCover 1.5.4 to profile your 1.1 application (at least until NCover 1.5.6 is released).

Re: Strange NCover results

I think my assumptions about the way that Generic classes are loaded was incorrect in this instance. I'm working on a solution.

Re: Strange NCover results

In my experience, it looks like members of a generic class that do not use the generic type do not get covered. It appears that a method has to either take the generic type as a parameter or return it to get coverage information. Is this the same bug you are working on?

At any rate thanks for the excellent tool.

John Melville

Re: Merge output files

Hi,

I use the current NCoverExplorer 1.3.2.1546 for this task. You can find it on http://www.kiwidude.com/blog/

ThomasD

Re: Index out of range

Just tested this with NCoverExplorer 1.3.5.1921 (that comes with TestDriven.NET RTM) and the good news is that it parses/merges the files without the above error.

The bad news is that the coverage numbers are much lower that previously (NCover 1.5.4). Looking into this deeper shows duplicate methods (like 1.5.5, 1.5.6 produced). Same issues as before, showing 100% coverage on the first reported, and 0% coverage on the second reported (which includes the additional line number for the first '{').

I guess this makes sense since the method signatures are still not unique in 1.5.7, so it has the same issues as the previous versions. Bummer...

Re: Index out of range

Interesting, if I use version 1.3.5.1921 to perform the merge (since the other fails), and the load the merged file into 1.3.6.12 to generate the report, the coverage percentages look very close to the 1.5.4 version, and the duplicate methods go away!!!

Must be some "enhanced" logic in the merge algorithm in 1.3.6.12 to deal with the "different line numbers per method" anomaly.

Now to see if I can work in two different versions of NCoverExplorer into the automated build. Maybe I'll hold off to see if this is a trival fix. Let me know if I can help out.

Re: Index out of range

Hi Mitch,

I've made a lot of changes to the merging logic in recent 1.3.6 versions to attempt to fix a range of issues with various NCover versions. The issue is not just identifying the methods uniquely - it is removing the noop sequence points from code that has partially been executed as well that various NCover versions profile differently.

I am obviously very keen to get this resolved asap - I thought I had nailed this problem already but obviously not. Any chance you could zip and send me your coverage.xml files? I promise they will be deleted immediately afterwards and treated completely confidentially. Do a find/replace on the namespaces or chop them down in some way if you like - so long as the problem still appears. It is obviously some corner-case that I am not handling properly that would be trivial to resolve with your files. My e-mail address is support at ncoverexplorer dot org.

Also, I take it that if you drag/drop those coverage files into the NCoverExplorer gui, do you see exactly the same error popup? If not, can you also send me the extract from your build script so I can see how you are calling NCoverExplorer?

Thanks for reporting this - I have been running this build myself without any issues on our build server at work across half a dozen projects without a problem. So hopefully not everyone is going to be stuck as you have been. I pushed this build up because the coverage results had become truly meaningless as you saw with previous merging code. I hadn't announced 1.3.6 officially as yet because I was planning to give it more of a thrash this weekend. I will make sure that 1.3.5 is also available on my downloads page for anyone who wants to revert.

If you cannot send the files, I have just pushed up a 1.3.6.13 build replacing the existing one on my site that if you run up sysinternals DebugView should allow you to see where the parsing gets to when it experiences an error. If you can reduce the coverage files to containing just that method in it and still get the error then I'm sure I can fix it very quickly.

Re: Index out of range

Here is the output from 1.3.6.13 (debugview):

[5912] NCoverExplorer Exception: Index was out of range. Must be non-negative and less than the size of the collection.
[5912] Parameter name: index
[5912] File: E:\NCoverExplorer-1.3.6\Framework.Core.Coverage.xml
[5912] Line: 2342
[5912] Last known module: E3.Framework.Core
[5912] Last known method: get_Context

Also, not important, but if you send in an invalid list (*xxxcoverge.xml), you get an Index error:
Index was outside the bounds of the array.

Re: Index out of range

Mitch,

I've just pushed up build 1.3.6.14 which should address this issue. Let me know how you get on.

Re: Index out of range

Thanks for the wicked fast turn around time on this issue. As far as I can tell the new build has resolved the, "Index was out of range. Must be non-negative and less than the size of the collection. Parameter name: index," issue I was experiencing when merging my reports.

Kudos to both of you for working it out...

Thanks,
Tom

Re: Index out of range

Hi Tom,

Thanks very much for your valuable feedback on this being fixed for you too. Looks like its showtime for an official NCoverExplorer 1.3.6 release now.

The problem only occured if you merged methods in multiple files in a certain order with a combination of instrumented/non-instrumented code. I tried to get clever near the end of my release cycle with some "optimisations" for reading NCover 1.5.7 files (which contain extra attributes like whether a method was instrumented) - but obviously I screwed up along the way.

Thankfully Mitch was able to send some files to me which made it a doddle to track down and fix. Apologies to all who suffered in the interim build... hopefully the longer term benefits of better coverage result consistency are worth the pain I caused.

Re: Index out of range

Mitch wrote:

Also, not important, but if you send in an invalid list (*xxxcoverge.xml), you get an Index error:
Index was outside the bounds of the array.

Sorry, missed this one earlier. 1.3.6.15 just pushed up now has this fix too.

Re: Index out of range

Just got a chance to give it a run. Awesome job and thanks for the lightning fast turn around. I ran it with quite a few extra coverage files and looks much better. Haven't seen any duplicate methods or anything!!!

Your comment on "causing people pain" is quite funny. The only pain that I remember is when we were writing the merge algorithm. Now that we have the pleasure of using your awesome and superior tool, all the pain has gone away.

Cheers...

Re: Wild Cards: Exclude Class Window*

Nigel,

I think the class name exclusions need to include the namespace. So you would have to change it to something like "*.Window*". If that causes a problem (like you having a namespace with Window in it) then you could get more specific, like "Microsoft.Practices.CompositeUI.WinForms.Window*"