NCover - Code Coverage for .NET Developers

Code Quality

Peter Waldschmidt — Fri, 10 Jul 2009 03:17:00 GMT

As the creator of NCover I often get asked what my inspiration was and what the importance of code quality and coverage really is. Well, it’s really very simple:

Customers expect more.

They want software publishers to make their software available for instant download over the Internet, pushing updates frequently. They expect software to install quickly and easily and work right the first time out of the box. Software that upgrades itself is even better. All of these things contribute to your customer's expectations for a quality product. So how can we consistently achieve quality?

Quality is not something you can add to a product; it must be built into the foundation.

It has been said that if we regularly pay attention to something it will improve, while what we ignore will languish. Software quality is achieved by not only paying attention to it, but also by understanding what quality really is.

So, what do I mean by quality?

There are qualitative measures of quality like:

Does the software solve the customer's problem? Does it do what it was designed to do?
Does the software meet all of the specifications that were defined when starting the project?

These aspects are sometimes measurable, but may just result in arguing over the definition of the problem your software hopes to solve. The measures that I want to focus on right now are the quantitative measures.

How many bugs have my customers found in my code since it was released?
Have our support requests increased or decreased since the new release? What is the ratio of support calls to users?
Has the complexity of my code improved or decreased over time? How understandable is it?
How many automated tests do I have? are they passing?
What code is tested by my automated tests? More importantly, what code is NOT tested by those tests?
Is my code getting slower or faster over time?

These are pieces of the development process that cannot be ignored.

A decade ago, source code version control software was the only real tool requirement that a software shop had aside from a compiler and maybe a text editor. If you were doing version control, then you were writing software right. Now, we've reached the point where, if you are not doing version control then you are either lazy or ignorant and there are even higher expectations like continuous integration, automated testing, stress testing, code coverage and static analysis.

My primary message is this:

Put in place measurements at key places in your development process and know what those numbers mean. Watch them and improve them. Measurement is the first step on the way to building a software development process that produces high quality products.

NCover Trend Format Changes

Joe Feser — Mon, 22 Jun 2009 20:01:00 GMT

Our customers have spoken and we listened. We received a bunch of requests to speed up and optimize the memory usage of our trends feature in NCover 3. For more information on trends please click here.

NCover v3.1.4 includes a brand new binary data format for coverage trends. What does that mean for you? It means that the entire set of trend data no longer needs to be loaded into memory any time you work with trends. The time and memory required to append a new coverage file to the trend file has been reduced by as much as 80% and the file size by 50-66%. It also means that we are able to read any piece of trend data from any location in your coverage file in a fraction of the time it took with the existing format. Associating a trend file to a coverage file is now an instantaneous operation. No longer will you watch the "Loading Trends" dialog.

With changes come new behaviors. By default, if the coverage file path does not exist, we will create one for you and it will be empty until trends are added to the file. We will also require you to use the new binary format for any new trend files. You will no longer be able to create a new xml based trend file from scratch. Your existing xml based trend files will continue to work, but we highly recommend converting them to the new format using the new converstion tool that we will talk about next.

NCover v3.1.4 ships with a new tool called ncover.upconvert. The experience of moving to NCover 3 taught us that people do not want file formats changing by magic, so we now require you to convert trend files if you wish to use the new functionality. Our support cases tell us that this is a good thing.

At this time the new application only has two switches, one to set the source files, and one to write to a single destination file. You can use an unlimited number of input files to write to the new output file and the application will be smart enought to ignore any duplicates. This is cool if you have a series of smaller trend files that you wish to covert to our new format since it is so much better than before. The input files may be the old or the new file format.

Every input file is prefixed with the //it flag and one flag is provided for the //ot output flag as seen below. Returns have been added for clarity.

ncover.upconvert //it c:\mypath\input1.trends
//it c:\mypath\input2.trends 
//ot c:\mypath\output.trends

The command will take the input1.trends and input2.trends file and append the data to a new file called output.trends in the new binary file format.

On a final note. You do not need to convert your files if the xml format works for you. The changes are invisible to the user. NCover and NCover Explorer will continue to read the old and the new format without any intervention from a human.

We would love to hear from you about your trends experience. You can do so by commenting on this blog entry or by emailing us at support@ncover.com.

Download the new version here.

NCover v3.1.4 released!

Joe Feser — Mon, 22 Jun 2009 17:56:00 GMT

Download the new version here.

Features and Improvements

Added new trend file format that reduces memory use by up to 80% and improves update speed by up to 93%.
NCover Explorer windows now reposition themselves if they appear off screen.
Improved the error messages and error handling of the registration program.
Improved the calculation of uncovered code blocks in the Summary, UncoveredCodeBlocks, and FullCoverageReports which sped up those reports by up to 10x.
Added //ignorefailedbuilds argument to NCover Reporting.
Added //reportinvalidfiles argument to NCover Reporting.
The trend graph in NCover Explorer now shows trends for method coverage and cyclomatic complexity, and respects the Satisfactory coverage value for those metrics.

Changes

Registration program now asks for proxy login info when using proxy information from Internet Explorer.
The //op and //or arguments now accept relative paths.
Runtime Intelligence was removed.
NCover Console now prints a message if the trend file could not be opened.

Bug Fixes

The main NCover Explorer window wouldn't remember it's last open position on the desktop.
NCover Explorer windows would reposition themselves if last opened with negative coordinates (problem on multi-monitor systems).
The "Working Folder" and "Html Report" configuration settings in NCover Explorer now open a Folder Browser as they should.
Updated trend files to handle incorrect class signatures in coverage files created prior to v3.0.10.
Summary and UncoveredCodeBlocks reports could throw an exception under some circumstances.
Fixed highlighting bug in NCover Explorer for lines that could be executed from two different constructors.
Fixed sort order for the "UnvisitedSequencePoints Ascending/Descending" sort option.
NCover Explorer required a value for the "Working Folder" field when Windows Services were being covered.
NCover Console was saying that it couldn't find executables that were on the PATH.

Good Code Coverage Is Never Enough

Stephen Ward — Thu, 18 Jun 2009 19:04:00 GMT

For the past month, the NCover Support Team hasn't been very responsive.

Ok, they haven't answered any support questions at all.

But there's a good reason for that.

We haven't been getting any.

Well, we've gotten support cases.

But they've been blank.

Every. Single. One.

But there's a good reason for that too. You see, the form that submits the support ticket sends the data to an API that expects the data in a subtly different format than it recieves it in. So, after a 2 minute bug fix everything works again. A bug caused by a series of typos. Simple to fix, hard to catch. The web team has decided to write more functional tests.

If you submitted a support request to us through the www.ncover.com/support/ticket page in the last month, we apologize, but we didn't get it. If you care to re-submit the ticket we will be more than happy to give it top priority and make sure it gets taken care of as soon as possible.

If you submitted a support request to us through the support@ncover.com email however, we did receive the request and responded to it with our usual alacrity. You can always submit support questions to us through the support@ncover.com address.

Craig's evil spawn brings CC.net integration goodness

Daniel Waldschmidt — Tue, 09 Jun 2009 02:35:00 GMT

Short on time to publishing his own autobiography, Craig Sutherland devoted his effort to sharing step-by-step integration help for the "every man" using the Cruise Control continuous integration server.

Like he's crafting a beautiful piece of artwork, Craig brings together NCover 3.1 features with the future of continuous integration goodness we call Cruise Control...

A new design, a refreshed focus.

Ethan Mullis — Wed, 03 Jun 2009 09:00:00 GMT

We've been getting lots of compliments and questions about the new NCover website (who designed it, who wrote the copy, etc.) and I wanted to share with you our mindset behind the redesign, and a little bit of insight into how we work. First though, I'd like to thank everyone who has sent us a message about the new site. It feels great knowing that our work has been appreciated, and that the site is more informative than ever.

The new site was designed internally by the web team at Gnoso, NCover's parent company, with input and content from the entire NCover team. We started out with meetings about where we saw NCover as a product, what we really stood for, and how we could better inform our customers. It soon became obvious that NCover is about more than just code coverage, it's about something much bigger, and that's code quality. Once we knew what we stood for, we started making a list of what the site needed to accomplish:

Make a bold stand about who we are and what we care about.
Show off what we actually do/make.
Be concise and to the point. Don't waste time on marketing jargon.
Be clear about how potential users can get started.
Educate our uses with more documentation and learning content.

Having this list in mind made it easier to decide if a design element should stay or go. It focused all of the copy that was being written for the site, and it made clear what could be cut and what was a must have item.

The next step was to actually start designing and I had a blast laying out the entire site. Originally we tried to put new content on top of our old site design, but it became clear that a complete redesign was in order. This was a perfect opportunity to refocus our messaging, get back to our roots, and really show off all of the features NCover has to offer. Large text, big buttons, and an interactive screen shot, really helped the homepage come to life and drive our message home. We also added a brand new "Products" page that dives deep into what versions we offer, an interactive diagram that shows how NCover fits into your organization, and a vibrant list of NCover's top features. Previously, our documentation was buried inside of our support section, but now the "Learn" section acts as a central hub for all the information you need to get going with NCover. With the inclusion of site search, a login tab, improved support ticket submission, and a host of other improvements, we've made ncover.com a more useable site.

