Add time and date to the XML output

Please add the time and date to the XML output.

Re: NCover hangs on NUnit tests

I have this same problem. I'm using NCover and NUnit within Visual Build Pro and also on the commandline. In both situations NCover hangs and just sits there after NUnit has completed. Interestingly NCover runs fine using TestDriven.NET from within VS.NET 2003. I'm running version 1.5.4 of NCover. Anyone figure out a fix/workaround for this, besides killing the second process?

Re: NCover hangs on NUnit tests

I have the same problem with NCover 1.5.4. I am using NAnt and MBUnit.

Is this still an outstanding issue for most people?

Roger

Re: NCover hangs on NUnit tests

I'll add that I'm seeing this as well. I'm using MbUnit test exes so NUnit isn't coming into play. Didn't this happen before in the 1.5 beta 1 and it was fixed?

Re: NCover hangs on NUnit tests

I have the same problem. But it seems that it only occurs when I use the //p Parameter. If I omit the parameter NCover runs ok.

Re: NCover hangs on NUnit tests

Same here. Although I assume you mean //q and not //p. When I take that parameter off my command line, it's working correctly again.

Re: NCover hangs on NUnit tests

Same problem here too. When the unit tests spawn a new process (and terminate it), Ncover never returns therefore not producing the coverage report...

Re: NCover hangs on NUnit tests

Any news on this? Anyone found a workaround?

Re: NCover hangs on NUnit tests

I'm seeing the same issue, though not even using nUnit... nCover simply doesn't detect the program aborting. At the very least, there should be a way to get nCover to print partial statistics if we have to ctrl-C it.

Re: NCover hangs on NUnit tests

Is this only a problem when the unit test spawns a new process? Because I'm getting a similar issue where NCover occasionally freezes and I have to kill nunit-console.exe, and the tests don't spawn any processes. NCover prints this:

Waiting for profiled application to connect...
Profiled process terminated. Profiler connection not established.

and then just sits there.

NCover hangs on NUnit tests - Workaround

I've been experiencing the same problem, and have a workaround. I suspected that nunit.console was not closing because of some background thread in my code under test, which was preventing nunit.console from terminating naturally when running under the ncover harness. So, I had a dig around the nunit.console source code, and sure enough, the Main method simply returns. I changed the Main method of nunit.console to explicitly invoke System.Environment.Exit(int) with the exit code, rather than simply return it, and it appears to solve the problem.

I'd be interested to know if anyone else can confirm this workaround, as I've only really tried it out on one machine - our build server. Everyone else in my team uses the nunit gui, so it's not an issue for them.

Chris

Re: NCover hangs on NUnit tests - Workaround

Hi Chris,

Long time no see. How's tricks?

I've just run into this problem myself, and have lost a day to it. Our build server is a dual processor machine so I'd been working on the assumption that the problem was due to a deadlock in our code caused by loading a large chunk of the data in a background thread, however I tried running our NUnit tests both from VS 2005 and using nunit-console and they all work fine until NCover is added into the equation. It took long enough to actually track down the test causing the problem anyway since there were around 50 possible culprits.

Now unfortunately it turns out that the build server is using a binary distribution of NUnit 2.2.8 rather than one that we built from source (although this has never been a problem until now). At present I don't want to change this in case it impacts the project I'm working on, which is under significant time pressure, plus other projects in the company. I might try to get our build manager to try verifying this on our testbed server, so I'll let you know what happens. For now I think we're just going to end up disabling NCover for this project, which is clearly not an ideal solution. The other alternative is to run it only against the subset of tests that we know don't cause it problems.

Anyway as I said, once we've tested this workaround I'll post again.

Thanks,
Bart

Re: NCover hangs on NUnit tests - Workaround

Chris,

I have tried your work around and it doesn't seem to fix the hanging issue I am seeing. I even tried to modify the code to have Main not return anything and rely on System.Environment.Exit to return the value.

