HTML Code coverage report generator

HTML Code coverage report generator

First of all: compliments for the hard work you put into NCover! From what I've seen from it, it looks really promising. In my spare time I've created a very simple/basic HTML generator tool that reads the output coverage.xml file and creates pretty printed HTML code coverage documents for all source files. Each line is either red or green and keywords are highlighted etc.

Current version is very simple and basic, but it does the job. I think it would be nice if the current report (xml/xsl) is integrated or linked to these reports.

An example can be viewed at http://www.virtualsciences.nl/temp/koen/bowling.cs.html and the source can be downloaded from http://www.virtualsciences.nl/temp/koen/TestViz.NCover.Browser.rar

BTW: Peter, did you check your private messages?

Re: HTML Code coverage report generator

I did get your message and responded.  Did you not receive the response?

I have started on a similar output feature for the next release.  I hope to make it available before the next released version.

Re: HTML Code coverage report generator

No, I didn't receive any response? Strange... My mail adress is koen (at) n koen.com (palindrome of my firsname). Maybe you can try it again?

Oops, I didn't know you we're doing the same... maybe a bit useless then, anyway, I hope it can still be of some use. If you want, you can (re)use this code any way you like.

Re: crash due to large switch statement

Great catch!  That's a rather embarrassing problem to have in my code.  Rather than modifying the buffer to be 2000 bytes, I changed it to use a dynamically allocated buffer that is exactly the right size.  Get the latest source code to see the fix.

Thanks again for reporting this defect.

Re: crash due to large switch statement

Thanks Peter,

