We have released an important maintenance release of NCover 5.5. We encourage all NCover users to upgrade as this release touches our entire product line. Remember, if you have an active support agreement there is no charge for this upgrade. If your auto-update alert has not already notified you, simply check for a new update from within the NCover GUI and initiate the update process.
We have full release notes for version V5.5.3353.1077 but here are a few of the key highlights:
Improved Handling of Module Duplication
This release marks a big change in the way NCover handles module duplication in code coverage. We have historically, and continue today, to define a module as being changed when the IL generated no longer matches a previous build. This approach allows multiple versions to merge, even after multiple rebuilds. However, once the IL changes, the module is considered new.
Historically, when these duplicate modules were merged, NCover would include both modules in the final merge.
As of V5.5.3353.1077, NCover will rely on Last Modified Date to determine which module in the merge is newer and NCover will only include the newest module in the final merge.
The main benefit of this new behavior will be seen by developers or teams that are continually merging coverage over a period of time. At any given point in time they will, by continuous merging, have the best summary of the coverage across their entire system without the confusion of how many times modules have changed.
This behavior previously required the use of the Prune command to remove modules that were being replaced. This change greatly reduces the work required to create the desired outcome. Although this is the new default behavior, you can easily revert to the previous behavior via a system-wide config setting by setting the following attribute to false in the ncover.exe.config file and restarting the windows service:
<deduplicateModulesOnMerge>true</deduplicateModulesOnMerge>
Please contact us if you have any questions or need assistance with this setting.
Faster Document Filtering
Document filtering speed has been greatly improved, particularly when multiple filters are in place, and we have made several minor adjustments to the calculation of metrics. Previously document filters eliminated only statistics from the query, but now the code branches (classes, methods) within those documents will be filtered from the tables and navigation. Additionally, the filtering process is much quicker, making the documents view of coverage more responsive. Document filters are most commonly used to ignore generated files in a solution like *.Designer.cs files.
Improved Merge Handling
One of the deceptive causes of duplicated modules which will not merge is the differences between DEBUG and RELEASE builds of the same code. This release introduces new labelling at the module view which shows if the profiler was able to detect that JIT optimizations are disabled. Disabled optimizations is the common identifier in compiled .NET assemblies that indicates if the assembly is a Debug or a Release build. This provides one more clue to the observer what the differences are between assemblies. The details reported now are Version, Create Date, and Debug/Release.
Faster Import of Execution Data
The import of execution data from export files is now dramatically faster with this release. We have refined the import process to provide a heavily multi-threaded import which also optimizes disk I/O and results in much faster imports. We tested the improved process against imports which contain a hundred executions and, in a control situation where all other system resources are held constant, have seen reductions in import time from approximately 2 hours to approximately 5 minutes.