NCover v3.1.2 released!

Stephen Ward — Mon, 01 Jun 2009 13:09:00 GMT

Download the new version here.

We had a few issues with the first installer. If you run into any issues, please make sure you are running v3.1.2.5168 or download the latest version here.

Features and Improvements

Added branch point count (total / unvisited) to the html report header.
The //ias and //eas arguments now correctly handle fully-qualified filenames, e.g. "C:\development\project\debug\program.exe".

Changes

Two messages in the NCover log that were reported as ERRORs are now reported as MESSAGEs, since in their common case they are not ERRORs. The ERROR case for both is reported as an error.

Bug Fixes

Could orphan the NCover process by closing NCover Explorer while NCover was running.
Fixed inaccurate documentation.
Fixed a bug in Assembly filter matching that required a trailing '*' or '.*' to match an assembly.
NCoverExplorer.Console.exe wasn't correctly stripping xml report files to the bare minimum amount of data.
Fixed the xsl file used to transform xml reports into html reports. It would not work when the //rdf argument was used.
Fixed the xsl file so that the MethodModule and MethodModuleNamespace reports reported functional not symbol data.
Covering IIS or a windows service from NCover Explorer would cause an exception.
Trend graphs in the trend report now show in IE8.
Fixed javascript errors in the SummaryReport and FullCoverageReport.

The TWEETS have spoken.... and we have heard you.

Daniel Waldschmidt — Thu, 28 May 2009 08:21:00 GMT

I couldn't help but take a quick search through Twitter for what you are saying about NCover -- especially after the rapid fire release of 3.1 a few days ago.

Certainly GraemeF seems to believe that we are indeed developing NCover.

Let me put this rumor to rest. We are developing code quality solutions like mad men and <secret> we are planning sweet integration with the latest Visual Studio 2010 WPF IDE "goodness" Microsoft is delivering. Expect big things. Suggest big things...

Certainly Shane is jazzed about TestDriven.net and NCover working together to produce method-level quality analysis.

We agree that TD.net is a "must buy" and so is NCover. Take two or three with you to share with your buddies.

Certainly Ruby_Gem loves how NCover magically creates unit tests for her. Did I hear something about a special exercise program?

Absolutely, Ruby, we will be doing the code pilates right beside you. You must have had a look at our secret plans for world domination. It is amazing how the idea of testing becomes a lot easier with the right tools.

Certainly Kkozmic has an opinion on how NCover compares to the rest of the code quality tools on the planet (perhaps even the universe).

Well, I happen to agree with out friend Kkozmic. We do claim to "fly like a butterfly, sting like a bee". And in all seriousness, we do work hard to keep pushing out features and a quality product.

Last, but certainly never least important, I leave you with our Confucius thought of the day from PaulLiebrand.

Certainly PaulLiebrand asks the right question: "Do you love NCover? Anybody using this thing? Tell me your experience..."

I re-blog-tweet his thought and counter with an invitation to hear our CEO talk code quality with the zen-masters from Innerworkings. Bring your twriends with you...

Your software stinks. I should sue you...

Daniel Waldschmidt — Wed, 20 May 2009 18:35:00 GMT

Throw out the models that show how expensive it is to let bugs make it into product deployment. Bugs are expensive, but they just might cost you even more in the coming months. Recent frustration with software quality has led the European Commission, to consider making software creators liable (i.e. getting sued) for writing bad code.

That's right.... The cost of bugs just went up. CNet broke the story about a week ago and since then the blogosphere has exploded with comments, frustrations, and insight into the possibility that software companies might have to suffer more than just an angry customer or a public flaming:

"A priority area for possible EU action is 'extending the principles of consumer protection rules to cover licensing agreements of products like software downloaded for virus protection, games, or other licensed content,' according to the commissioners' agenda. 'Licensing should guarantee consumers the same basic rights as when they purchase a good: the right to get a product that works with fair commercial conditions.'

EU consumer commissioner Meglena Kuneva said that more accountability for software makers, and for companies providing digital services, would lead to greater consumer choice."

Certainly any such advocacy has to expect to encounter massive international resistance. It would seem that applying Underwriter’s Laboratory approval to simple software ideas would prove to be overly burdensome for creative software developers. Great ideas might not survive the day!

Further, I have doubts about the feasibility of assessing “actual” and punitive damages as a result of software quality. Proving a direct connection would likely be expensive and ultimately unfulfilling especially damages were to the collected.

Regardless of our feelings on the subjects, the winds of change are blowing. Consumers want their software to work right and they are pushing their dissatisfaction to new limits. Software quality just became a bigger priority for all of us.

Read the full article here: http://news.cnet.com/8301-1001_3-10237212-92.html?tag=newsEditorsPicksArea.0

NCover v3.1 unveiled! Bad code flees!

Joe Feser — Wed, 13 May 2009 22:16:00 GMT

Joe and Steve, our lead developers, and the entire NCover team are pleased to announce that we have released NCover v3.1 today. We listened to a ton of great feedback from the community about our v3.0 platform and went to work to make the leading .NET code coverage platform EVEN BETTER. Thanks for your help! A new key is not required if you are upgrading from NCover v3.0; just download, install and run.

You will already notice the new website that Ethan, Kevin and Alan spun up. We hope you like it as much as we do. Check it all out: better access to answers, better videos to get you started, and better navigation.

Take a moment to check out our partners, linked at the bottom of the page, while you download v3.1. Check back over the next few days as Joe will be working on explaining his new "diff" and trending reports that are part of this release. Until then, here is everything you wanted to know about the new product release:

Features and Improvements

Added Trend Reporting
Added Difference Report (The "Diff")
Added new //xslt flag which allows for loading of a custom xslt file for the reports.
Added new //literal flag allowing you to ignore the corrections we make when covering child processes using MSBuild and Gallio.
Acceptable Branch Percentage is now supported in the IDE and in all reports except FullCoverageReport.
Acceptable Cyclomatic Complexity is now supported in the IDE and in all reports except FullCoverageReport.
Added the ability to toggle if we should ignore failed builds in the Trend graph.
Added the ability to sync the coverage file exclusions back to the project (on by default).
Added the ability for the //cr to be specified multiple times from the ncover.reporting command line.
Updated the text and visuals on the RebasedSourceWindow depending whether it is looking for a missing or an out of date file.
You are now able to click on Project split button to load project options instead of using the "Manage Options" button.
You are now able to click on Coverage split button to load coverage file options instead of using the "Manage Options" button.

Changes

Module is now called assembly everywhere.
Sequence Points are now called Symbols.
Sample code now contains a link on the program menu.
Arguments appearing after a config-read statement now override settings in the config file, instead of being ignored.
Updated documentation to refer to //or instead of deprecated arguments.

Bug Fixes

The //at flag on the NCover.Console command line would create an exception if the file didn't exist.
If //h was used, NCover.Console ignored it and output the report to the current directory instead.
Bugs with the //sct flag.
Fixed bug where sct view options were not being placed on the view. We now add the view level items to the view first and everything will inherit from it correctly.
The FullCoverageReport now treats arguments from the //op and //or parameters as directories, like the documentation says it does and like 3.0.18 did.
The FullCoverageReport now clears out the files\ sub-folder if it exists when a report is created.
The algorithm that merged modules together as they came out of shared memory was merging instrumented points based solely on the offset, when it should have been merging based on offset and the type of point (symbol, branch, etc).
The type name of the CyclomaticComplexity object was being displayed instead of the maximum value when an object failed a CC threshold.
Fixed bug where we were showing "load trends" on the trend graph when a trend file was loaded in the graph.
Update the graph if you change the report style
Added missing MergeFilterMode for MSBuild and NAnt task items
Fix bug where if the list was less than the max fail to show, the entire list would be displayed. We now correctly limit the list to the max you tell us to use.
When the Rebase Source Window was launched from the search pane, it would throw an exception when it closed.
If a missing source file was 'ignored' by the user, NCE wouldn't load it, but the next time they clicked on the class NCE would ask them to locate the 'ignored' file.
If multiple classes were in the same missing source file and the user 'ignored' the first request, NCE would ask the user to locate the missing source file once for each other class in the source file.
Assemblies were not being filtered correctly due to the fact the name was fully qualified, including the version metadata. You no longer have to use a trailing * for the filters to work correctly.

How to opt-out of NCover's customer improvement data reporting program

Stephen Ward — Wed, 08 Apr 2009 16:14:00 GMT

NCover 3.0.20 includes a customer improvement data reporting feature that reports memory and performance statistics to us whenever NCover.Console, NCover.Reporting, or NCover Explorer is run.

To opt out of our customer improvement reporting for any one of the programs above, open the <executable>.config file for the program, find the <appsettings /> section, and change

< add key="customerfeedbackoptout" value="0"/>

< add key="customerfeedbackoptout" value="1"/>