I will wait until the yield statement works.  I looked through the opcode list and saw nothing obviously wrong (I'm not an IL expert though!).

fxCop complains if you do not use the yield statement, so it is a priority for me.  If you want help I may have some time.

Paul.

G8ZPD

Re: Empty Results File Again :(

The most common reason for this is the profiler failing to find your symbols.  Make sure your symbols are up to date and in the same directory as the application.  More recently, 1.5.0 seems to have a problem with the shadow copy feature in NUnit.  Using the /noshadow option has worked for some others.

Re: Empty Results File Again :(

Thanks... You were right the profiler was not finding the symbols.   Everything is working now.

Thanks again.

Re: NCoverExplorer 1.3.5 beta

The foreground colour for the visited code in the upper right list is coming from the setting for the foreground colour for Full Coverage on the Coverage Tree tab.

It should be black.  Or you could enable setting both foreground and background colours on the Source Code tab like you added to the Coverage Tree tab.

(Set Full Coverage to be white on green and you'll see the covered code lines disappear in the upper right window because they become white on white except for the selected line, which is always white on dark blue.)

Another nice colour enhancement would be to have the ability to set the foreground and background colours for the selected item in the Coverage Tree (separately for when that list has focus and when it does not -- the former is always white on dark blue and the latter is always black on grey). And you might as well add one for the selected item (focus and non-focus) in the Source Code listing.

Or just tell me to go away.   :-)

Some of the options have a question mark icon next to them. Clicking on them does not seem to do anything.

Thanks,

Mark

Re: NCoverExplorer 1.3.5 beta

Can't complain about feedback dude... I do reserve the right to say no however ;-)

Good spot on the statistics pane. I had forgotten to set the background with the change I made for your options. The colours as you have noticed should default to the same as those you set for the coverage tree - since the logic applied is the same in terms of looking % covered etc. I'm reluctant at this point to add yet another set of colour options for the statistics pane as think it will just get way too busy - both on screen and in the options dialog.

If you can find me a way to set the selected/non focused colors of a TreeView control (and ListView) then I can look to add those extra options. Doesn't look like Microsoft expose properties I could see in my quick look at the TreeView object. I could Google myself but if you want it that badly I'm sure you can point me to some code... ;-)

Re the question mark icon on the options dialog. It's intended as a tooltip (no click capability, hence not shown as a button). I have cranked down the popup delay so this is far more obvious.

Other changes in the new build I have just pushed (build 1.3.5.1740 at above link) relate to fixing the colouring for function coverage. No changes to the Extras zip.

Re: NCoverExplorer 1.3.5 beta

New build now up (1.3.5.1744) at links above:

• Added ability to apply filtering and sorting to the reports, both from the console and the application.
• Sorting/filtering now reapplied every time you refresh and persisted in settings as requested on this thread.
• NAnt and MSBuild tasks updated to support new filtering/sorting options.
• Report types, sorting and filtering can all be specified either with their numeric enum values, or with the enumeration name. For instance, you can now do /r:ModuleSummary or /r:1
  
• Further refinements to the reports xsl for function coverage etc.
• Added toolbar button to turn off filtering.
• If the source code is out of date when trying to open file and apply highlighting, user is prompted for a new location in same way as if source file cannot be found.

Re: NCoverExplorer 1.3.5 beta

Another build (1.3.5.1750) up:

• Added ability to run NCover directly from NCoverExplorer (version 1.3.3 or 1.5.x)
• Ability to generate command line, NAnt or MSBuild scripts for above NCover version, using either the standard <Exec> type tasks or my custom <NCover> tasks inside NCoverExplorer.Extras.zip
• After running NCover, the results are then displayed inside NCoverExplorer as requested in this thread
  

Re: NCoverExplorer 1.3.5 beta

Build 1.3.5.1754 now up.

• Fixes a number of bugs in the new "run NCover" functionality
  
• New versions of the NCover and MSBuild tasks if using the script functionality - so download the Extras zip as well.
• MSBuild task can now run NCover 1.3.3 (for completeness only - doubtful you would ever want to).
  

Re: NCoverExplorer 1.3.5 beta

Build 1.3.5.1758 now up.

• Fix bug from spaces in temp path used when running NCover.

Re: NCoverExplorer 1.3.5 beta

Build 1.3.5.1761 now up.

• Bug fix to the <ncover> NAnt and MSBuild tasks (and NCoverExplorer's ability to run NCover) for when using NCover 1.5.4 and not specifying any "assembly" arguments. My thanks to MH for helping get to the bottom of this from this thread.

Re: NCoverExplorer 1.3.5 beta

Looks good to me so far.

One additional feature request:  Add the ability to exclude methods.  Not methods within a class (only method abc if it is in class def), just the ability to exclude any methods named abc* globally.

I'd like to exclude seeing coverage of methods named "set*" and "update*" during the beginning phase of a code conversion effort, for example. (They are much tougher to write tests for, and I want to ensure adequate coverage for the rest of the methods before I tackle those.)

What do you think?

- Mark

Re: NCoverExplorer 1.3.5 beta

Hi Mark,

Excluding methods is definitely on the list - but unlikely for 1.3.5. There is obviously an overlap with the coverage exclusion attribute capability of NCover, however not everyone wants to decorate their code with code coverage directives. There is as you say also the situation where you might exclude "temporarily", plus it is nice to more easily report on the exclusions applied so people are still "aware" of what is being hidden.

I think I will have to cater for both types of method exclusions to keep everyone happy - i.e. both global and class scope:

e.g. "Set*" or "*.Set*" would exclude methods on all classes, and...
       "MyNamespace.MyClass.Set*" would exclude only those on that specific MyClass class.

This feature is not going to be all that useful unless you only work on a single application though - as it needs another thing on my todo list which is the ability to have "projects". That way people can have a group of settings associated with that "project" such as their exclusions, NCover options, filters, sorting etc. I've also briefly discussed with Jamie how he might pass me the Visual Studio solution name when a user does "Test With Coverage" - so NCoverExplorer can lookup the related project file and automatically apply the right settings... Alternately the user can select a project from a menu. Too much to do, too little time...

Re: NCoverExplorer 1.3.5 beta

I have just pushed up build 1.3.5.1789. Quite a few changes and enhancements as listed below:

• Major overhaul to the NAnt and MSBuild tasks
• Renamed the assemblies/namespaces to NCoverExplorer.NAntTasks.dll and NCoverExplorer.MSBuildTasks.dll
  
• The <ncover>/<NCover> tasks now automatically register coverlib.dll (using a registry trick which does not require local admin rights). No more regsvr32 hacks in your scripts!
• The version attribute is now optional. If not specified will determine all the info it needs by interrogating the NCover.Console.exe version attributes.
• Additional support for NCover 1.5.5 such as enabling the LogLevel of "Quiet".
  
• Built documentation for these tasks. You can find this in the zip file, off the help menu, or directly linked here:
  NAnt Task documentation
  MSBuild Task documentation
• Added a new filter option of "Hide All Above Threshold" (in GUI and reports etc).
  
• Fixed a bug for parsing of J# based files which will now allow nested classes to be named the same as property accessors.
• Added a workaround for NCover 1.5.5 to prevent duplicate entries appearing in the tree when being run from TestDriven.Net.
  
• Changed keyboard shortcuts for next/previous unvisited. Now use Alt+Right/Left for unvisited line within class, and Alt+Down/Up for next/previous unvisited class within namespace.
• Remember the last selected tab in the options dialog during a session.
  
• Improvements to the NCover Runner
• No longer needs local admin rights to run when "register coverlib.dll" is ticked.
• Enhanced the logging options to include Quiet as well as Normal/Verbose
• Now uses Ctrl+N as shortcut key.
• Script generation updated to match new assembly names, attributes etc of tasks.

Re: NCoverExplorer 1.3.5 beta

Build 1.3.5.1794 just pushed up.

• Change filter for satisfactory threshold coverage so that it does depth first rather than top down which makes for more intuitive results on screen.
• Updated the extras zip file with NCoverExplorerSummary.xsl now making use of shim.gif which should already exist in CC.Net deployed builds.

Re: NCoverExplorer 1.3.5 beta

Build 1.3.5.1797 pushed up:

• Fix bug in NCover tasks and NCover runner where multiple dlls were specified in the command line args not picked up correctly.
  

Re: NCoverExplorer 1.3.5 beta

Build 1.3.5.1809 pushed up (no changes to NCoverExplorer.Extras since last build 1797)

• Coverage exclusions specified inside NCoverExplorer at "Assembly" scope are now case insensitive
• Implemented the "Stop" button on the NCover runner dialog.

Re: NCoverExplorer 1.3.5 beta

Hi Grant.

I'm having problems with NCoverExplorer showing multiple redundant nodes (and misreporting coverage percentages).  I have build  1.3.5.1809 of NCoverExplorer, and NCover version 1.5.5.0.

On my unit test, which periodically loads some DLL's into temporary AppDomains, NCover generates multiple "module" nodes for the same assembly (in fact, my entire application consists of a single, executable, assembly -- but there are 5 "module" nodes in the coverage output file!)  When the resulting coverage file is opened in NCoverExplorer, the multiple module entries appear to confuse NCoverExplorer.

I think NCoverExplorer should collapse such redundant "module" nodes, merging method lists and aggregating the sequence points counts within methods, in the case when several "modules" are actually the same exact assembly.

I've sent you the coverage file (using the address from your homepage), so you can take a look for yourself .

Re: NCoverExplorer 1.3.5 beta

Hi Boris,

Thanks for the e-mail. The problem isn't really with NCoverExplorer - it is caused by NCover 1.5.5. If you "roll back" to NCover 1.5.4 I believe you will find things are ok.

You are absolutely right that things should be merged, and that is what NCoverExplorer does. The problem however is that NCoverExplorer uniquely identifies methods by (amongst other things) their first and last sequence point line numbers. NCover 1.5.5 unfortunately has some problems with a new feature Peter added to remove no-op instructions. The problem it causes is that it does not remove these consistently - so in some of those "multiple module nodes" you noticed it will have an extra sequence point at a different column/line location. NCoverExplorer can't tell the difference of course so treats it as another method - hence the "duplication" in the treeview and corrupted coverage results.

In the long term Peter will finish the refactoring he is doing and hopefully get this issue resolved completely. I am sure he would be interested when he has 1.5.6 ready for you to try it and see if it resolves the issue. I must admit this is the worst "case" of "multiple modules" I have seen. How are you launching NCover (TD.Net or command line?)? Are your tests specifically creating AppDomains as part of their execution?

As I mentioned on another thread today I did have a blog entry about all this which was intended to warn people away from NCover 1.5.5 for mostly this reason. I held off publishing it as we thought we might have a workaround for TestDriven.net users that Jamie was working on. However his fix and the one I made in 1.3.5 will only resolve the problem of a multiple module where one of them has a blank assembly name. This is another problem altogether that would be great to get a small repro for.

Re: NCoverExplorer 1.3.5 beta

Grant,

First, thanks for your excellent support.  I'll try to come up with a small repro, as you asked.  But in the meantime, to answer your questions:

I get these results regardless of whether I go through TestDriven or through command-line.  In fact, I initially used NCover only through TestDriven, but then upgraded to version 1.5.5 (because I was getting a lot of "unvisited" code in the older version, and 1.5.5 promised to fix the problem somewhat.)  Immediately, I noticed this issue with NCoverExplorer.  So, I tried to run NCover from command-line, to see if the problem might be connected to TestDriven's automation.  The symptoms are exactly the same, so it's not TestDriven's fault.  Of course, my next step was to download the latest available version of NCoverExplorer -- but of course, as you know, that didn't fix the problem either...

Regarding the AppDomains (which is what I suspect is causing the problem, because otherwise my app is pretty ho-hum) -- it's part of the app's implementation to allocate a temporary AppDomain on start-up, scan all assemblies in its runtime directory into that AppDomain, and then inspect each assembly for the presence of certain interface-implementing classes.  Basically, it's part of a plug-in mechanism, where the plugins are discovered and loaded dynamically -- the idea is that all that's necessary to add a new plugin, is to copy its binaries into the app's runtime directory.  Once all the plugins are found, the temporary AppDomain is unloaded, to free up memory.

Several of my unit tests exercise the plugin-discovery and loading logic, and the associated error handling mechanisms.  Several more unit tests exercise the application's entry point, which invokes the plugin loader as well as doing a few other startup tasks.  Each time, slightly different scenarios are exercised -- which might help explain NCover's slightly different behavior that causes the multiple "module" entries as you described.

So actually, in each applicable test case there's only one temporary AppDomain being created and then unloaded -- but many test cases are being executed, which might help explain the number of duplicated "module" entries I get.  Anyway, I'll try to get back to you tomorrow with a small and simple sample app that manifests this problem.

In the meantime, I don't quite understand why NCoverExplorer cares about the last sequence point of a method.  Isn't it enough to know the method's name and class, together with the starting entry point line and column number (which ought not to ever change -- or am I wrong), to uniquely identify it?

Re: NCoverExplorer 1.3.5 beta

Hi Boris,

Thanks for the detail - that fits what I suspected about the causation of the AppDomains. There does seem to be a little gotcha in certain scenarios with the AppDomain creating that is tripping NCover 1.5.5 up so if indeed you can find the time to make the mini repro I'm sure Peter would be delighted. I'm sure Jamie will be equally delighted that as we suspected it is not specifically TD.Net that causes a problem!

As for why I need the end line# too? It's because class level variables that have initialisations as part of their declaration get listed as the first line sequence point line for constructors. So when you have overloaded constructors they will all show the same start line number, but obviously have different end line numbers which is what I use to differentiate them.

public class Illustration
{
    private string someVariable = "Grant";  // This will be the first line number for both constructors.
   
    public Illustration()
    {
    }

    public Illustration(string parameter)
    {
       someVariable = parameter;
    }
}

Re: NCoverExplorer 1.3.5 beta

Grant,

I've had a great deal of trouble cutting down the original program.  After a day and a half of trying, my "simplified" versions flatly refuse to mirror the behavior of the full-blown app (they do generate multiple "module" entries, but these entries aren't missing any sequence points, and do not result in duplicated nodes within NCoverExplorer.)  I'm utterly baffled.  It seems, somehow, unwittingly, I stumbled upon a very rare condition -- which, while reproducible, is paradoxically very hard both to diagnose and to replicate independently.  I give up!

Re: NCoverExplorer 1.3.5 beta

Hi Boris,

That's a shame - I guess fingers crossed Peter manages to resolve it as a byproduct of the other work he is doing to that portion of the codebase. Sadly not much else we can do without a fixed NCover release.

Re: NCoverExplorer 1.3.5 beta

I've just pushed up build 1.3.5.1813 of NCoverExplorer and NCoverExplorer.Extras:

• Fixed memory leak from continually opening/closing source code tabs
• Made dialog hopefully clearer that appears when source code is out of date
• Additional bugs and tweaks to the NCover NAnt script and command line generation

Re: NCoverExplorer 1.3.5 beta

Build 1.3.5.1850 of NCoverExplorer-1.3.5b.zip now available:

• Improvements for .Net 2.0 treeview performance
• Bugfixes for when relative paths used in coverage file and report filename arguments to NCoverExplorer.Console.exe

Re: NCoverExplorer 1.3.5 beta

                Build 1.3.5.1861 of NCoverExplorer-1.3.5b.zip and NCoverExplorer.Extras-1.3.5b.zip now available:<br /><br /><ul><li>Added support for regular expressions in coverage exclusions<br /></li><li>Changed the xml schema for .config files being passed to NCoverExplorer.Console so that the attributes for "ModuleExclusion" nodes are now proper cased not camel cased. Anyone using this particular feature will need to either update their files manually (if passing via the &lt;exec&gt; task) or take the latest NAnt/MSBuild tasks.</li><li>NAnt/MSBuild tasks updated to support the regular expressions option for coverage exclusions. Also enhanced the MSBuild ability to specify exclusions - the same way traditionally using Type=Pattern pairs is supported, as well as a new way of defining a &lt;PropertyGroup&gt; with nested xml. The latter is required if you want to specify regular expressions.</li><li>Added a load more examples to the NCoverExplorer MSBuild/NAnt documentation.</li></ul><br /><br />

Re: Constructor Coverage

Colin,

Yeah I see what you mean. It keeps coming back to the "same old chestnut" time and time again - unfortunately NCover does not produce a unique identifier for each method on a class. So in NCoverExplorer I have to do a series of "kludges" to try to handle things transparently particularly when merging coverage files. My "latest" attempt in 1.3.4 which solved the merging problem people had was to uniquely identify each method using a combination of its name, class, assembly AND the first line# in the sequence point coverage. Most of the time, this works well to identify the overloaded methods.

However if you look at the raw coverage xml produced in this situation, you will see that in each case of the constructors in your "NCoverExplorerTest1" class they have the same first statement that was executed - being the initialisation of the variable. In "NCoverExplorerTest2", the first line is the constructor declaration, which does allow NCoverExplorer to see the methods are on different lines.

I am clearly going to have to change that logic again - I can use the "last" line number as well in the "unique key". This wasn't really an easy option to me originally with how I was streaming the file in but I think I read the coverage file a little differently now so this should hopefully be a trivial change.

I will take a look in the next few days and let you know when there is a new beta version to try. Thanks for posting this here with the great detailed explanation - I love it when I just have to copy/paste to replicate an issue ;-)

Re: Constructor Coverage

Colin (or others interested),

I have got my first beta build together for the next NCoverExplorer release, which includes this bug fix. Please give it a go and tell me what you think. I will have more to add to this release over the coming weeks before I officially release it but it should get you going in the meantime.

The "only" other thing I have added at this point is a bunch more coverage viewing options for showing function coverage percentages etc (alternative to sequence point coverage). There is also a new report (report type 5 for your build script) for showing function coverage per module/namespace/class as requested by someone. Of course you need to update your xsl stylesheet on your CruiseControl server if you make use of that (so a new NCoverExplorer.Extras.zip available as well).

http://www.kiwidude.com/dotnet/NCoverExplorer-1.3.5b.zip
http://www.kiwidude.com/dotnet/NCoverExplorer.Extras-1.3.5b.zip

Please let me know how you get on...

Re: Constructor Coverage

That did the trick for resolving the issue I was seeing.  Thanks for the quick replies on this!

Re: Report not generated...

Hi Peter,

Which target are you running - the "Coverage" target or the "NCoverExplorerMerge" one?

The "report not generated" message I would expect to come from the "NCoverExplorerMerge" target - you havent specified an xml or html report filename so by default it will not generate a report.

What is the output if you just run the "Coverage" target? There should be a big section where NCoverExplorer dumps out all the parameters that are passed to it...

Re: Report not generated...

I'm running both, "Coverage" from tasks section and "NCoverExplorerMerge" from publishers section. When running just Coverage, I get the following in my build results.

Re: Report not generated...

When running Coverage alone in the merge section, I get the following output.

Invalid command line switch for "NCoverExplorer.Console.exe". Illegal characters in path.

The "NCoverExplorer" task failed unexpectedly.
System.ArgumentException: Illegal characters in path.
   at System.IO.Path.CheckInvalidPathChars(String path)
   at System.IO.Path.NormalizePathFast(String path, Boolean fullCheck)
   at System.IO.Path.GetFullPathInternal(String path)
   at System.IO.Directory.CreateDirectory(String path, DirectorySecurity directorySecurity)
   at System.IO.Directory.CreateDirectory(String path)
   at MSBuild.NCoverExplorer.Tasks.NCoverExplorer._GetConfigFilename()
   at MSBuild.NCoverExplorer.Tasks.NCoverExplorer._CleanupConfigFile()
   at MSBuild.NCoverExplorer.Tasks.NCoverExplorer.Execute()
   at Microsoft.Build.BuildEngine.TaskEngine.ExecuteTask(ExecutionMode howToExecuteTask, Hashtable projectItemsAvailableToTask, BuildPropertyGroup projectPropertiesAvailableToTask, Boolean& taskClassWasFound)

Re: Report not generated...

Hi Peter,

I just got your later posting - you are right, it should not be the same issue described in the FAQ. It looks like it's choking when trying to create the output directory. What is the value of your "CoveragePath" variable in the script?

Here's what I had typed in response before I saw that - it may still help:

It might be easier to just temporarily take CruiseControl out of the equation if you can (get your MSBuild script running from the command line and then plug it in).

When you run from the command line, you should see output like the following:

Project "F:\NCoverTest\nursery.proj" (NCoverExplorerReport target(s)):
Target NCoverExplorerReport:
    -----------------------------------------
        NCoverExplorer.Console 1.3.5.1762
        (c) 2006 Grant Drake
        http://www.ncoverexplorer.org/
    -----------------------------------------
    Using .config file: F:\NCoverTest\MSBuild.NCoverExplorer.config
    -- Options:
         Project Name: NurseryRhymes
         Acceptance%:  80%
         Sort:         Name
         Filter:       None
         Xml Report:   F:\NCoverTest\CoverageSummary.xml
         Html Report:  F:\NCoverTest\CoverageSummary.html
         Report Type:  ModuleClassSummary(4)
         Merge To:     N/A
         Min Coverage: 80
         Exclusions:   (Included in report footer section)
         - any Assembly matching .Tests
         - any Namespace matching .Tests
   
    -- Loading file: F:\NCoverTest\Coverage.xml...
    -- Calculating coverage and applying exclusions...
    -- Sorting...
    -- Coverage file parsing complete.
   
         68.75% coverage, 20 unvisited sequence points in 1 coverage file(s).
   
    -- Applying command line options ...
    -- Generating summary report...
    [OK] - Xml report created: F:\NCoverTest\CoverageSummary.xml
    [OK] - Html report created: F:\NCoverTest\CoverageSummary.html
    -- Done.
__________________________________________________
MSBuild Summary: Build succeeded.
    0 Warning(s)
    0 Error(s)
Build succeeded.
Time Elapsed 00:00:01.32


That was produced using this script:

 <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">;

  <UsingTask TaskName="MSBuild.NCoverExplorer.Tasks.NCoverExplorer"
             AssemblyFile="MSBuild.NCoverExplorer.Tasks.dll"/>

  <PropertyGroup>
    <CoveragePath>$(MSBuildProjectDirectory)</CoveragePath>
  </PropertyGroup>

  <ItemGroup>
    <CoverageFile Include="$(CoveragePath)\Coverage.xml" />
  </ItemGroup>
 <Target Name="NCoverExplorerReport">
     <NCoverExplorer
              ProjectName="NurseryRhymes"
              ReportType="4"
              OutputDir="$(CoveragePath)"
              XmlReportName="CoverageSummary.xml"
              HtmlReportName="CoverageSummary.html"
              ShowExcluded="True"
              SatisfactoryCoverage="80"
        CoverageFiles="@(CoverageFile)"
        Exclusions="Assembly=.Tests;Namespace=.Tests"
        />
    </Target>
</Project>

Re: Report not generated...

   <CoveragePath>$(MSBuildProjectDirectory)</CoveragePath>

I'll try the command line MSBuild first thing in the morning. Thanks again for all of your help.
Peter

Re: Report not generated...

Oddly enough, when running in MSBuild command line, it wasn't happy until I referenced the property group variables as $(@PropertyName), where I had been using $(PropertyName).

Does this make sense to how things are supposed to work?

Re: Report not generated...

Sorry Peter, without seeing your entire script it's hard to say. If you look at the example I posted above - that most definitely works from the command line. So if you follow that syntax you should be ok...

Re: Report not generated...

Grant,

It all seems to be working fine from the command line, now I just have to figure out how to make it play nicely in CCnet. It will generate the reports, but the integration status still comes back as false and the report (which is generated) does not display on the website.

Thanks for all of your help, I'll work through these (most likely noob) issues tomorrow.

Peter

Re: Report not generated...

Hi Peter,

I am a NAnt user myself so havent tried running those tasks directly from CCNet but there shouldn't be a difference in theory - surely someone else would have reported a problem by now if there was. I suggest cranking up the logging level of MSBuild to "Diagnostic" and see what you get...

As for the report not appearing - a couple of things to check...
(1) Is the <coverageReport> xml merged into your build log?
(2) Are the stylesheets copied to your CC.Net webdashboard xsl folder, and have you updated your dashboard.config as per the instructions in the NCoverExplorer.Extras zip download?