Welcome, Guest!
We have multiple projects deployed on CC.NET. If two project start building at the same time there is a problem of one build turning off the IIS service for the other integration build.
I there a way to configure IIS in such a way, that NCover would not have to restart IIS service, and just connect to it if needed during the integration and testing build profiling?
not at the current time.
Stephen
Can you/Will you add such a feature in the future?
We're not sure we can. If it's possible, it would mean reworking NCover's artichecture, so that when a process started, a lightwight stand-in dll was always loaded, to which NCover could connect later. We haven't even prototyped the concept yet, and needless to say it would involve major changes to NCover. So we're not sure if we will add such a feature, and if we do, it won't be within the next 12 months.
Stephen
I think you should consider giving it a higher priority, cause without this CC.NET is crippled when NCover is part of its build process.
We have about 20 solutions in our CC.NET setup, most of them have asp.net projects, our teams usually work on about 4 solutions at any given time. So when there are multiple check-ins builds running on 2 solutions, one of them will fail tests, caused by IIS taken offline.
From my point of view the part NCover that is plug-in to IIS, does not have to be lightweight, our build server have enough muscles to handle that, and anyway when IIS is running something it is ALWAYS an integration build test, and there is ALLWAYS NCover present.
A compromise solution is to serialise CC.NET builds in one queue. Bad solution cause we want to know the results of a build as quickly as possible, and there is no point in having powerful build server is there is only one build going one at any give time :(.
Can you provide some kind of quick workaround that enable profiling of all integration builds but would not require IIS restart? 12 months is a little bit to long.
Without this in our perspective NCover is not production ready/worthy, because test profiling would have to be run manually by developer on a separate machine, and that is waste of time, why have CC.NET builds setup to just avoid such a waste :(.
Please give me something to work with because I'm loosing in the battle for implementing NCover.
wooyek,
NCover, in its current state, is meant to profile one process at a time. Due to Windows process architecture, the way NCover gathers coverage data, and the CLR architecture, it is simply not possible for NCover to gather data from an already running process; doing so means solving about a dozen fairly difficult problems involving memory allocation and deallocation, process attatch/detatch, and gathering coverage, among other things.
The only workaround I can suggest now (other than running ASP.NET tests in serial) is to run the IIS tests on webdav, the VS test web server. You'll have to run each process on multiple ports, but you can have multiple webdav instances running on a single machine, so NCover won't trounce on the tests in any other project.
Regards,
Stephen Ward
There is no way you could setup NCover to start IIS in NCover snadbox by default, profile etherything that is/will be runnig on this IIS process, and only gather profilining info when needed by starting NCover.Console!?
no.
you could always start IIS in the NCover sandbox and then gather coverage by stopping IIS, but that's the closest NCover will come to that (your desired functionality) now.
Stephen
OK, I think I understand now... You collect coverage data, but you need to stop IIS to pass this data to NCover.Console, am I correct?
PS. Your suggestion to use development server to separate web server processes is somewhat contradictory to the "Enterprise Edition" name ;)
Yes. Stopping whatever process NCover is covering is the trigger that tells NCover to collect the coverage data.
P.S. I am struck by the irony as well