Example: Opting out of data reporting for NCover.Console.exe

Open NCover's installation directory ("C:\Program Files\NCover\", don't forget that NCover (x86) is installed in "C:\Program Files (x86)\NCover\" on 64-bit machines, and that it's config file will have to be changed as well.
Find and open in a text editor the "NCover.Console.exe.config" file.
Locate the <appsettings /> area in the file.
Find the "customerfeedbackoptout" key
Change the value to "1" (from "0")
Save and close the file

NCover's customer improvement data reporting feature is powered by PreEmptive Solutions' Runtime Intelligence™.

NCover v3.0.20 released!

Stephen Ward — Wed, 08 Apr 2009 15:46:00 GMT

We are pleased to announce the release of NCover 3.0.20! This release includes many bug fixes and several new features that we've spent a long time crafting to make using NCover easier and simpler. If you're creating a lot of reports you'll especially appreciate the new //or argument in NCover.Reporting that lets you create multiple reports without re-processing your coverage files.

Also new in this version is our customer improvement data collection feature. NCover.Console, NCover.Reporting, and NCover Explorer all gather anonymous memory and performance statistics while they run and report that data to us so we can know how NCover performs in the wild and address problems before they are problems. The data collection program is opt-out, and another blog post will explain how to opt-out of the process for now.

Features and Improvements

Allow for unlimited number of reports to be created using the //or flag.
Added new //mfm argument to NCover.Reporting to permit different merge behaviors when merging coverage files.
Decreased memory usage when merging coverage files by 30-40%.
Added MethodModule and MethodModuleNamespace reports to the Complete edition.
Added new sample console application and getting started guide to demonstrate how to perform code coverage on a console application.
Added new NUnit sample application and getting started guide to demonstrate how to perform code coverage using NUnit.
Added new WPF sample application and getting started guide to demonstrate how to collect code coverage on a windows application.
Added new MSBuild and MSTest sample application and getting started guide to demonstrate how to use NCover with MSTest and MSBuild.

Changes

Changed merging to allow you to reproduce the merge behavior of NCover 2.1. See the new //mfm argument documentation.
Deprecated the //r and //rf arguments. These arguments are now combined in the //or argument. Functionality will still be available until NCover 4 ships.

Bug Fixes

Fixed state problems in NCover Explorer that prevented NCover from covering IIS or services.
Fixed bug with assembly filters. The value was fully qualified and not the assembly name. You will no longer need to add .* to the end of the Regex.
Fixed bug with assembly thresholds containing patterns. Also fixed an issue with the assembly name being fully qualified.
Fixed incorrect output being displayed when NCover classic when attempting to use a Complete report.
Fixed bug for smaller reports written to the same location of a larger report did not truncate correctly.
Fixed bug on the filters screen.
NCover Explorer is more responsive when displaying output from the covered application.

We help you cover your code, help us cover our documents

Peter Waldschmidt — Fri, 20 Mar 2009 22:00:00 GMT

Here at NCover, we are constantly trying to figure out ways to make it easier for the development community to understand and use our products. Part of that experience is documentation and training. We are looking to improve our documentation, and create other educational resources that will help our user community to write better quality code. That’s where you come in. We need help.

We are looking for a couple of sharp, passionate developers who like to share their knowledge with others by writing. You don’t even need to become an employee here at NCover. If you can help us by writing in your spare time, we would greatly appreciate your help and you could make some money on the side as well. If you are interested in writing for the NCover team, please contact us at conversation@ncover.com. Send some examples of work you’ve written before, or point us to blog posts that you’ve written.

NCover v3.0.18 Released!

Joe Feser — Tue, 10 Mar 2009 19:27:00 GMT

We are pleased to announce that v3.0.18 of NCover is officially released. The biggest change is in the handling of source filesthat belong to multiple assemblies. How does this happen? One way this can happen is if you have v1.0.1 and v1.0.2 in your coverage file. Unless you branched your code, the source file's path will be the same. Another way this will happen is if you "Link" your source files into multiple projects. We are telling you about this change in case you are post processing the file and expect the url to be unique. Old coverage and trend files will continue to work in NCover Explorer and NCover Reporting.

Features and Improvements

Documents are now per module. This will allow you to obtain coverage for multiple versions of the same assembly and for linked source files
30% increase in performance for merges that contain many filters

Changes

