Filtering coverage

I think I already know the answer, but I thought I'd ask anyway. When running tracking coverage from testdriven.net, a significant portion of the uncovered code sits in catch blocks. Many times, the catch block is doing nothing but adding a small amount of context information to the exception stack and throwing up. I'm sure there are cases where you might want this covered in tests, but generally since these conditions are, well exceptional, they aren't tested and shouldn't be covered. Make sense?

I don't see any way to filter out those sorts of things with NCover, is that true? Any chance it ever would be true?

Thanks for all you have done so far, it's already helpful.

Re: Can I use NCover on a .net dll if my UI is VB6?

Are you saying the executable you are launching is VB6 which invokes some .NET dlls? The entry point executable being profiled by NCover must be .NET managed code I believe.

Re: Can I use NCover on a .net dll if my UI is VB6?

Yes the executable I am launching is vb6 which invokes .NET dlls.

If the entry point exe must be .net managed code is there a way of tricking it? Since it seems to write out the Coverage.log file it seems like stuff is being recorded. Is there a way to manually run the profiler against this file?

What about if I were to write a .NET exe that NCover launches and this .net exe starts the VB6 exe. Would that work?

If none of that works is there a product that you know of that will work for what we are trying to do?

Thanks

Randy

Re: Can I use NCover on a .net dll if my UI is VB6?

I would doubt the .NET exe trick would work. AFAIK NCover profiles a specific process (which must be managed code) - launching a separate process takes you outside of that process domain so would not report coverage on it.

I'm not aware of any other products out there but you are talking a fairly unique requirement. I would suggest that the majority of NCover users use it in conjunction with unit tests, which will all be managed code. In theory it is possible to use it for integration tests such as profiling a running managed code executable, or a windows service/IIS application. The latter two options are currently "broken" however in the latest NCover builds available as you will see mentioned on other threads. I believe Peter is getting this all sorted for the next NCover release.

The only other option NCover offers is the //pm for monitoring a process that is not the one being launched. This was intended for the likes of using MSTest. This won't help you though as your .NET code is managed dlls and not a standalone process executable.

Sounds like you need to pull finger on the project plan and replace that VB6 executable with managed code to me...