None, I'm afraid the name clash is rather unfortunate - I googled but did not find the other ncover so assumed it was a 'safe' name.
However the differences are quite striking:
our ncover is c# code not c++.
our ncover does not use the profiling api (which slows processes down) and doesn't need arcane environment variables set up.
our ncover doesn't restrict you to running one instance per machine.
Oh, and our ncover is designed from the ground up to easily slot into your continuous integration build cycle.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Also looking at the date there site was put on GotDotNet (9 Jan 04) and the date our NCover on source forge was created (22 Dec 03), I guess it's no supprise that I didn't find it on the web because it wasn't there and (dare I say it) we got there first?
Let the battle of the ncovers begin...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't think anyone is trying to start a battle here. :-) There is certainly room in the world for more than one .NET code coverage tool (even better that they use two different approaches).
I did not know there was an ncover workspace on source forge until Craig notified me. Not that it matters much anyway. Looking at the project history, there was nothing posted on this sourceforge site until after my stuff went up on gotdotnet. Competition is good for the community!
Just a quick response to the differences noted in a previous post.
1) Yes, our profiler is written in C++. It interfaces with the COM Profiler API. It also supports profiling any .NET language that emits debug information (C#, VB, even IL).
2) The profiling API, as we use it, does not significantly slow down the program execution because we don't hook function calls. I'd love to see a benchmark comparison.
3) No environment variables are required to set up our NCover. NCover is a command-line application that runs the profiled process as a sub-process and takes care of all the profiler setup details for you in the background.
4) There is no limitation as to the number of instances of NCover that can be running on one machine. I'm not sure where this idea came from.
5) Our NCover integrates very well into a continuous build process. In fact, that is why we built it. Our build processes use NCover inside Nant to generate build statistics all the time. There is also a plug-in available for running it from within the Visual Studio IDE.
6) Our NCover does not require a special compilation step. It is designed to run on shipping code (as long as build symbols are available)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What's the relationship of this project to the nCover on GotDotNet?
http://www.gotdotnet.com/Community/Workspaces/workspace.aspx?id=3122ee1a-46e7-48a5-857e-aad6739ef6b9
None, I'm afraid the name clash is rather unfortunate - I googled but did not find the other ncover so assumed it was a 'safe' name.
However the differences are quite striking:
our ncover is c# code not c++.
our ncover does not use the profiling api (which slows processes down) and doesn't need arcane environment variables set up.
our ncover doesn't restrict you to running one instance per machine.
Oh, and our ncover is designed from the ground up to easily slot into your continuous integration build cycle.
Also looking at the date there site was put on GotDotNet (9 Jan 04) and the date our NCover on source forge was created (22 Dec 03), I guess it's no supprise that I didn't find it on the web because it wasn't there and (dare I say it) we got there first?
Let the battle of the ncovers begin...
I don't think anyone is trying to start a battle here. :-) There is certainly room in the world for more than one .NET code coverage tool (even better that they use two different approaches).
I did not know there was an ncover workspace on source forge until Craig notified me. Not that it matters much anyway. Looking at the project history, there was nothing posted on this sourceforge site until after my stuff went up on gotdotnet. Competition is good for the community!
Just a quick response to the differences noted in a previous post.
1) Yes, our profiler is written in C++. It interfaces with the COM Profiler API. It also supports profiling any .NET language that emits debug information (C#, VB, even IL).
2) The profiling API, as we use it, does not significantly slow down the program execution because we don't hook function calls. I'd love to see a benchmark comparison.
3) No environment variables are required to set up our NCover. NCover is a command-line application that runs the profiled process as a sub-process and takes care of all the profiler setup details for you in the background.
4) There is no limitation as to the number of instances of NCover that can be running on one machine. I'm not sure where this idea came from.
5) Our NCover integrates very well into a continuous build process. In fact, that is why we built it. Our build processes use NCover inside Nant to generate build statistics all the time. There is also a plug-in available for running it from within the Visual Studio IDE.
6) Our NCover does not require a special compilation step. It is designed to run on shipping code (as long as build symbols are available)