We no longer show 100% covered for items with no points in the stats pane. It is now displayed as N/A
Fixed localization issues with the Cyclomatic Complexity statistic in trend and coverage files by changing the field seperator to a semi-colon (it was a comma)
Documents are now per module which means their URL may be duplicated in the coverage and trend file (but they're still unique by ID, and are unique by URL and module ID as well)
Coverage for a single assembly is now merged across all application domains it was loaded into, which gives a more accurate coverage statistic. Before, coverage for the assembly was reported once per application domain it was loaded into, giving multiple instance of the same assembly in the coverage data, some with really low coverage and some with really high coverage
When NCover is running, only the "Output View" and "Trend Pane" buttons and the help tab are enabled
The Registration program no longer requires administrative credentials in order to run
CC.NET reports incorrectly displayed the acceptable coverage threshold for methods.
Branch Point coverage thresholds are not correctly support in NCover Reporting

Bug Fixes

It was possible to open a recent coverage or project file while NCover was running
Fixed issue with Typemock Integration
Fixed issues with TD.NET Integration. v2.19+ of TD.NET is required
Fixed issue with NDepend v2.11.2 reading NCover 3 coverage files
Merging wasn't keeping the source filters from the original/first view
Statistics for nested classes are now calculated correctly in the reports and tree view control
The registration program now launches after the install is complete
The 32 bit installer will now install without registration problems on 64 bit systems

NCover v3.0.15 Released!

Stephen Ward — Thu, 19 Feb 2009 15:41:00 GMT

Features and Improvements

Up to 6x less memory use when creating the FullCoverageReport.
33% speedup when creating the FullCoverageReport.

Changes

Updated the NCoverReporting30.xsl file to work with CC.NET by default. Consult the updated documentation and this blog entry to set up CC.NET with the new xsl.

Bug Fixes

NCover.Reporting now recovers from invalid regular expressions and prints an error message.
Fixed null references exceptions that could happen when creating a FullCoverageReport with trends when there were holes in the trend data.
Fixed misc. errors in the documentation.
The "Script Helper" button in NCover Explorer is now enabled when no coverage file is open.

How to verify your CC.NET report file and optionally send a good support request

Joe Feser — Wed, 18 Feb 2009 21:47:00 GMT

A few customers are reporting integration issues with CC.NET v1.4+ and NCover v3.0. Our last blog post addressed the issue with the graph images not displaying correctly. This blog post is going to expand on the other integration issue that people are experiencing, which is the report showing N/A and NAN% for the coverage percentages.

The first thing you need to do is look at the url for the report. An example url would look like this

http://server/ccnet/server/local/project/NCover+Tests/build/log20090218054153Lbuild.2.xml/NCoverBuildReport.aspx. You want to look at the part right after /build/, in our case “log20090218054153Lbuild.2.xml”, this is the artifact that is being transformed using the NCover3XmlReport.xsl file.

In order to determine the location of this file, look in your ccnet.config file for the following tag for your project: <artifactDirectory>D:\ccnet\artifacts\ncover3</artifactDirectory>

This is the folder that will contain the artifact. Open this file in a text editor and you should notice the root node should look something like this: <cruisecontrol project="NCover Tests">

Under this node, you may see a tag called “buildresults”

<buildresults>
  <message>NCover Reporting Complete v3.0.14 x86 (Administrator)</message>
  <message>Merging and Reporting for NCover</message>
  <message>Copyright (c) 2007 - 2009 Gnoso Inc.</message>
  <message>http://www.ncover.com</message>
  <message>Wrote xml report to 'D:\ccnet\artifacts\ncover3\symmarymodule.xml'</message>
  <message>Execution Time: 3,453 ms</message>
</buildresults>

This is the output that came from ncover.reporting.exe during the run process. The next section you should see is the information used for the transformation

<trendcoveragedata xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <en>::coverage.xml::</en>
  <stats acp="95" afp="80" ccavg="2.44" ccmax="106" ex="0" ei="1" cc="2.44,106" ubp="8098" udp="0" ul="11485" um="3036" usp="11156" vbp="8503" vdp="0" vl="10667" vsp="10738" mvc="30211284" vc="1" vm="3897" svc="401794353" />

If you do not have the <trendcoveragedata> node in your artifact, there is an error in your ccnet.config file, please read the readme.txt file or this following url. If all of this information exists, and your <trendcoveragedata> contains at least one <doc> element and one or more <mod> elements, then you should contact support (http://www.ncover.com/support/ticket) to see if we can help you once you verify the following items. 1. If you are receiving NAN% or N/A% for Symbol coverage, first verify that at least one of the <stats> nodes has non-zero values for the usp and vsp attributes. If all of the vsp and usp attributes are 0 (zero), the PDB symbols were not available at the time you ran coverage. The vl and ul (visited lines and unvisited lines) will also be 0 if PDB symbols were not available. 2. If you are receiving N/A for Cyclomatic Complexity, verify that the ccavg and ccmax numbers are not 0. If they are and you are running the Complete edition of NCover, you may have not included Cyclomatic Complexity coverage when you ran coverage. Please verify your options for the //ct flag. By default we capture all of the information allowed by your edition. If you passed in flags, you have limited the data that we are going to collect.

My images do not show up in CC.NET what do I do?

Joe Feser — Wed, 18 Feb 2009 19:40:00 GMT

There has been some confusion as to why the images are not showing up in the cc.net dashboard. A few people have made specific changes to the xslt file to resolve the issue. The underlying issue is the CC.NET path for the dashboard does not map to an actual path on the file system. Using Firebug, we determined the actual issue was the server is returning an HTTP 500 due to the fact that the relative path does not exist on the server.

In order to resolve the confusion, we have modified the xslt file to handle CC.NET out of the box. By following these few steps, you will be up and running in under five minutes.

By default, cc.net is installed in the "C:\Program Files\CruiseControl.NET" folder. Inside that folder, you will find a folder called webdashboard. This folder maps to the ccnet virtual web that is created when you install cc.net. Three images are released with NCover, r.png, g.png, and y.png, these files are located in the "C:\Program Files\NCover\CC.Net" folder. If you copy these three files to the "C:\Program Files\CruiseControl.NET\webdashboard\images" folder, and replace the NCoverReporting30.xsl in the "C:\Program Files\CruiseControl.NET\webdashboard\xsl" folder, your images will begin to appear. If you are using the email report feature of cc.net, you will also need to replace the file located at "C:\Program Files\CruiseControl.NET\server\xsl".

If by some chance, you do not want to place the images in that folder, you will need to modify the xslt file to match the path you have placed the images. This can be done by modifying the "baseimagepath" variable in the xslt file

<xsl:variable name="baseimagepath" xml:space="preserve"><xsl:choose>
               <xsl:when test="not($fulltags)">/ccnet/images/</xsl:when>
               <xsl:otherwise></xsl:otherwise></xsl:choose></xsl:variable>

All you need to do is change the path located in the when condition with an absolute path of your choice. This is a web path and not a file path. It is also absolute from the root of the cc.net server (webdashboard). Your install may not be on the C drive, it may be D, E... The easiest way to determine the install path of CC.NET is to go to the Internet Information Server Manager, find the CC.NET virtual directory and right click the item and go to the Home Directory tab. Please consult your Windows help file or system admin if you are having trouble determining the root location. You can also use the iisweb /query option on the command line. Choose yes if it asks you to register the cscript.


C:\>iisweb /query
Connecting to server ...Done.
Site Name (Metabase Path)               Status  IP              Port  Host
=========================================================================
Default Web Site (W3SVC/1)              STARTED ALL             80    N/A
Microsoft SharePoint Admin    (W3SVC/2) STARTED ALL             7617  N/A

Find the name of the default web site or the name of the website that cc.net is installed. In our case it is W3SVC/1


C:\>iisvdir /query "W3SVC/1"
Connecting to server ...Done.
Alias                        Physical Root
========================================================================
/_vti_bin                    C:\Program Files\...\isapi
/CCNET                       C:\Program Files\CruiseControl.NET\webdashboard\
/ServiceModelSamples         C:\inetpub\wwwroot\...

This xslt is part of the v3.0.15 release (or later) which is available on the download page. If you would like us to send you a copy of the file instead, please email support@ncover.com.

"Early Bird" Enhancements Make NCover v3.0.13 Faster!

Joe Feser — Tue, 10 Feb 2009 19:26:00 GMT

We continue to listen to our customers suggestions and we are proud to provide you with our latest release. One of the biggest requests from our customers was the ability to disable highlighting the language keywords (public, sub, int), and v3.0.13 provides you with this option. The option is located under "Managed options" in the "Other Options" section. Check the "Disable Source Code Syntax Highlighting option" and all new opened files will no longer provide syntax highlighting. Your covered and uncovered code will continue to be highlighted.

Recent security changes to our application require you to download the latest version. All existing versions will expire on February 14, 2009.

BETA Security Removed

Inclusion of beta security protocol in release candidate requires removal of v3.0.11 and download and installation of v3.0.13.

Features and Improvements

//CCF and //RDF Flags are now supported in the MSBuild and NAnt Tasks.
All out of sync files will now display the line number highlighted.
Performance improvements in the source code tab when changing themes.
Added the ability to disable keyword syntax highlighting in the code preview.
Trends are now normalized and will show as missing data on the graph. This will provide much greater insight over items that have been added, removed or failed.
Improved readability of plot points for very large data sets. The intersect points will now scale to size, keeping the points from overlapping.

Bug Fixes

Fixed issue with out of sync documents. We now highlight the line number that we know is out of sync
Multi line symbols no longer report out of sync on empty lines.
Warn If missing source code would not provide a way to show the source file if cancel was chosen.
Rebase Paths dialog would blow up if you caused a circular replacement (point the replacement path to the same bad file).
Failed builds no longer show up in the trend graph.
Fixed issue with nested classes not displaying the correct coverage percentage.
Fixed a node state issue for nested classes.

Changes

Failed builds no longer show up in trend graph.

Download Now

The Battle on Bad Code Continues

Daniel Waldschmidt — Fri, 06 Feb 2009 00:53:00 GMT

Today, Kathy Richards from Redmond Developer writes about how we fill a nice partnership position with Microsoft Visual Studio in the growing role of code quality analytics:

Earlier this week, NCover, a .NET specialist in code coverage analysis, released version 3 of its flagship product -- available in a community edition and the more advanced commercial products. Code coverage, often employed in Agile and test-driven development, makes sure the test cases touch all of the code by measuring how many times each line of code is executed. NCover version 3 improves coverage loading performance, according to the company, and adds new metrics such as cyclomatic complexity and method visit coverage.

http://reddevnews.com/blogs/weblog.aspx?blog=3426

Laurent Kempe takes the first dance...

Daniel Waldschmidt — Wed, 04 Feb 2009 22:36:00 GMT

"Ask and ye shall receive...." sayeth the gospel of NCover.

And Laurent asked...

If you don't know Laurent Kempe, then go meet him... He's "one of the TechHead Brothers", a bad-ass techie, and the first official licensee of NCover Complete.

http://weblogs.asp.net/lkempe/

Everyone not named Laurent: "YOUR CODE'S ARE ON THE WAY!

It all went down on Twitter

The Twitter Trailing Thoughts @DanWaldo Ok now I see what you were talking about with WPF! Really nice, let's try it! It is late here, I think I will be late to bed! @DanWaldo Yeah ! Saw it and just registered! First to Get license for NCover 3 :) Champagne :)

Aliens Have Landed?

Daniel Waldschmidt — Wed, 04 Feb 2009 16:54:00 GMT

It started late last night and ended early this morning... and will change every day from here on out. With plenty of hype and a sexy new redesign, our international clients already started snapping up licenses 30 minutes after the new product launched.

And so the madness begins.... (and not without reason)

We call it NCover Complete!

David Worthington at SD Times summed it up nicely with his article about us:

Code coverage tool digs deeper into .NET analysis By David Worthington

February 3, 2009 — Gnoso, a code coverage tool maker, has updated its NCover code analysis tool with broader analytics and new reporting capabilities that help development managers assess .NET code quality.

NCover Complete 3.0, released yesterday, has several more coverage points, including branch coverage, cyclomatic complexity (or conditional complexity), and method visits, said Daniel Waldschmidt, Gnoso's Technology Evangelist for code coverage tools.

With this data, NCover can create trend data from its coverage files and can automate coverage from within Microsoft Visual Studio Team Foundation Server. It is also interoperable with other code coverage tools, including Bullseye for native code and Clover for Java, said Waldschmidt.

Additionally, NCover's command line utility is now able to perform over 30 different activities, Waldschmidt added.

"Customers can create a workflow that takes .NET assemblies and passes them through NCover and other feedback loops," he said.

A greater variety of code quality reports can now be created. Previous versions produced only a single report for managers; NCover 3.0 produces over 22 reports, such as a build's 20 most uncovered methods and its five most complex assemblies, Waldschmidt noted.

It's more than than the future of software development -- it's the dawning of a better methodology. This means safer software for consumers and the ability for big business to make products MORE profitable. And that's only the start.

Gotta go, my phone's ringing.

NCover 3 RC1 is now available

Joe Feser — Tue, 27 Jan 2009 19:28:00 GMT

Features and improvements

Added ability to show / hide excluded nodes in the tree view. The default behavior is to remove the nodes from the treeview when they become excluded. You may change this option by right clicking on the treeview and selecting "Show excluded nodes", or you may also go to the "Project Options" and check "Show Excluded Nodes" checkbox located under the project name.
Managed C++ now highlights properly.
Serialization exceptions (caused by passing the wrong file to various places) are now handled and display an explicit error message.
When a project is loaded, there is now an option in the application options to load the last coverage data file that was opened w/ that project
Tweaked functionality of the "Filters" screen in the Project options and the Coverage View options
The registration program now lets you specify a proxy server
Default theme for 0% coverage nodes is now red text.

Bug Fixes

Fixed some trend bugs. Trends were running in Professional mode, removing all of the Cyclomatic complexity and branch point information. Any Trend file that was used with v3.0.9 should be discarded unless you need those metrics.
Visit count tooltips in the source file viewer wouldn't display under certain circumstances.
Source code wasn't highlighting with the color in the theme.
Sidebar titles in the Full Coverage Report were double html-escaped.
Fixed sorting in the Full Coverage Report sidebars.
Fixed sorting in the Full Coverage Report main pages.
When run on a non-english OS, NCover's help links didn't work.
Excluding a property in the tree view now works.
Excluding nodes under certain circumstances would cause NCover Explorer to crash.
Excluding a class now properly excludes all inner classes. This is supported in the treeview and in the reports.
The NCover command line generated by NCover Explorer in the "Generate" window wasn't handling empty include / exclude lists properly.
The "Filters" screen wasn't handling wildcards
Using a wildcard or regex filter would add extra filters to the collection -- one for each element that was excluded.
Trying to open a corrupted or non-existent coverage data file no longer crashes NCover Explorer.

Changes

NCover now removes elements that have no coverage data from the xml coverage file before the file is persisted to disk.
Deprecated the "Satisfactory unvisited Seq. Pts." fields in the Project options and the coverage view options (the field is no longer available).
Deprecated the "Additional Arguments" field in the Project options (the fields is no longer available).
"Print" and "Print Preview" are no longer supported and have been deprecated (last working version was in 2.1.2).

Download the latest release here

NCover v3.0.9 beta is now available

Stephen Ward — Tue, 20 Jan 2009 18:46:00 GMT

Features and Improvements

Sped up processing of filters. Roughly 2x faster when filtering source files.
The window that reports errors now has an email field, in case NCover was not bought by whoever is using it.
When the reporting tool doesn't understand its command line, it now displays the command line it was given and its help.
Redesigned the source code control. Roughly 1.5x faster.
Added support for v2.1 reports back into the reporting tool. Sped up processing 1.5x, and load times (into a browser) roughly 5x for large (10+ megs) files.
Fully implemented CC.NET Support.
Added 16 new xml/html reports.

Changes

Dragging and dropping a coverage file into NCover Explorer just opens the file if coverage isn't already loaded.
"ShowExcluded" items in report footers was removed.
The ServiceTimeout (//st) NCover argument now interprets its parameter as the number of minutes to wait, not the number of seconds.

Bug Fixes

Fixed an exception that was caused when certain nodes in the tree view were selected.
Fixed lockups in the NCover Explorer gui when loading large coverage files (90+ megs).
IIS and Services now respond to the "Wait for App Load" (//wal) argument.
Excluding documents yielded incorrect coverage stats under some configurations.
Closing NCover Explorer w/ the [X] in the upper-right corner could wipe configuration information in some circumstances.
Opening a project would ask to save the prior project twice.
Exceptions were reported twice.
Fixed various exceptions that were caused by relative paths to coverage files, trend files, log files, etc.
Fixed an exception (in NCE) that happened when NCover doesn't create a coverage file.
"Remove Selected Filter" button was removing all of the filters.
Fixed incorrect license violation messages that were triggered by an empty HtmlReportDir.
If the "Working Directory" option in NCover Explorer project settings pointed to a directory that did not contain NCover.Console.exe, NCover was unable to run.

Known issues

Trend support is running in a semi locked down state and it will remove your branch and cyclomatic data when you append a new file. Back up your trend file before using v3.0.9. This will be fixed in v3.0.10.
Changing your paths from very large names to very short names or removing settings may damage the file when using the //cs switch. There are cases where the length is not truncated, causing a malformed xml document. This will be fixed in v3.0.10.
Opening a project does not load the last known coverage file. This will be fixed in v3.0.10.

Download the latest Beta release here

NCover v3.0.8 run coverage exception workaround

Joe Feser — Mon, 05 Jan 2009 15:45:00 GMT

A few users have reported the following issue: After running coverage, the application tosses an exception and the application exits. The temporary workaround for this issue is to fully qualify your coverage xml file. This is located in the Project Options on the "Output options tab". Change the "Filename for coverage" to be fully qualified instead of the default (coverage.xml). Once you make this change, the application will no longer crash after running coverage.

We will be releasing a fix for this issue in the next release of NCover.

NCover v3.0.8 is now available

Joe Feser — Thu, 04 Dec 2008 14:04:00 GMT

We are pleased to announce the newest release of NCover 3. The coolest feature of this new release is the ability to read Team Foundation Server code coverage files. TFS files may be loaded and viewed in NCover Explorer and you may also create trend files.

Features

Added TFS Coverage file support. You may now load and trend TFS 2008 and 2010 code coverage files.

Changes

Removed Save and Load buttons from the "Project Options" and "Options" windows. Any changes made are immediatly effective.
Changed Window graphic on the main window to the usual NCoverExplorer graphic (a magnifying glass and the NCover logo)
Added extra info to the title of the Main window -- 32 vs. 64 bit, and whether the executing user is an administrator
New Trend graph now shows Sequence and Branch points at the same time. The scaling issues have also been fixed. Each x-axis tick is one "run"
Maximum visit count is now stored in the trend file. The existing "vc" attribute is still the minimum visit count
Coverage files and trends now include a "failed" flag and will be set to true if the tests return an error code
Changed binding on satisfactory coverage slider bars to lost focus to fix performance issues with large coverage files
We now display a message as we load a trend file so the user knows when the process is complete

Bug Fixes

After selecting a node that does not have trend data (e.g. a property node), selecting a node that does have trend data will not show the trend data. The trend data will show if the application is resized.
Fixed font size issues in the tree view when upgrading from NCover v2.1 to NCover v3.0
Fixed various sizing problems in the stats pane
Fixed a problem with generating trends and adding them to an html report via NCover.Reporting.exe
Fixed various usability problems with the exception dialog. Describing the error should be much easier now
Fixed various usability and sizing problems with the project options and application options windows.
The x86 version of NCover Explorer is now correctly named as NCover.Explorer.exe
Add Included/Excluded assemblies now starts in the working folder when opened
Cyclomatic Complexity trends now display correctly
Trends now combine all versions of the same dll into the graph. This will allow all of the trends for an assembly to be displayed
Trends are now shown for properties
Trend file now correctly calculated method visits and visit count for documents
Trends now property display correctly for duplicate namespaces, types and methods across assemblies

Download the latest Beta release here

NCover v3.0.6 is now available.

Stephen Ward — Wed, 12 Nov 2008 16:35:00 GMT

Features and Improvements

Memory performance issues have been resolved with large coverage files
400% performance gains on coverage percentage exclusions.
Added Exclude Assembly support to the command line //eas
Added full support for TestDriven.NET.
If you pass a coverage file in as the first argument to NCover Explorer, it will load the file
Added option to disable auto reload of coverage file
Added inclusion support for types
Added inclusion support for attributes
Added inclusion support for files

Bug fixes

Assembly Include text box now correctly supports choosing and appending items chosen from the dialog
Trends load after coverage is run, as long as a trend file is specified
After a trend file is loaded, trends for the selected node are displayed
Fixed issue when no working folder was set. After coverage run, an exception was thrown.
The current tree view element now recieves focus when empty space in the treeview is clicked (duplicate v2.1 behavior)
Trend graph resizing issues have been resolved.
Fixed misc. issues with "Do you want to reload coverage file?" popup
Fixed misc. display issues on the "Generate Report" window
Fixed misc. issues with the coverage view tool tip sticking around longer than it should
Stats Pane Symbol Coverage was bound to Unvisited %
Fixed Application Logo, was 16x16.
Cursor has been fixed while running coverage. It is no longer 64x64 pixels
CoverageExclusionType is no longer in the coverage file. This is a calculated field and should not have been persisted.
Binding issues on Project Runtime Exclusions has been fixed
Fixed bug with duplicate rebased paths taking down the application if a duplicate existed
Fixed bug with the find missing source file dialog if the user chooses a new path that still does not contain the source file
Fixed UI design of the Themes design window
Fixed misc. synchronization problems with the Themes window
Include / Exclude item fields now wrap long input and scroll when they run out of room
"Project Name" is now correctly synchronized between coverage files, projects, and run settings
FileOpen dialog for adding application argument to the covered application now defaults to the specified "working directory"

Download the latest Beta release here

NCover v2.1.2 has been released!

Stephen Ward — Wed, 12 Nov 2008 16:31:00 GMT

It's been a long, long time since the release of NCover 2.1, and many minor fixes and improvements were made to that codebase while we were busy working on NCover v3.0. After the team discussed it for awhile, we decided it would be good to release a version that packaged all those fixes into a single install, both as a fitting end to the NCover 2.0 series, and to make the fixes available to the community at large. Barring major problems, this should be the last official release of the NCover v2.x codebase.

These are the improvements made and problems fixed since v2.1 (minor bugs not included):

HTML Report now places the Project name, not the report path in the report header
Non-USA users would fail the Administrative privileges check because of a culture-specific assumption in the checking code.
Feature: //a (include assembly) and //ea (exclude attribute) now support regular expressions
NCover would always save a blank settings file
Reduced the occurance of "No Coverage Gathered" errors by removing a subtle timing bug.
Fixed several exclusion bugs.
Feature: Branch points in excluded documents are now excluded as well
Instrumented point visit counts are now stored as a 64-bit integer, to facilitate very large visit counts
Property nodes can now be excluded by right-clicking on them in the tree view.
fixed several HTML report highlighting problems in the source report.
fixed very rare bug where NCover would corrupt a method name
fixed several bugs around the merging algorithm in NCoverExplorer.
fixed bug with dlls located above the 32-bit boundary
right-click exclusions now exclude property nodes in the tree view.

Special mention: An NCover user, Jason M. Kretz, found some bugs in the NCover xsl provided for CC.NET integration and fixed them himself. Thanks Jason! The updated xsl files are included in v2.1.2

You can download the latest version here.

NCover v3.0.5 Beta is now available

Stephen Ward — Mon, 03 Nov 2008 16:17:00 GMT

Since the NCover Beta launch on 10/22, we've been busily incorporating great user feedback with our own testing to make NCover v3 more robust, improvements to the user experience, and correct unexpected behavior. Remember! If you don't tell us it's wrong, it won't be fixed!

Here is a short list of the items we fixed since the v3.0 Beta release:

Now possible to select coverage, log, and trend files that don't exist.

All textboxes select their text when they receive focus.

Improved integration with Typemock by un-deprecating the //reg argument.

Child windows now pop in front (and stay in front), instead of disappearing behind the main window when they lose focus.

The Full HTML Report now displays after it's created when the appropriate checkbox is selected.

(NCover) Dlls loaded above the 32-bit boundary no longer cause a program crash.

Running coverage without a coverage file open no longer crashes the app

Fixed misc. usability issue in the Error Report window.

The latest trend information now included in reports created from NCover.Reporting

Open source files could sometimes cause a crash when coverage was run.

Problems with selecting and storing the right font size were fixed.

Changes to NCover run options are now detected correctly.

If the NCover output window is closed, it will pop up while NCover is running, and close after NCover is finished.

Fixed multiple file selection in the "Application Arguments" field.

Fixed exclusions for MBUnit and MSTest testing frameworks, and added MbUnit dependencies and an obfuscation tool to the auto-excluded list.

Entering a regex into the exclusion fields (source file exclusions, type exclusions, method exclusions, and assembly exclusions) does not invalidate now!

Fixed HTML report issue for trends. Firefox was ignoring the last trend data point.

Lightened the HTML trend graph lines to fix issues when trend data was always 0 or 100%.

Download the latest Beta release here

NCover 3.0.2 Beta is now available

Joe Feser — Thu, 23 Oct 2008 21:02:00 GMT

The feedback is pouring in and we have released an even more stable version of NCover 3 beta. After watching “My Own Worst Enemy” this week, I sat back and wondered how we could “cover” the build person. ;) With that chip embedded, we would have been able to remove the snafu that occurred with our deployment today. Thanks for all the great feedback and keep it flowing. Download the latest release here.

NCover 3.0.1 Beta is now available

Joe Feser — Thu, 23 Oct 2008 13:44:00 GMT

We have released a new beta installer to fix an issue with NCover Exlorer. If you downloaded the original v3.0.0 release, please download the latest here.

Announcing the NCover 3 Beta Program

Joe Feser — Wed, 22 Oct 2008 21:35:00 GMT

We haven't slept a wink since we shipped NCover 2.1 a few months ago and now we're ready to give you a sneak preview of NCOVER 3.0 BETA 1. We can't wait to hear what you think about it...

We listened to your feedback and tried to squeeze in as many of your ideas as possible in this next generation of NCover. Here is the low-down on this BETA 1 release:

NCover Explorer has been built from the ground up in WPF...
New metrics including cyclomatic complexity and method coverage...
Improved HTML reports...
And one of my personal favorites, "trends"...
There's more too... So dive right in and check it out!

Download NCover 3 BETA 1 here.

Nigel Thorne on Upgrading NCover to NCover 2

Alan Johnson — Thu, 19 Jun 2008 20:32:00 GMT

We love hearing about it when NCover helps developers program more efficiently. Nigel Thorne made a blog post about his experiences upgrading from NCover 1 to NCover 2. He especially emphasizes the fact that his automated build process saw almost a 50% speedup.

Read Nigel's post and don't hesitate to let us know about your experiences with NCover either in comments or at support@gnoso.com.

I Cover My Code at TechEd Developers 2008

Alan Johnson — Fri, 30 May 2008 13:06:00 GMT

We'll be handing out "I Cover My Code" swag from our booth at TechEd Developers 2008 (June 3rd - 6th). Come talk to us about what you like and dislike about NCover, ask questions, or just hang out.

Twitter

Alan Johnson — Mon, 19 May 2008 13:19:00 GMT

We're into Twitter here at Gnoso, so we figured we'd set up an NCover account so that people can follow NCover and ask questions in a little bit more informal setting.

You can look us up at http://twitter.com/ncover.>

NDepend v2.8 now supports NCover 2.0 coverage data

Joe Feser — Tue, 29 Apr 2008 00:00:00 GMT

We are pleased to announce that NDepend v.2.8 supports NCover 2.0 coverage files. Using NDepend’s Code Query Language (CQL), you can quickly and easily combine and query your coverage data with all the existing NDepend features including Cyclomatic Complexity and method line count.

You may view a screencast or view additional information.

Gnoso would like to introduce Joe Feser to our team

Joe Feser — Thu, 24 Apr 2008 07:37:00 GMT

Hey everyone, my name is Joe Feser and I am very excited to have started working for Gnoso on March 1st. I relocated from Medina, Ohio to Greenville, South Carolina to work for this amazing company. We were feverishly working on releasing NCover v2.1 during the months of March and April, and are currently developing the next major release of NCover. We want to hear from you, the developer community, of any features or suggestions you have to make NCover even better. Please feel free to email us at support@gnoso.com with your ideas or suggestions. When I am not working on NCover, I enjoy spending time with my wife and three children, cooking and drinking tea.

I also blog at http://blog.joefeser.com and have written articles like Linq to NCover.

Spring Greetings from NCover 2.1.0

Stephen Ward — Fri, 04 Apr 2008 11:53:00 GMT

NCover 2.1.0 is a substantial improvement over NCover 2.0.4. In addition to the normal bug fixes and minor improvements, we've also added several features that should enhance productivity and make NCover and NCoverExplorer easier to use. In addition, we've finally finished testing NCover with .NET 3 and .NET 3.5, and we are proud to say that NCover fully supports both.

You can read the release notes, or download NCover.

Integrating NCover with TeamCity

Alan Johnson — Mon, 31 Mar 2008 07:09:00 GMT

There's a great blog post over on Laurent Kempé's website that outlines how he is integrating NCover into his TeamCity builds. We've been hearing good things about TeamCity, and it's impressive to see how easy it is to integrate NCover into TeamCity builds.

Read Laurent's Post on Integrating NCover with TeamCity

Collecting Coverage on ASP.NET Applications

Alan Johnson — Mon, 25 Feb 2008 11:54:00 GMT

One topic we frequently receive support requests for is usage of the //iis flag for collecting coverage information under IIS with NCover. We just published a new article that describes exactly how to use the //iis flag and how to use Selenium to run automated tests of ASP.NET applications. Let us know if you have any tips for using NCover with ASP.NET in the comments.

Read the Article

Quick Tip: Failing Your Builds Based On Coverage Data

Alan Johnson — Thu, 14 Feb 2008 07:13:00 GMT

In this week's Quick Tip, we walk you through how to get your builds to fail when a certain coverage threshold has not been met with the help of NCoverExplorer.Console.

Watch the Video

Announcing NCover 2.0.4

Alan Johnson — Wed, 13 Feb 2008 13:06:00 GMT

For the past two months, the team at Gnoso has continued to work on new NCover features while supporting our existing users. We uncovered and fixed several problems with branch coverage and some insidious bugs during those support requests, and we are now making those fixes generally available in NCover 2.0.4.

You can read the release notes, or just download NCover 2.0.4.

NCover Basics: Creating a Good Support Ticket

Stephen Ward — Thu, 31 Jan 2008 12:12:00 GMT

Today we added an article to our "How To" section covering what to include in an NCover bug report.

Read "Creating a Good Support Ticket"

New Marketing Campaign

Alan Johnson — Wed, 30 Jan 2008 08:00:00 GMT

Up until recently, we've only marketed NCover through word of mouth and our relationship with our users. That has worked well, but we feel that more developers could benefit from our software, so we decided to release a new advertising campaign. It's important to us that we not only advertise NCover, but also spread knowledge of the benefits of code coverage. While our campaign doesn't directly describe those benefits, we do think it will get coverage on the minds of anyone who views it.

Let us know what you think!

View the Campaign

Quick Tip: Running NCover from Visual Studio

Alan Johnson — Tue, 29 Jan 2008 14:19:00 GMT

We recently added a video to the documentation section of the site that outlines how to run NCover and NUnit within Visual Studio by creating an entry on the Tools menu. Check it out, and let us know if you have techniques for working more efficiently with NCover.

Watch the Video

NCover Basics: Are you Covered?

Alan Johnson — Fri, 25 Jan 2008 08:22:00 GMT

We recently published an article on the Code Project website that covers the basics of NCover and code coverage in general, so felt like it was a perfect fit for the NCover Basics series.

Read "Are you Covered?"

Bullseye Paper On Code Coverage

Alan Johnson — Tue, 22 Jan 2008 07:53:00 GMT

There's a great paper over on the Bullseye website about code coverage analysis. It reviews basic theory behind code coverage, different code coverage metrics, and code coverage best practices. I highly recommend looking it over.

Code Coverage Analysis Paper at Bullseye

NCover Basics: Improving Json.NET's Test Suite with NUnit and NCoverExplorer

Alan Johnson — Fri, 18 Jan 2008 06:12:00 GMT

Over each of the next several weeks we will be releasing an about the basics of using NCover to analyze code quality. We’ve planned to publish articles showing you how to measure code quality with NUnit and NCoverExplorer ,NUnit and NCover.Console, and with ASP.NET, Selenium, and NCover Console, but if you have any requests for additional topics, we’d be more than happy to cover them. Just send us an email at support@ncover.com referencing the NCover Basics Series and the topic you would like covered, and we’ll try our best to cover that topic.

One of the easiest ways to master NCover is simply to dive into some code and improve tests, so this week we’ll be looking at improving the test quality for an open source project, Json.NET, which is available on CodePlex at http://www.codeplex.com/Json. Json.NET is a tool for reading and writing JSON from .NET, and includes a JsonSerializer for easily serializing .NET objects into Json.

New HTML Report Examples

Alan Johnson — Wed, 16 Jan 2008 13:40:00 GMT

Today we updated the site to include some examples of our HTML reports. We included reports for the great Lucene.NET, log4net, and Json.NET libraries.

Example HTML Reports.

NCover 2.0.3 Released Today

Stephen Ward — Fri, 21 Dec 2007 08:39:00 GMT

(Don't read this boring post: go get NCover 2.0.3)

Ever since the release of NCover 2.0.2 in October, we've been working hard (or is that hardly working?) to get NCover 2.0.3 finalized and released. But it wasn't the only project we worked on. Between October and now, we've enhanced the website and started planning NCover 3.0 based on ideas from the community. Somehow we've also managed to cram NCover 2.0.3 with a host of bug fixes, improvements, and minor features, including

NCoverExplorer has added a new "Run NCover now" button to the menu that allows one-click running of NCover with the current options.
The registration program now correctly registers NCover when it is run as a non-administrative user (problem only on Vista).
NCover now responds to Ctrl-C when it is run through NCoverExplorer. (Many thanks to the IIS testers who mentioned this wasn't working.)
Fixed the //reg switch to permit multiple copies of NCover to run in parallel.
Fixed an OutOfMemory exception that sometimes occurred when generating large HTML reports.
Fixed some tricky interop issues regarding NCover and NCoverExplorer projects.
Sped up HTML report generation in NCover.
Fixed highlight color of comments in VB.NET code.
NCoverExplorer now correctly reopens merged reports.
A status window now appears when generating a report in NCoverExplorer. Helpful for those big reports!
NCoverExplorer now correctly sends multiple exclusions to NCover.
Fixed the generation of reports through the MSBuild task.
Fixed misc. issues with displaying out of date and missing source files in NCoverExplorer.
Made some fixes to branch coverage calculations.
Greatly enhanced the speed of profiling extremely large methods (such as those created by code generators).

Website Updates

Alan Johnson — Tue, 27 Nov 2007 13:33:00 GMT

Over the past couple of months we've been working on quite a few site updates, and this morning they went live. Most of the changes were just small tweaks here and there, but we have rolled out brand new forum software and the ability to purchase NCover with your PayPal account.

If you notice any problems with the website or have any comments you would like to make concerning the site, please let us know by commenting to this post or sending us an email at support@gnoso.com.

Hire a Build Server Today

Peter Waldschmidt — Wed, 21 Nov 2007 21:37:27 GMT

Coding Horror has a post titled, "The F5 Key Is Not a Build Process." It references a series of emails chronicled by HackNot as a new employee gets up to speed on a company's build "process."

Anyone who has been a developer for a while has seen aspects of this scenario play out. I can say from experience that having an automated build process makes all the difference. Here are some of the keys to creating a good build process.

Build Musts

<li>Dedicated Build Environment - You need a dedicated server to run your build process.  Under no circumstances should this be a developer's workstation.  The dedicated build environment could be anything from a virtual machine to a build lab full of compilation &amp; testing servers, but it must be dedicated to the purpose.  If possible, this build environment should run your unit tests and functional tests as well.  In several teams that I've been involved with, we've even kicked off the install program and started automated integration testing for each build.</li>
<li>Ship From the Build Environment - Builds that you ship to a customer must originate from the build environment.  In fact, your build server should generate your install package.  This means that you can produce an installable build (at least theoretically) at a moment's notice.  It also means fewer mistakes when shipping to a customer and the result will be predictable.</li>
<li>Regular Builds - Your build process must kick off at predictable intervals.  For large projects, having the process start once or twice a day works well (overnight for example). If possible, you should try continuous integration.  With any of the CruiseControl variants you can set up your build to automatically kick off every time code is added to your repository.</li>

Build Niceties

<li>Predictable Output Versioning - It helps a lot if the output (installer, compiled dll's, etc...) have version numbers that are unique to each build (via an automatically incrementing counter).  This way, there can be no confusion about two builds with the same version number but different functionality.  On one project we even had the least significant part of the version number encode the date and time of the build.  So, we could take a dll from a test machine or customer machine and know what date and time it was compiled.  Since compilation always comes from the source repository and there is only one build environment, we could tell exactly what code made it into that build.</li>
<li>Monotonically Increasing Build Numbers - It helps if the build numbers always increase over time. Sorting by version number will then result in chronological sorting of builds as well.</li>
<li>Automated Integration Testing - With virtual machines and the power of automation tools today, you can set up a build environment that automatically installs your software on a fresh machine, and starts automated integration test scripts, reporting the results back to the development team.  While this can be difficult to set up, it's worth it over the long term.</li>

It's much easier to start a continuous build environment like this when the project is small. Once it gets large, you may never be able to get the time to put together the build infrastructure. Taking some time up front to do it right will pay dividends when you get down to shipping deadlines. Your build server could end up being your best employee.

Quality Code...Specification or Testing?

Peter Waldschmidt — Mon, 29 Oct 2007 14:58:30 GMT

Modern programming environments have come a long way, with powerful development libraries, rapid development frameworks and fancy new language features. But I think the biggest advance in the past ten years has been the widespread adoption of automated testing. In my opinion, there are really two basic ways to produce quality code.

<li><strong>Quality by Specification</strong> - tightly controlling product specification and defining up front as much of the functionality as possible to minimize unknowns and limit project risk.

Quality by Specification focuses on making the definition of the project as stable as possible so that the code-base can settle on a stable configuration and quality assurance staff staff can verify the program against a written definition. By making changes few and predictable, testers can verify the product functionality with a manageable amount of effort.
Pros - The earlier the scope of the project is understood, the easier it is to plan and execute. For line of business applications and enterprise projects where the requirements are well-known ahead of time, this approach may work well.
Cons - Often software is not completely understood before the user has interacted with it. As a result, either the specification process is long and expensive, or software is not specified well enough. This is especially true for a very dynamic product, such as a consumer web site where the features can change very rapidly.

<li><strong>Quality by Verification </strong>- continuously monitoring and verifying program outputs with automated scripts to make sure they match up with the programmer's intent.

Quality by Verification focuses on making tests automated and quickly repeatable so the project can change rapidly without unsettling the quality assurance staff. As the programmers' intent changes, the tests move with them. Automated tests also uncover hidden dependencies between different pieces of a large project (as breaks ripple through a project under rapid change, the tests highlight the issues and point developers to the problem.)
Pros - Results can be seen earlier and the project can change and grow more quickly as requirements are discovered. Testing allows for dynamic development environments like scripting languages. Automated tests can live as long as the code and offer continual validation of program output long after they are created.
Cons -Automated testing can be difficult without a disciplined approach to software architecture. It is often not feasible to adapt a code-base to automated testing if it was not designed with that in mind to begin with.

I hope it's clear that the most successful teams use elements of both approaches, but I think it's been interesting to see the shift from specification-based quality management to an increased emphasis on automated testing.

What approaches do your teams use? Where do the best quality gains come from?

TypeMock Announces Support for NCover 2.0

Peter Waldschmidt — Mon, 15 Oct 2007 08:46:11 GMT

I'm a little late on this announcement, but last week Eli Lopian announced that the newest version of TypeMock (version 4.1) now supports NCover 2.0.

If you haven't tried out TypeMock yet, you should try it out. TypeMock is a powerful type replacement framework that surpasses anything else I've ever seen. TypeMock uses the power of the CLR profiling API's to allow you to swap out virtually any type on the fly while testing. It is especially useful for testing code that wasn't designed to be mocked up easily. For instance, you can use this framework to mock up pieces of the .NET framework libraries, or a third-party vendor component, or just legacy code written before you decided on a testable design approach.

Collecting Coverage Data on Large Services

Alan Johnson — Wed, 03 Oct 2007 14:00:39 GMT

Collecting coverage data on large assemblies can be tricky at times. When the CLR loads an assembly, NCover analyzes the assembly to note the classes and methods that it contains. In most situations this analysis takes less than a second, but some projects with large assemblies (many megabytes) can run into longer load times.

Yesterday an NCover user reported an interesting issue when running NCover on a service. The user reported that he would start collecting coverage data on the service, it would run for about 30 seconds, and then the service would die. We asked him to send us a copy of the NCover log, and it looked an awful lot like an unhandled exception was occurring in his application. The only problem was, when he ran the service normally, no unhandled exception occurred.

It turns out that Windows Service Manager only gives a service 30 seconds to start by default, and then it ends the service's process, assuming that something is wrong. In order to get the Service Manager to wait long enough for the service to initialize properly, we need to increase the service timeout. That timeout can be overridden with a Windows registry key. To override it, open up regedit, and browse to

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control

If it's not already there, create a new DWORD value named ServicesPipeTimeout. Set the value of that key to the number of milliseconds that you would like Windows Service Manager to give your service to start up.

Problems like this can be pretty tough to solve, so please don't hesitate to contact us when you run into issues. Just submit a ticket through the support section of the website, and someone from our support team will help you troubleshoot your problem.

Announcing NCover 2.0.2

Alan Johnson — Tue, 02 Oct 2007 14:09:06 GMT

In the past two weeks we've worked hard to resolve those small nagging bugs that show up after any release, and we're proud to announce the resulting NCover 2.0.2. Among the improvements in this release are:

<li>Fixed a NullReferenceException that bothered many users generating HTML reports, especially those using C++ code.</li>
<li>Resolved a problem in the HTML output that caused links on modules pages to not work.</li>
<li>Fixed other miscellaneous bugs in the way HTML output is rendered.</li>
<li>Tweaked NCoverExplorer to give better status indication in the saving dialog, so that large coverage XML files don't make NCoverExplorer look like it is not responding.</li>
<li>Fixed issues involving running NCover 2 under TestDriven.NET on 64-bit Windows.</li>
<li>And...several other minor fixes.</li>

Download NCover 2.0.2, and please don't hesitate to contact our support team either via the forum or by submitting a trouble ticket if you run into any problems.

The What? Why? When? and How? of Code Coverage

Peter Waldschmidt — Fri, 28 Sep 2007 07:51:57 GMT

From time to time I get questions about why a developer would use code coverage or how best to use it, so I've put together a compilation of my thoughts about code coverage analysis and how it should be done. I'll be writing a series of these articles over time. Let me know if you have ideas for other topics you'd like me to elaborate on.

What is Code Coverage?

Code coverage analysis is a measurement that is taken on running program code reporting how much of that code was executed. Specifically, code coverage usually tells you how many times each line of code was executed. There are various forms of coverage metrics, such as function coverage, sequence point coverage, statement coverage and branch coverage. I'll elaborate on some of these in later posts. For now, NCover supports sequence point (which is basically statement coverage) and branch coverage.

Why do you need Code Coverage?

Code coverage is most valuable as a feedback mechanism for test-driven or agile development methodologies. Both of these methods rely on a developmental feedback loop that promotes the addition of features while maintaining a predictable quality level. Code quality is one of the most important concerns of any software development organization. Rapid development and technical wizardry will do you no good if customers can't rely on the quality of your product.

The way most modern software development teams maintain the quality of their software is by building a suite of unit tests that automate the verification of code correctness. These unit test suites are designed to run through (often thousands) of simulated program functions, verifying that the code is producing the expected output. While creating a number of unit tests is laudable, just creating a suite of tests alone is not enough. After some point, adding more tests does not necessarily mean that the code has better quality. You may just be testing the same code over and over again, while missing an important piece of code entirely. Any bugs in code that is not tested will not be detected by your unit test suite and thus could creep into production.

Coverage analysis closes that feedback loop by reporting on the comprehensiveness of your unit tests. Code coverage reports allow developers to quickly find code that is not executed by the test suite.

When should you use code coverage?

Early and Often...is the short answer. The heart of an iterative development environment is a continuous integration server. Each time a developer checks code into your revision control system (or on a regularly scheduled cycle), the build server should check out the latest code, do a full build of the product, run the test suite and report test success/failure and code coverage metrics. A continuous build process facilitates the early detection of code errors. Immediate reporting of code coverage also makes it clear to everyone on the team if the quality of your tests are increasing or declining.

How do I implement code coverage?

For the .NET framework, of course, I'd recommend NCover as the tool of choice. It's been used all over the world by over 100,000 developers, and has 4 years of maturity behind it. For other development platforms, there are various other code coverage tools available.

NCover performs analysis on your code by instrumenting it behind the scenes. If you are using NUnit as your unit testing tool, for instance, you would simply prefix the NUnit command line with the NCover command.

NUnit command line:

NUnit-Console MyTests.dll

NUnit with NCover:

NCover.Console NUnit-Console MyTests.dll

It's easy enough to create code coverage data, but we also include the NCoverExplorer tool for browsing your source code with coverage analysis and HTML reports for publishing those metrics to your team.

Look at the NCover documentation for more information about how to use it.

Thanks For a Great NCover 2.0 Launch!

Peter Waldschmidt — Thu, 27 Sep 2007 15:15:52 GMT

We've had a great response to the release of NCover 2.0. Thanks to all of you who have tried out NCover 2.0 and gone on to purchase it. Keep it coming. The Gnoso team has a lot of fresh ideas and we're excited about bringing a whole new level of code quality tools to .NET developers!

We've had a few relatively minor issues reported in the past week and we've been fixing the problems and giving out patches to the people affected. We'll put another software update up on the site within a few days once the initial issues settle down. If you are aware of a problem that we may not have caught, please let us know so we can get it into this upcoming release. Again, thanks to those of you who have provided feedback. We're still listening...

Uncovering the New NCover

Peter Waldschmidt — Mon, 17 Sep 2007 21:23:24 GMT

The NCover project has entered a new era. If you've looked around the rest of the web site already, you've probably noticed the complete overhaul of our site. Since the NCover 1.5.8 release in April, we've been working on an upgraded version of NCover. We've made a large number of improvements in the product. Check the list of highlights on the "What's New" page and let us know what you think.

Over the past few years, NCover has become a tool that many development teams rely on daily for their continuous build processes. As such, we have gotten many requests for help and additional features. As a part-time project, there was no way I could give it the time it deserved. A short time ago, I began to realize that the only way to provide the kind of support that NCover needed was to create a sustainable business model around NCover. Over the past 6 months, I've been putting that business model together. I've hired a team of talented developers to help me maintain and support the product. We've partnered with (the sharp and tireless) Grant Drake to roll NCoverExplorer into the NCover project. The team has written sorely needed documentation for NCover and NCoverExplorer (and there's more to come). In short, NCover has needed to become an enterprise-class tool for .NET developers, and with 2.0 we've made that step.

In determining pricing for NCover, we've done our best to price it well within the range of comparable development tools in the market. NCover owes a debt of gratitude to the .NET developer community for putting up with a beta-quality product since the beginning of the project. So, in order to ease the transition of NCover from a free to not-free product we are taking the following steps.

Gnoso will provide a free NCover 2.0 Enterprise license plus a one year support subscription to everyone who made a donation of any size to the NCover project before today. (Yes, I have a list). If you are one of those people, please contact us to redeem your free license.
Gnoso will provide free NCover 2.0 Professional licenses to educational institutions for use in educating the next generation of developers. We believe that test-driven agile development processes need to be taught in computer science curricula and we want to support that effort in any way possible.
Gnoso will provide free NCover 2.0 Professional licenses to open source projects to support development of their projects. Many free/open source projects have embraced NCover by adding NCover integration to their tools or by using NCover in their testing and build processes. We'd like to see these teams continue to succeed. If you are an active developer on a .NET open source project, please contact us to get more information about working with the NCover team.

This is a monumental step for the NCover team and we know it's just the beginning. We are wide open to feedback from you, our customers. Please try out the new version and let us know how we are doing. The product is much improved, but I'm sure we didn't get everything exactly right. We'd love to know how NCover can work better for you.