What I am seeing is ConsoleUi.Main() returns right away with a status of 0, indicating everything is correct.

Has anyone had any success in finding the solution to this?

Thanks,
Michael

Re: Bug with reading config file

Pavel,

So what is the actual error that you are getting? Can you post what your configuration file looks like?

Re: Bug with reading config file

Hi Grant,

Actually, there is no any error. The problem is that config file we are trying to supply using "/config:" is simply ignored. We are trying to use config file in order to specify assemblies to ignore.

BTW. Maybe you know. What is the status of http://jira.public.thoughtworks.org/browse/CCNET-770?

Thanks,
George

Re: Bug with reading config file

Hi George,

The config route certainly "can" work as it is what the NAnt/MSBuild tasks use that are in the NCoverExplorer.Extras.zip off my website. There is also an example config file in there, an xsd file with the schema plus the source code for my tasks that generates the config file content. I suspect you have a schema compatibility issue with the xml but without seeing your file contents and/or the command line thats just a guess.

Re CCNet-770. Last status I knew of as of six weeks ago was that it was stil parked on a branch awaiting a merge back to main - Owen was planning on getting the CC.Net 1.2 release out of the way first. There is a thread on the ccnet-developers Google newsgroup that you should post to ask about the latest status. I've been too busy with the day job since Christmas to work on it myself or even check for activity.

State of play as far as I am concerned apart from the merge required is that:

- the CCTray side of things was all working ok provided you used the remoting transport
- the http transport was not coded - not major work but so many people had reported performance issues with using the http implementation in CC.Net I wasnt rushing to put it in initially. Perhaps the caching etc they added in 1.2 has fixed that
- there is no web interface for viewing the queues as yet. Dan Piessens is working on a new web UI and code model for CC.Net (see the Bamboo thread in ccnet users newsgroup). He advised me many months ago to wait for that to avoid the rework - like me he has got snowed with the day job so that has slipped although think he is targeting April now.
- finally a number of people have questioned whether it would be possible to try to solve the build dependency problem (B&C depend on A but want B&C to be allowed to build in parallel while still ensuring they dont build when A does). CCNET-770 is totally focused just on the serialised build queue problem/issues which is the more common one- but my implementation would need to be changed if you wanted to solve the dependency problem "properly" too. Whether Owen decides to do something about that or just rolls it out as is, is up to him of course.
- Owen was also using this change as an opportunity to refactor some things about the current CC.Net design. So depending on how far he wanted to continue with that would also have an impact on delivering this branch.

Rambled a bit sorry but thats what I know - obviously I would love for it to be finished off to see the light of day in the main build but it needs some resource to do so which I at least can't offer at the moment...

Re: Bug with reading config file

@George: I think I am seeing a similar problem to this: http://ncover.org/SITE/forums/thread/1377.aspx (or maybe not...?)

Cheers,

Jon

Re: Framework 3.0 WCF Services

I honestly don't know if the latest released version of NCover even supports .NET 3.0. It is quite possible that it doesn't, which would be a showstopper right there for you.

When you say you are unable to run NCoverExplorer - do you mean using the ability of NCoverExplorer to execute NCover using the "NCover Runner" dialog? As I can't think of a reason why NCoverExplorer itself wouldnt run under 3.0.

I suggest you knock yourself up the simplest of console applications using .NET 3.0, and execute an NCover.Console.exe command line against it taking NCoverExplorer completely out of the equation. By all means you can use NCoverExplorer to generate the necessary command line for you if you need to. Isolate this down to whether it is NCover.Console that is unable to profile your .NET 3.0 application, or if that works whether it is NCoverExplorer that will not execute NCover when the .config file has been changed to run under 3.0...

If you can knock up a mini repro project and zip it all up and send it through to me that would be great - I don't have time to build one myself at the moment (dont even have 3.0 on my machine) but if you do all the legwork to clarify what bit of the chain is "broken" we can hopefully do something about it.