1.5.8 Fails with Index Out of Range

I'm still using NCover 1.5.8 with NCoverExplorer 1.4.7, which, until yesterday, worked flawlessly for my project.

Since today, it always breaks down with an IndexOutOfRangeException at NCover.Framework.CoverageData.MergeModule(ModuleData leftSide, ModuleData rightSide).

The strange thing is, I didn't change anything in the code and even after reverting to an older state of my project, the exception still happens.

I tried it with the NCover 3.1.4 trial and it works flawlessly there. I'd gladly donate some money, but completely switching to NCover 3 is not an option for me because I want to keep my development tools free (easier to add people to the team) and because I like the old NCoverExplorer better (looks nicer & is more responsive)

RE: 1.5.8 Fails with Index Out of Range

Oh, and the question was, has anyone experienced this before or can pinpoint the what causes this exception?

I've got about 15 projects in the NUnit project that I run through NCover, so the method its failing in (NCover.Framework.CoverageData.MergeModule()) suggests that one possible workaround would be to only test a single assembly at a time, which is rather inconvenient.

RE: 1.5.8 Fails with Index Out of Range

I debugged NCover 1.5.8 using the Deblector Addin for Reflector.

The NCover.Framework.CoverageData.MergeModule() method fails directly in or after it has merged msvcm80.dll (the Visual C++ 2005 Runtime).

I'm not sure if it's that assembly or the one after it, but the Visual C++ 2005 runtime is one thing might have changed between yesterday and today. There was a lengthy Windows Update that did something to Visual C++ 2005, including the file NCover now likely is failing at:

http://support.microsoft.com/?kbid=971090

RE: 1.5.8 Fails with Index Out of Range

we tracked down this bug sometime in the NCover 2 timeframe. As I recall, the problem was usually caused when 2 different versions of the 'same' assembly were loaded into the covered process. Typically, one version had fewer classes/methods than the other version, and the problem would happen when the shorter module was passed in on the LHS. Unfortunately I don't remember the specifics of the bug, but it was fixed about a year ago, and the definition of 'same' assembly changed somewhere within that same timeframe, although I don't remember whether it was before or after this fix.

Anyway, running one test assembly at a time will at least help you isolate the problem, but the VC++ runtime shouldn't be affecting the bug since it's unmanaged code.