NCover

Hey,
The majority of my applications are an ASP.Net applications that use the Com+ (EnterpriseSerivces)
As the host for my business logic.
I maanged to connect the NCover to the ASP.Net, but I cant find a way to tell NCover to profile my com+ application.
Is there a way to tell NCover to "attatch" to a specified process?
If not, it would be a great improvement because it will allow to run NCover on windows services, console application, and basically every process hosting the CLR.

Thanks haead

--Rami

Try the new attribute-based exclusion feature.  We probably need pattern-based exclusion as well, but it's a start.

Oops, sorry; should have posted this to the NCover forum rather than the NCoverExplorer forum

Just to add, if ccservice runs from a local administrator's account, the task works fine. So it's not something with service vs console.

Dave

Hi mate,

The short answer is no I have not tried running the <ncover> task using CC.Net as a service.

From your follow up post, are you saying the issue now is if you use a non local administrator account to run cc.net as a service? As when you use a local administrator account to run cc.net as a service it works fine? Using a non local administrator account to run it as an exe - that works ok too or does that fail?

Another workaround to try would be to just regsvr32 the coverlib.dll on that machine (under your administrator account), and then run the service under your non local admin account.

Let me know if you draw a conclusion from all of your experimenting - I'm on holiday at the moment so trying not to work too much but if it's an issue the intrigue usually forces me to crack open the laptop...

Have a great Christmas,

I'm not too familiar with domain vs local admin, so I don't know which categories are likely to be relevant. But, I'll try to outline what I've tried and the results.

A quick listing of what I've gathered so far:

CC.Net as console app, local admin: ???

CC.Net as service, local admin: ???

CC.Net as console app, domain account with local admin right: Works!

CC.Net as service, domain account with local admin right: Works!

CC.Net as console app, limited user: ???

CC.Net as service, limited user: ???

CC.Net as console app, LocalSystem account: I don't think this is testable because there is no way to log on or run as the LocalSystem account.

CC.Net as service, LocalSystem account: Does NOT work.

Since I know how to workaround the problem, I'm not blocked on this anymore. I would like to figure out whether it works as a limited user so that I can add this caveat to the CruiseControl.Net + NCover page on the CruiseControl.Net confluence site.

Thanks for the help KiwiDude, and enjoy your time in Thailand!

Dave

Thats an interesting one. I take it that it is generating the xml report ok (if you look in that folder)?

The code being executed looks something like:

- Generate the xml report
- Verify the CoverageReport.xsl stylesheet exists in the NCoverExplorer source folder
- If stylesheet of that name already exists in the target folder, and it has the read-only attribute set, then remove the read-only attribute
- Call File.Copy(source, dest, overwrite=true)

So the only things that could go wrong would be if it cannot copy over the top of that xsl file, or if it cannot change the readonly attribute on it. Do you have some window open already like in IE using that stylesheet which is holding a file lock so it cannot copy it? Assuming you do already have a CoverageReport.xsl in that folder (which it looks like you do according to the error message), try deleting it and see if you are allowed to. You can always use a tool like "Unlocker" to find out what process has the file handle.

kiwidude wrote:

Thats an interesting one. I take it that it is generating the xml report ok (if you look in that folder)?

The code being executed looks something like:

- Generate the xml report
- Verify the CoverageReport.xsl stylesheet exists in the NCoverExplorer source folder
- If stylesheet of that name already exists in the target folder, and it has the read-only attribute set, then remove the read-only attribute
- Call File.Copy(source, dest, overwrite=true)

So the only things that could go wrong would be if it cannot copy over the top of that xsl file, or if it cannot change the readonly attribute on it. Do you have some window open already like in IE using that stylesheet which is holding a file lock so it cannot copy it? Assuming you do already have a CoverageReport.xsl in that folder (which it looks like you do according to the error message), try deleting it and see if you are allowed to. You can always use a tool like "Unlocker" to find out what process has the file handle.

<font>Grant,</font>

<font>Thanks for the reply.</font>

<font>To answer your questions:</font>

<font>Yes, a "CoverageReport.xml" file is being generated in the directory everything is being run from.</font>

<font>CoverageReport.xsl exists in the directory everything is being run from and is not marked as read-only.  I can delete the file without problem.</font>

