Any news on 1.5.7?
Any news on 1.5.7?
I saw a reply to another post about yield and something, which was supposed to be fixed in 1.5.7, "coming out in a few days", two weeks ago. Any news about this version? And will it fix the problem I asked about a while ago where the finally-block of a try/finally clause in a iterator method wasn't counted as executed in all cases?
Re: Any news on 1.5.7?
It is very close, although of course it is Peter's call on an actual date.
I've been testing the latest builds over the last week or two and it is certainly looking the most solid version of NCover to date imho. There were a few things on Peter's todo list that he sorted this week, and gave me a new build yesterday that I'm testing currently he has called "99% ready". I know he has one edge case he was contemplating tackling but whether he does that or pushes it out as is may depend on his time available.
I know Jamie is planning another TestDriven.Net release tomorrow with the latest NCover and NCoverExplorer builds in it unless a show-stopper issue comes up.
As for your iterator scenario - can you post an example method showing the problem exactly and I will try it out - or if you have posted this in another thread previously please point me to it.
Re: Any news on 1.5.7?
In case anyone jumps straight to the forums on their links and missed the blog entry - NCover 1.5.7 has now been officially released and is available in the files section. I hope to have an official NCoverExplorer 1.3.6 build available in the next few days - just getting some of the kinks out first.
Re: "Unable to read beyond the end of the stream" error
Thanks for the feedback. I am trying to get a fix for the appdomain loading issue into this next release. I would also like to update the XML format to a more compact form. I might do this in the next release if I can get the time. Actually the old versions of NCover wrote the coverage data from the process directly. There were a bunch of design issues with that approach that caused me to switch to the named pipe approach.
You may be right about running out of memory for the named pipe, but I'm not sure. I've seen that error before when it was caused by a bug in the profiling data protocol. The generics fix might be your answer.
Re: "Unable to read beyond the end of the stream" error
I've also been getting the same "Unable to read beyond the end of the stream" error. This is my setup:
* I've just upgraded NCover from 1.3.3 to 1.5.4 because we are upgrading to .NET 2.0.
* I'm using NCover with NUnit, although my final testing has been done running NCover.Console straight from the command line.
* I've kept the command line arguments the same, apart from the changes required (e.g. //a instead of /a).
* 13 assemblies are listed with the //a argument. If I list all 13 assemblies, I get this error.
* When I've tried only listing some of the assemblies, the XML file is built only if I list up to 8 assemblies. In this case the XML file is just over 6MB.
* I've tried different combintations of assemblies to see if one is the issue, but kept on getting the error message if I listed different assemblies as the ninth and last assembly.
Thanks,
Shandos
Re: "Unable to read beyond the end of the stream" error
I did do some more digging into this. I originally thought that perhaps the size of the data on the named pipe might be causing the error, since a lesser number of assemblies usually fixed the problem. But considering Peter's comment, and the fact that running the same test over and over again will produce some runs that work and some that don't (even though the output size is the same), I believe the problem lies elsewhere.
In all cases, the NUnit tests complete, its the processing of the data in the named pipe on the C# side that causes the error (whether that be because of bad data in the pipe or whatever). I updated the NCover.console.exe code (the ShowException() method) to print out the full exception (rather than just the message). Here is the details from the exception:
System.IO.EndOfStreamException: Unable to read beyond the end of the stream.From looking at the exception and the code, it appears that either the stream ended prematurely, or some garbage data in the stream messed up the logic. I wish I had a small test case that I could send to reproduce the error. If there is any other way to help out (or test a patch), let me know. Would like to help out in any way possible.
at System.IO.__Error.EndOfFile()
at System.IO.BinaryReader.FillBuffer(Int32 numBytes)
at System.IO.BinaryReader.ReadInt32()
at NCover.Framework.SequencePointData.Read(BinaryReader rdr)
at NCover.Framework.MethodData.Read(BinaryReader rdr)
at NCover.Framework.ModuleData.Read(BinaryReader rdr)
at NCover.Framework.CoverageData.Read(BinaryReader rdr)
at NCover.Framework.ProfilerDriver.GetCoverageData()
at NCover.Framework.ProfilerDriver.WaitForExit()
at NCover.ConsoleMain.ConsoleMain.Main(String[] args)
Thanks,
Mitch
Re: "Unable to read beyond the end of the stream" error
I think it is probably garbage data in the stream. I have seen this is a case with generics and I fixed that bug in the upcoming 1.5.5 release. There could be another case that you are seeing.
Re: "Unable to read beyond the end of the stream" error
I have installed NCover 1.5.5 and run it a number of times, both directly from the command line and also within my NAnt scripts. The first two or three times, I didn't get any error and the xml file was correctly produced (about 6MB in size). However, the last two times, I have again received the "Unable to read beyond the end of the stream" error.
I also noticed that the final line in the coverage.log was missing when this error occurred: "MESSAGE: Received driver ready event."
At this stage I'm planning to look at versions prior to 1.5.4, when I have the time, to see if the error occurs with those versions. Previously, I was using 1.3.3, and only upgraded NCover due to upgrading to .NET 2.0.
Re: "Unable to read beyond the end of the stream" error
We have found in the previous version (1.5.4) that running the NCover.Console would sometimes work, but most often not work (giving end of stream errors). We were hoping that the new 1.5.5 vesion would have fixed this (with the generic fixes), but are still receiving the same problems. When it works, it produces a 150MB xml file (which we then run through NCoverExplorer to merge the results down to a 152KB file).
Also, the coverage numbers (as shown by NCoverExplorer ver 1.3.4.1702) have dropped from 80% to 40%. Have tried running through our own custom merge program, and are seeing a lot of output that looks different from the previous NCover 1.5.4 version. Will have to spend more time with this to get more details and see if I can describe what I'm seeing. So far it looks like that when a module is found again in the output coverage.xml file, it has additional methods for a class that were not shown previously (which seems very odd and wasn't the case with NCover 1.5.4).
This may be breaking some assumptions in the merging algorithm. Loading the 150MB Coverage.xml file in the browser (very painful), the assembly under test (that gets repeated about 50 times) has one instance that report about 88%, so would expect the merged total to be greater than 88%.
Would be nice if NCover would only list the modules out once (uniquely identified by their name) and had unique signatures for the method names. This would help the performance greatly and make the merging algorithm much easier. These are easy things to ask for, but may be very difficult technically.
Still a great product. Let us know if there is something else we can do to help out.
Thanks,
Mitch
Re: Console Tool Ouput
I was using NCover 1.5.4 Beta.
I installed NCover v1.3.3 and life is better now.
Neal Walters