"Unable to read beyond the end of the stream" error
"Unable to read beyond the end of the stream" error
We had been using NCover (with NUnit) in one pass to test 4 or 5 assemblies for quite awhile. The command was something like this:
NCover.Console nunit-console Assm1.dll Assm2.dll Assm3.dll Assm4.dll Assm5.dll
Some of these assemblies are using AppDomains and testing dynamic plugin loading. So, we are seeing the same modules loaded/unloaded many, many times in the outputed xml report. It was getting to be such a problem that we had to write our own program to merge the 120MB Coverage.xml file into an equivalent 1.4MB file. (Now it appears that NCoverExplorer will do this merge functionality as well.)
As more tests were being added, the XML file is now getting up in the 200MB range and causing the following error:
Unable to read beyond the end of the streamAs a workaround, we broke up the command to only process 1 assembly at a time. This worked for awhile, however now we are seeing the same error on just 1 assembly (has about 500 unit tests). So, the only option left for us is to get the NCover.Console.exe code fixed. From looking at the code and the design, I would guess that the named pipe that is used to transfer the data from the C++ side to the C# side is getting too full and causing the error.
Not knowing the details of the profiling API, maybe a solution would be to hold the map of the modules in memory until the completion of the run (so that each module is only outputed once, rather than multiple times). Another solution may be to have the C++ side just write the XML data (rather than passing it to the C# side via named pipes).
Anyways, I don't know if there is a quick fix that could be made for the next release (1.5.5)? If there is anyway that we can help, just say the word. I would be glad to look at the C++ code if necessary. Can't wait to get the next release, as we are suffering from low coverage percentages on some of our generics code.
We absolutely love the tool (especially with the addition of NCover.Explorer and TestDriven.NET), and would like to help out anyway that we could.
Thanks,
Mitch
Re: Code Coverage on service ...
Gada,
I've never run code coverage against a service (nor against a web application as someone else posted here recently) so I can't comment on the specifics of your error.
However what I would say is that unless you are trying to do code coverage during system/integration testing then you would be far better off avoiding trying to run as a service at all.
If you structure your application such that the service itself is a trivially thin wrapper delegating to other assemblies that implement your functionality, then you can apply conventional unit testing techniques against those assemblies which NCover usually manages quite well.
That will then just leave your thin service executable itself as the only thing not being tested for coverage. However as it should be so trivial an implementation that should not cause concern.
The same principles apply for trying to test web applications for coverage. Personally I wouldn't bother with all the fudges and workarounds in either scenario - push as much of the logic as possible into unit testable assemblies and apply coverage to those.
Just my opinions but I suggest it's a more solid long term strategy if you have the opportunity to take that approach. Someone else may have some specific experiences of profiling services with NCover and avoiding the error you received of course as the alternative.
Re: Code Coverage on service ...
Grant:
Thanks for the suggestions and I agree that we should only NCover the service during the integration test.
I was able to solve the issue by using the following command
NCover.Console.exe //svc "NetIQ Security Manager" /noservice