<font>The machine that is running all of this is a dedicated build box - so the only thing running on it is the ccnet service.</font>

<font>I've tried running both "Unlocker" and "Proess Explorer" but I think things are moving too fast when the error happens to actually trap the process that has the file open.  If I right-click and run Unlocker on CoverageReport.xsl when the error happens, it tells me "No Locking handle found.".</font>

<font>I'm not sure I understand what you mean about source and target directories for the files - everything lives in c:\nunit\bin (the unit test DLL's, NCover, NUint, etc.).</font>

John Cavanaugh wrote:

kiwidude wrote:

Thats an interesting one. I take it that it is generating the xml report ok (if you look in that folder)?

The code being executed looks something like:

- Generate the xml report
- Verify the CoverageReport.xsl stylesheet exists in the NCoverExplorer source folder
- If stylesheet of that name already exists in the target folder, and it has the read-only attribute set, then remove the read-only attribute
- Call File.Copy(source, dest, overwrite=true)

So the only things that could go wrong would be if it cannot copy over the top of that xsl file, or if it cannot change the readonly attribute on it. Do you have some window open already like in IE using that stylesheet which is holding a file lock so it cannot copy it? Assuming you do already have a CoverageReport.xsl in that folder (which it looks like you do according to the error message), try deleting it and see if you are allowed to. You can always use a tool like "Unlocker" to find out what process has the file handle.

<font>Grant,</font>

<font>Thanks for the reply.</font>

<font>To answer your questions:</font>

<font>Yes, a "CoverageReport.xml" file is being generated in the directory everything is being run from.</font>

<font>CoverageReport.xsl exists in the directory everything is being run from and is not marked as read-only.  I can delete the file without problem.</font>

<font>The machine that is running all of this is a dedicated build box - so the only thing running on it is the ccnet service.</font>

<font>I've tried running both "Unlocker" and "Proess Explorer" but I think things are moving too fast when the error happens to actually trap the process that has the file open.  If I right-click and run Unlocker on CoverageReport.xsl when the error happens, it tells me "No Locking handle found.".</font>

<font>I'm not sure I understand what you mean about source and target directories for the files - everything lives in c:\nunit\bin (the unit test DLL's, NCover, NUint, etc.).</font>

<font>Some additional information.</font>

<font>I ran process monitor and had it filter on CoverageReport.xsl during the entire build process.  The only process touching CoverageReport.xsl was ncoverexplorer.console.exe and of the 18 times that it touched the file during the build 3 IRP_MJ_CREATE operations resulted in "SHARING VIOLATION"s.  I've got a PML file from procmon I can email if you that would help.</font>

<font>Let me know what you think.</font>

<font>Thanks.</font>

Hi John,

By source and target directories, I meant the source being the NCoverExplorer executable directory where the xsl is copied from, and dest being the location where the report is created and hence the stylesheet is copied to.

Sounds a real puzzler, and I've never had anyone else report a similar issue to me. I would ask if you have a virus scanner running or something but surely that would have shown up in process monitor?

I will have a think about it tomorrow night after work to see if I can come up with anything else. If you can send me an email with your process monitor log (support at ncoverexplorer.org) then I may do a special build or something to try to diagnose where the problem lies. Ordinarily I would suspect an unclosed file stream, but the xsl file is literally just a call to File.Copy in the .NET framework.

<font>Hi Grant - thanks for replying.</font>

<font>Interesting that you mentioned the virus scanner.  The build box is running McAfee VirusScan Enterprise 8.0.0 and it's on-access scanner is enabled; however, no virus scan activity is coming up in procmon during the build.  However, we have rules built-in to the on-access scanning which may be allowing build things to happen without being scanned.</font>

<font>I turned off the on-access scanner and tried to do a build with the NCoverExplorer stuff back in and got the same error message as before.</font>

<font>I've sent you email with the procmon log - let me know what you think.</font>

<font>Thanks.</font>

<font>--</font>

<font>John Cavanaugh</font>

Just to close this one out for anyone else reading. John was generating his coverage report in the same folder as the NCoverExplorer executable. So the exception message was caused by it trying to copy the stylesheet over the top of itself. I will add some code to NCoverExplorer to prevent this situation happening but the easiest workaround is to use separate folders for your tools and the actual application assemblies/coverage output.