Profiling IIS - Watin tests run from command-line

Hi,

I'm runing Watin tests using XUnit and want to use NCover to get coverage information, I have thus tried using the "//iis" command-line argument but this when I do my test run just ends with:

 [exec]
 [exec] ******************* Program Output *******************
 [exec] Stopping Service [World Wide Web Publishing]...
 [exec] Starting Service [World Wide Web Publishing]...
 [exec] The profiler will not connect until you load an ASP.NET page.
 [exec] Press Control-C to stop the service and collect coverage data.
 [exec]

No tests are run and it just appears to sit there waiting.

If I remove "//iis" the test runs fine, I should also say I'm assuming //iis is the command-line equivalent of using true in a config file.

I was thus wondering what I am doing wrong?

Thanks,

Colin

RE: Profiling IIS - Watin tests run from command-

Could you post more of the command line you're using? something like the following command line should do what you are trying to accomplish:

ncover.consol.exe //iis

RE: Profiling IIS - Watin tests run from command-line

We're running it througn NAnt, the is what it looks like without the "//iis" (which I was just tagging on to the end of the commandline):

<exec program="${ncover.dir}\ncover.console.exe" commandline=""${testRunnerExe}" "${build.dir}\Specifications\App.Web.Integration.dll" //eas "${excludeAssemblies}" //x "report.xml" //p "${projectName}" //ssp "${symbolSearchLocations}" //w "${workingDirectory}"" failonerror="false"/>

RE: Profiling IIS - Watin tests run from command-

adding "//iis" at the end of that command line should do what you were trying to do then, despite the message that NCover prints on the console (it's confusing, I know, there is an open case in our system to resolve it).

Depending on how long you waited last time you tried, one thing to keep in mind is that NCover will increase the startup time of any IIS tests you have, since it has to prepare them for gathering coverage. We've seen start up times double very easily.

Does that maybe help clarify some of what you should expect NCover to be doing?

RE: Profiling IIS - Watin tests run from command-line

Interesting, I did actually leave it for quite a while and just there now left it sitting for a very extended period of time but the message just stayed up and nothing else of not happened.

Any ideas?

Also is there any way to convince NCover to be more verbose in this situation to help me tell what its doing?

RE: Profiling IIS - Watin tests run from command-

no extra reporting is available on the console unfortunately. You can add "//ll Normal" to the command line to tell NCover to generate a log file that will tell you whether NCover connected to IIS or not. It might also be an issue with the license key. Are you using a classic or a complete license?

RE: Profiling IIS - Watin tests run from command-

I think we've tracked down and fixed the problem that was plagueing you a couple of days ago. These installers have the fix

http://files.ncover.com/NCover-x86-3.3.3.6317.msi http://files.ncover.com/NCover-x64-3.3.3.6317.msi

RE: Profiling IIS - Watin tests run from command-line

Hello,

My team is currently evaluating NCover 3.3. We have an ASP.NET web application that is tested through automated WatIn tests via NUnit.

With NCover 3.3.2, we had the same issue described by the opening poster. After reading this thread, we upgrade our installation to 3.3.3. In this version our tests run, but they are not detached correctly after the test suite completes.

After the Test Suite completes, we receive the error: NCover.Console is returning exit code #20000

If we Ctrl-C prior to the test completion, the w3p process is ended, but the NUnit test fixture continues to run (and fails tests, as IIS has been shut down) and we are forced to manually kill the process.

Any advice would be appreciated.

RE: Profiling IIS - Watin tests run from command-line

jchiancone,

Can you send the output that you're seeing on the console to support@ncover.com? We're investigating an issue that sounds similar to yours with a few users.