Forum Archives
Resources Support
Forums › Suggestions / Feature Requests › Output Folder Pollution

Output Folder Pollution

Output Folder Pollution

(NCover.Reporting 3.0.20) From what I can see, NCover.Reporting uses a random naming scheme for web pages, when creating an Html Report. If you are using NCover.Reporting to create the web pages in the same folder again and again, you end up with lots of stale copies of the web pages in the 'files' folder of the site, that are not referenced any more.

Solution A: Use a non-random approach for naming, e.g. similar to the naming scheme(s) used by Sandcastle for documentation pages.

Solution B: Clear the 'files' folder before actually writing the new files.

Solution C: A + B

Solution A has the advantage that, provided the algorithm for the page naming is published, you can create links to report pages from other web pages or documentation. If somebody writes a plugin for Sandcastle Help File Builder, coverage data could be automatically included/referenced in online help files/help web pages.

RE: Output Folder Pollution

I thought we were clearing the files first. The name of the files should be the same every time since it is an md5 of the path.

I will look into this and see if it is a bug.

I will also look to see how sandcastle is naming the files.

Joe

RE: Output Folder Pollution

E.g. I've got a project that has been built four times:

  • 425 files in the files folder belong to the most recent build.
  • 316 files in the files folder belong to the previous build.
  • 316 files in the files folder belong to the build before that.
  • 316 files in the files folder belong to the build before that.

Looks as if some file names are reused (109), but the others (316) aren't?

The project itself should not have changed much between the builds. Are time stamps or (assembly) version numbers or something like that part of the MD5?

RE: Output Folder Pollution

I've checked the code that creates the filenames, and we do include the assembly identity as part of the hash for everything except source files. We've had trouble in the past reporting on multiple versions of the same assembly that were covered at the same time, so we can't change how we create the hash.

However, I will add a task to this release to clear the files in the \files\ folder when the FullCoverageReport is created, and we'll get that fix into the next release.