To ensure that your unit tests exercise your code properly, you’ll need sufficient code coverage. Your coverage should be as close as possible to 100 percent. However, if your code base includes generated artifacts, such as resource accessors or strongly typed datasets, it is unlikely that you’ll come close to this figure. This is because the generated code has methods and properties for a wide variety of usages, many more than you’re actually using, thus leaving lots of untested code in your project. Since generated code skews your code coverage results, factoring generated code to separate assemblies is a common practice to avoid misleading code coverage metrics. A basic example is to have datasets in one project and business components in another project with a reference to the dataset project. This solves the code coverage issue, but it also introduces some other issues. Since one logical assembly has to be split into two or more physical assemblies, you’ll lose cohesion between the different logical assemblies. This might not be an issue during development, but you’ll at least have twice as many assemblies to deploy, version and maintain when the solution goes to production. Michael Barnett of Microsoft Research has developed a tool called IL Merge which can be used to merge multiple .NET assemblies into a single assembly. If you’re familiar with C-programming, IL Merge is akin to a linker.
For the remainder of this post I’ll show how you can factor a resource accessor out of a business component project to its own project, make the internals of that project available to the business component project (resource accessors aren’t publicly visible) and use IL Merge to merge the two assemblies into one.
I have created a small Visual Studio 2005 solution with two projects, one for business components and another for resources.
As mentioned earlier the generated resource accessor class is an internal class, and hence it is not available outside the assembly itself. There are numerous ways you can access the internals of one assembly from another. The most elegant is to use the .NET 2.0 InternalsVisibleTo attribute. This attribute allows you to declaratively give one or more assemblies access to the assembly’s internal members. The following declaration has been added to the ClassLibrary.Resources project’s AssemblyInfo.cs file. [assembly:InternalsVisibleTo("ClassLibrary")]
For a thorough discussion on InternalsVisibleTo and the other options available for accessing one assembly’s internal members from another, see my post “InternalsVisibleTo, StrongNameIdentityPermission and reflection”.
The internals of ClassLibrary.Resources are now available from within the ClassLibrary project with IntelliSense and other Visual Studio comforts just like if both the resources and the code had been part of the same project. An important difference is that the code base is spilt into two assemblies, so that you’re able to instrument just the ClassLibrary assembly and get accurate code coverage results.
When the unit test have been run (with code coverage instrumentation) you can then merge the two into a single assembly by using the IL Merge tool.
As you would expect, the merged assembly contains both the business component from the ClassLibrary project and the resources from the ClassLibrary.Resources project. Also note that it is a regular .NET assembly, so you can add it as a reference to any other project, sign it with your strong name key or similar.
Typically you would merge the two assemblies either when you package a release version of your code or from within your continuous integration build script prior to deploying it to a test rig.
There is a NAnt task for IL Merge available for download here. I’m not aware of a MSBuild task for IL Merge, but you can easily run IL Merge from your MSBuild script using the Exec task as shown below
<Project DefaultTargets="CompileUserControls"
xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
...
<Target Name="MergeAssemblies">
<Exec Command="$(ILMergeEXE) /out:$MergedClassLibrary.dll
ClassLibrary.dll ClassLibrary.Resources.dll" />
</Target>
...
</Project>I believe this is an elegant solution to a problem which almost everyone doing Test Driven Development on the .NET platform run into. However, one feature I’d really like to see in Visual Studio Orcas is the ability to declaratively exclude types, or even members from code coverage instrumentation. This could very well follow the same convention used to suppress static analysis rules with System.Diagnostics.CodeAnalysis.SuppressMessageAttribute since this would allow any vendor to support it without forcing developers to reference a particular assembly in their code (SupressMessageAttribute is defined in mscorlib.dll). The solution described in this post is vendor neutral and works just as good with Team Test as with Clover.NET or any other code coverage analyzer.