Wednesday, November 18, 2009

Announcing Gallio v3.1 Update 2

Today we are releasing Gallio v3.1 Update 2.  This releases fixes several problems on x64 platforms and includes support for Visual Studio 2010 and .Net Framework 4.0 Beta 2.

Download here:

Documentation here:

Earlier release notes: v3.1 update 1, v3.1, all versions


  • Improved startup performance by fixing a problem with pre-generated XmlSerializers.
  • Added support for Visual Studio 2010 and .Net Framework 4.0 Beta 2.
  • Fixed an AccessViolationException in Icarus.  Special thanks to Kent Hansen for identifying the root cause and proposing a fix!
  • Fixed installer bugs on x64 which caused some components to not be installed.
  • Fixed bugs running MSTest tests on x64.
  • Fixed a problem that caused long-running tests to be aborted prematurely by Visual Studio.
Technorati Tags: ,

Thursday, November 12, 2009

XmlSerializers, ModuleVersionId, ILMerge, and You

I solved a minor mystery today.

Gallio internally uses the .Net XmlSerializer class to load plug-in metadata and save reports.  You probably know all about XmlSerializer already, but maybe you don’t know just how badly using it can impact application start-up performance.

About XmlSerializer Code Generation

The heart of the issue is that XmlSerializer uses code generation to perform serialization and deserialization.  Specifically, XmlSerializer generates some fresh C# code, compiles it out of process with csc.exe, then loads the resulting assembly.  This work takes time.  Seconds… feels like forever to a user.  The generated assemblies are not cached across runs so there is a significant performance penalty on every launch.

There is a way to avoid this cost: pre-generate serializers assemblies and distribute them with the application.

To pre-generate a serializers assembly, you are supposed to use SGen.exe a bit like this:

SGen.exe /assembly:MyAssembly /type:MyRootXmlType

This command will emit MyAssembly.XmlSerializers.dll.  All you need to do then is copy it next to MyAssembly.dll and you’re done.  The cost of code generation is gone from every launch.

Two problems:

  1. SGen only lets you specify one root type.  If you use multiple Xml document types in your assembly then you will need to write a custom tool like this: Gallio.BuildTools.SGen.
  2. Make absolutely sure that you keep MyAssembly.dll and MyAssembly.XmlSerializers.dll in sync.  If you change MyAssembly.dll in any way then you must regenerate the serializers assembly.  This is easy to set up once in your build scripts and forget about.


So let’s say you do all of this work and you run your program and you still see csc.exe starting up while your program runs.

To find out why, add the following to your application’s config file.  (eg. MyApp.exe.config)


            <add name=”XmlSerialization.PregenEventLog” value=”1” />


Then run your program again and look at the Windows Event Log.  There should be some information in there to help you out.  (Another thing to try is fuslogvw.exe.)

Here’s the message that I saw:

Pre-generated serializer ‘Gallio.XmlSerializers’ has expired. You need to re-generate serializer for ‘Gallio.Runtime.Extensibility.Schema.Cache’.

This message is telling me that I violated rule #2 above: the serializers assembly must always be kept in sync with its parent assembly!

Why?  I’ve got fancy build scripts…


XmlSerializer verifies that the serializer assembly is in sync with its parent assembly by comparing the module version id of the parent assembly with an id that it previously cached when it generated the serializer assembly.

Let’s check whether the assemblies are in sync using Reflector.

Gallio.dll is the parent assembly, it has a module version id of “fbe34432-817a-46dd-832f-3e5bc679ecff”.


Gallio.XmlSerializers.dll is the serializers assembly, it has a special assembly-level attribute called XmlSerializerVersion that was emitted during code generation.  It expects the parent assembly id to be “3c420916-3f3c-45cb-a79c-9a4bbc81014a".

Pedantic note: An assembly can have multiple modules each and each module has its own id.  So the XmlSerializerVersion attribute actually contains a comma-delimited list of all module version ids of the parent asssembly sorted in increasing order.


Ok, so XmlSerializer thinks the pre-generated serializers assembly is out of sync because the module id is out of sync.  That seems bananas because my build scripts always regenerate Gallio.XmlSerializers.dll whenever Gallio.dll is recompiled.


Well, my build scripts do one more thing: they run ILMerge on Gallio.dll to internalize certain dependencies that might otherwise get in the way of running unit tests.  (Bad things would happen if your unit testing tool exposed a dependency on one version of Mono.Cecil.dll whereas your tests depended on a different version.)

When ILMerge internalizes dependencies, it has to regenerate the assembly.  As a result, the new freshly merged Gallio.dll gets a brand new ModuleVersionId.  Unfortunately we pre-generated Gallio.XmlSerializers.dll before running ILMerge so it is now out of sync.

All we need to do is regenerate Gallio.XmlSerializers.dll after the ILMerge.  Problem solved.

Monday, October 26, 2009

Announcing Gallio and MbUnit v3.1 Update 1

Today we are releasing Gallio and MbUnit v3.1 Update 1.  This is mainly a bug fix release with a few new little goodies.

Download here:

Documentation here:

Earlier release notes: v3.1, all versions

Reminder: The Visual Studio Test Tools integration requires Visual Studio 2008 SP1 or Visual Studio 2010 to work.  If you still don't see tests in the Test View then ensure that your project has the necessary ProjectTypeGuids and that the Gallio add-in is enabled in the Visual Studio Add-In Manager.


  • [New!] Added samples for web testing with WatiN.  In particular demonstrates the creation of a custom [Browser] attribute to support running tests with multiple browsers.
  • [New!] Added samples for GUI testing with White.
  • Improved basic MbUnit samples a little to make them easier to understand.
  • [New!] Added a Sources.txt file to the installation to help users find out where to check out the original source code for the release.
  • Fixed a bug with Hint Directories being ignored by the test runners.
  • Upgraded MVC templates for ASP.Net MVC 2.
  • Fixed bug with transitive dependencies not being considered by [DependsOn] attribute when deciding whether to skip a test.
  • Improved the error message displayed when attempting to use a [StaticTestFactory] in ReSharper which is not supported due to technical limitations.
  • Fixed bug with use of [Factory] attribute on a fixture type or property when the type was not explicitly specified.
  • Improved error reporting and workarounds for cases where the assertions or test context are being used incorrectly to help a test author diagnose the problem.
  • [New!] Added support for using the Delete key to delete items from the Project Explorer.
  • [New!] Pending and Ignored tests are now unchecked by default.
  • Added filtering to the test report view to only include reports that match the current report name format.
  • Fixed some threading issues.
  • Fixed some test filter issues.
  • Fixed test counts.
  • Fixed window positioning issues.
  • Fixed display of test categories.
  • [New!] Added support for viewing embedded text, html and video attachments in Icarus and Visual Studio.
  • Fixed rendering of embedded plain text attachments to preserve formatting.
  • Fixed UTF-8 character encoding issue with html reports.
  • Fixed attachment links and code navigation links in reports on 64-bit platforms and in Internet Explorer Protected Mode.
xUnit.Net Adapter:
  • Upgraded to v1.5 RTM.
AutoCAD Integration:
  • Improved detection of AutoCAD window.
ReSharper Integration:
  • Added support for certain reflection operations which were needed by NUnit to support derived test fixtures in ReSharper.
  • Fixed a bug that caused duplicate NUnit tests to appear in ReSharper.
NAnt Integration:
  • Changed how the severity of certain test results are reported so that NAnt does not incorrectly consider a test run to have encountered a non-fatal error when in fact a warning should have been logged.
TeamCity Integration:
  • Fixed a bug in the test event processing that indirectly caused TeamCity test result reporting to stall when an empty test assembly was encountered.
Technorati Tags: ,

Thursday, September 17, 2009

Gallio Next Steps

With Gallio v3.1 released, I have begun planning for what's ahead.

My first priority is to fix most of the issues that have been reported and to release a minor update to Gallio v3.1 in a week or two.

After that, the hard work begins.

Testing as a Service

As it stands, the Gallio platform mainly consists of one core library and a whole bunch of plug-ins.  The majority of the code is written in C# and runs on .Net Framework 2.0.

I want to go further.

The main goal of Gallio v3.2 will be to adapt the Gallio platform to operate as a collection of services that communicate via a message bus.  We will publish a specification of the messaging protocol so that other tools -- not necessarily written in .Net -- will be able to exchange messages with Gallio tools and participate in test execution, monitoring and reporting.

Why not pool our talents to develop great testing tools that work together across platform boundaries?

Gallio v3.2 and Beyond

Here's what you can expect from upcoming releases.

  1. Open messaging protocol.
  2. Test data warehouse.
  3. Web-based test reporting tool and test case manager.  (Archimedes)
  4. Test rigs for remote test execution.
  5. Data collection API for monitoring performance, gathering metrics and computing statistics.
  6. Improved IDE integration.
  7. Improved cross-platform support.
  8. More openness about the development process in general.
  9. Performance optimization, particularly of UI responsiveness and program start time.

How to Participate

I want to work with other members of the community to grow a practical lingua franca for test data interchange.  While at first we will be discussing how to design a suitable messaging protocol for Gallio, I hope that it will eventually evolve into an independent open standard that anyone can implement.


Please join us on the gallio-dev mailing list and tell us what you think!  :-)

Monday, September 14, 2009

The Gallio Plug-in Model

One of the biggest changes in Gallio v3.1 was is a new plug-in model.

The new plug-in model features comprehensive support for late-binding of components, provides a rich declarative metadata model, and provides enough information to support the installation and verification of plug-in assemblies and resources.


Late-Binding and Declarative Metadata

Gallio includes many plug-ins out of the box and more can be installed later but not all of the plug-ins need to be loaded at all times.  To improve startup time, Gallio defers plug-in assembly loading until the last possible moment.  Consequently Gallio's plug-in model relies heavily on late-binding and declarative metadata that is external to the plug-in assemblies.

We don't use .Net custom attributes to provide most of this metadata because then we would have to load assemblies in order to read it out.  (Note: We could read metadata from custom attributes once and cache it like MEF does but it is not practical for some purposes such as plug-in installation.)

So the basic idea is to pack a bunch of useful information in XML.

Drop-In Plug-In Installation and Caching

Gallio strives to support XCopy-style deployment as much as possible.  This feature makes it possible to check-out a copy of Gallio from your source tree and just run it with no strings attached (except for special features that require installation like Visual Studio integration).

When designing the Gallio plug-in model it was important to ensure that Gallio plug-ins could be installed just by dropping files in the right place.  At run-time Gallio locates its plug-ins by searching plug-in directories recursively for .plugin files.  There is one major problem with this process: recursively scanning directories and loading lots of little files can be very time-consuming.  So the new plug-in model incorporates a cache.

Gallio maintains a per-user cache of installed plug-ins in any given list of plug-in directories.  This way when it starts up, it only needs to load the cache file and move on.

However there is a small problem with this approach.  By caching plug-in metadata, it is no longer sufficient to just drop in new plug-in files to install them.  The cache must be cleared somehow.

Gallio implements three strategies for refreshing its cache:

  1. When loading a cache file, it checks the timestamps on the original plug-in files to verify that they have not been changed.  This way Gallio can automatically detect an edit to a .plugin file and refresh the cache.  Unfortunately it cannot detect the presence of new .plugin files.
  2. A user can explicitly clear the plug-in cache using the  "Gallio.Utility.exe ClearUserPluginCache" command.  Unfortunately if there are multiple users of the machine then all users will need to have their plug-in cache cleared to detect the presence of a new plug-in.
  3. A admin user can explicitly reset the Gallio "installation id" of the machine by running "Gallio.Utility.exe ResetInstallationId".  This command effectively invalidates the caches of all users running on the machine at once.

It's not ideal but it works well for now.  Plug-in metadata caching has significantly improved Gallio start-up performance.

Plug-in Metadata

.plugin files

Each Gallio plug-ins has a ".plugin" file that describes the plug-in using XML.  The description includes the id of the plug-in, some traits, dependencies, associated files, referenced assemblies, services and components.

Here is an excerpt of Gallio.plugin.

<?xml version="1.0" encoding="utf-8" ?>
<plugin pluginId="Gallio" recommendedInstallationPath="" xmlns="">
    <description>The heart of Gallio.</description>

    <dependency pluginId="BuiltIn" />

    <file path="Gallio.plugin" />
    <file path="Gallio.dll" />

    <!-- SNIP -->


    <assembly fullName="Gallio, Version=, Culture=neutral, PublicKeyToken=eb9cfa67ee6ab36e" codeBase="Gallio.dll" qualifyPartialName="true" />

    <service serviceId="Gallio.TestFramework"
             serviceType="Gallio.Model.ITestFramework, Gallio" />

    <service serviceId="Gallio.TestFrameworkManager"
             serviceType="Gallio.Model.ITestFrameworkManager, Gallio" />

    <!-- SNIP -->


    <component componentId="Gallio.FallbackTestFramework"
               componentType="Gallio.Model.FallbackTestFramework, Gallio">

    <component componentId="Gallio.TestFrameworkManager"
               componentType="Gallio.Model.DefaultTestFrameworkManager, Gallio">

    <!-- SNIP -->


Services and Components

Following the nomenclature used by several .Net Inversion of Control Containers, Gallio refers to its extension points as services and its extensions as components.  Services nominally represent interfaces.  Components provide implementations of those interfaces.

Internally Gallio refers to all service and component types by name using a TypeName object until it needs to instantiate it.  This is different from most .Net IoCs which immediately resolve most type names to runtime Type objects during initialization which causes most assemblies to be loaded up front.

Dependency Injection and Configuration

Gallio's plug-in model supports constructor and property dependency injection and configuration for components.

In the .plugin XML, the component parameters appear in a <parameters> element which contains an element for each constructor parameter or property that is to be bound.  If no value is specified for a given constructor parameter, then Gallio will attempt to resolve a service of the appropriate type to bind.  Otherwise if a value is specified, then Gallio will attempt to convert the provided string to an object of the required type using a DefaultObjectDependencyResolver.

The default object dependency resolver knows how to resolve all sorts of object types including strings, arrays, components, ComponentHandles, IComponentDescriptors, Versions, Guids, Icons, Images, Conditions, FileInfos, DirectoryInfos, Assemblies, AssemblySignatures, AssemblyNames, Types, TypeNames, and explicit references to other components (using the ${} syntax seen in the excerpt above.)

Gallio resolves Icons, FileInfos, and other disk-based plug-in resources using a special Uri scheme called "plugin".   For example, a component might require a reference to a file that belongs to the plug-in so it declares a constructor parameter of type FileInfo.  In the XML, it provides the path of the file relative to the plug-in base directory by specifing a parameter with a Uri like: "plugin://MyPlugin/Path/To/File.txt".  When the component is instantiated, Gallio will resolve the Uri and provide a FileInfo with the appropriate full path to the file.

Plug-in and Component Traits

Traits are collections of typed properties that Gallio uses to describe plug-ins and components.

At runtime, plug-in traits are represented by instances of the PluginTraits class which looks a bit like this:

public class PluginTraits : Traits
    public PluginTraits(string name) { ... }
    public string Name { get; }
    public string Version { get; set; }
    public Icon Icon { get; set; }
    // SNIP...

Likewise, component traits are represented by instances of the service's associated Traits type.  To establish that association, a service type may have an optional TraitsAttribute applied.

public interface MyService
    void DoSomething();

public class MyServiceTraits : Traits
    public string SomeInformation { get; set; }
    public string[] MoreInformation { get; set; }
    public Icon MyIcon { get; set; }

Traits parameters are bound just like component parameters except that they appear in the <traits> element of the ,plugin XML.

Plug-in Dependencies

In the .plugin XML, the <dependencies> element specifies the ids of other plug-ins that are required by this plug-in.

The dependency information allows Gallio to do a few useful things:

  • If a plug-in dependency is missing or disabled then all dependent plug-ins are automatically disabled.
  • Before activating a plug-in, all of its dependencies are activated.  (Note: Not implemented in v3.1 but may appear in a later version.)
  • When verifying the plug-in installation, Gallio can check that all of the services required by a plug-in are provided by that plug-in or by one of its dependencies.  This check helps developers find errors in component registrations.
Assembly References and Probing Paths

Each plug-in describes the list of assemblies that it required in the <assemblies> element of its plug-in XML.  Before attempting to use any components defined by a plug-in, Gallio first ensures that the plug-in's assemblies can be resolved.  Assembly references can also be qualified with binding redirects and other loader options.

A plug-in can also declare custom probing paths in a <probingPaths> element.

Here are a few possibilities:


    <assembly fullName="MyAssembly, Version=, Culture=neutral, PublicKeyToken=eb9cfa67ee6ab36e" codeBase="MyAssembly.dll" qualifyPartialName="true"  applyPublisherPolicy="true">
            <bindingRedirect oldVersions="" newVersion="" />

    <assembly fullName="MyAssemblyInGAC, Version=, Culture=neutral, PublicKeyToken=eb9cfa67ee6ab36e" />

Plug-in Files and Recommended Installation Path

In order to facilitate plug-in installation, each plug-in includes two pieces of information:

  • A list of files in a <files> element.
  • A recommended installation path (relative to the Gallio bin directory) in the recommendedInstallationPath attribute of the <plugin> element.

Gallio uses this information in two ways:

  • During plug-in installation it is able to determine which files belong to which plug-ins so that it can copy or delete just the necessary files.  (Note: Automatic plug-in installation is not implemented in Gallio v3.1 and will appear in a later release.)
  • On request, it checks the information to verify that all plug-ins are installed as expected and that no files are missing.  This is part of what happens when you run the "Gallio.Utility.exe VerifyInstallation" command.
Conditional Plugin Enablement

Plug-ins can include a conditional expression that specifies when the plug-in should be enabled based on characteristics of the environment.  For example, some plug-ins related to Visual Studio integration are only enabled when Gallio is hosted by the appropriate version of Visual Studio.

The conditional expression appears in the enableCondition attribute of the <plugin> element of the .plugin XML files.

Conditions are represented in the code by Condition objects.  Each Condition consists of a simple boolean expression of terms drawn from a ConditionContext and combined using logical "or".  For plug-in enablement the runtime uses the RuntimeConditionContext object to query properties in the environment.

The following condition properties are currently supported.

  • "${env:ENVIRONMENTVARIABLE}": Satisfied when the environment contains a variable called "ENVIRONMENTVARIABLE".
  • "${minFramework:NET20}", "${minFramework:NET30}", "${minFramework:NET35}", "${minFramework:NET40}": Satisfied when the currently running .Net runtime version is at least the specified version.
  • "${process:PROC.EXE}", "${process:PROC.EXE_V1}", "${process:PROC.EXE_V1.2}", "${process:PROC.EXE_V1.2.3}", "${process:PROC.EXE_V1.2.3.4}": Satisfied when the currently running process main module is "PROC.EXE" and exactly matches the specified file version components (if any).

For example, here's part of the .plugin XML file for the Gallio35 plug-in which provides .Net 3.5 specific extensions.

<plugin pluginId="Gallio35"

Runtime API

Gallio clients mainly interact with the plug-in model by way of the following types:

  • RuntimeAccessor: Accessor for the core runtime objects.
  • IRuntime: Configures and provides access to the plug-in registry, service locator, runtime logger, and other runtime parameters.
  • IRegistry: A registry of all installed plug-ins, services and components.
  • IServiceLocator: A service locator for resolving services and components provided by plug-ins.

The initialization process looks a bit like this:

  • Client code calls RuntimeBootstrap.Initialize() to initialize the runtime.
  • The runtime creates a CachingPluginLoader.
  • The caching plugin loader loads plug-in metadata into a PluginCatalog.  The metadata is represented in the catalog as PluginRegistration, ServiceRegistration, and ComponentRegistration objects.
  • The runtime augments the catalog with a few built-in services of its own.
  • The runtime creates a new Registry and populates it from the catalog.  Gallio performs many checks during this stage to ensure that plug-ins are well-formed and that all of their assemblies are accessible.  It automatically disables plug-ins that have problems.

Once the registry has been initialized, client code can use it in different ways.

  • The registry provides methods for getting IPluginDescriptor, IServiceDescriptor, and IComponentDescriptor objects.  Descriptors are used to get information about plug-ins, services and components as well as to obtain instances of components and traits objects.
  • The service locator provides methods for resolving services.  These are the same kinds of familiar operations exposed by most .Net IoCs such as Resolve, and ResolveByComponentId along with a couple novel ones like ResolveHandle and ResolveHandleByComponentId which obtain late-bound ComponentHandles.  Gallio does not use the service locator explicitly very often.  Most service location is performed implicitly by the runtime as part of dependency injection.

The ComponentHandle type is interesting in that it allows clients to obtain a typed reference to a component descriptor without resolving the component instance itself until needed.  Here is an example usage of a component handle to enumerate installed components and choose to instantiate one or more of them based on some criterion.

var frameworks = new List<ITestFramework>()
ComponentHandle<ITestFramework, TestFrameworkTraits>[]  frameworkHandles = // ...

foreach (var frameworkHandle in frameworkHandles)
    TestFrameworkTraits traits = frameworkHandle.GetTraits();
    if (IsSupportedFileType(traits.FileTypes, testFile))

Brief Comparison with Other Plug-In Models

Gallio's plug-in model is similar to the Eclipse plug-in model, Mono.Addins and MEF.

Eclipse and Mono.Addins both use XML to register plug-ins and to declare extensions points (services) and extensions (components).  Extensions can provide ample metadata in the form of XML extension configuration data.  Both of these frameworks also have provisions for packaging plug-ins as archives that can be installed incrementally.  (Of course, Mono.Addins was inspired by Eclipse so this is no surprise.)

MEF supports late-binding Exports (component handles) and makes available ExportMetadata (traits) for clients to use.  MEF is mainly attribute-based but can be configured to use external metadata files by providing an appropriate Catalog implementation.  It is quite powerful and will be included as a standard system component in the .Net Framework 4.0 release.

Aside: The original Gallio plug-in model used the Castle Windsor inversion of control container as its foundation.  Unfortunately Windsor does not support late-binding (it resolves all type names to Types on initialization) and it has limited support for component metadata.  It is a great tool (and I highly recommend it for many projects) but just not well suited to Gallio's needs.

Why Not Use Mono.Addins or MEF for Gallio?

This was a tough call.

I took a good long look at Mono.Addins and MEF beforehand.  Both are good options but I had a couple of problems with each of them.

I rejected Mono.Addins because I was not confident that I would be able to morph it into the kind of shape I needed for Gallio.  I found the code to be tightly coupled in several places that I knew I would have to change dramatically to get the kind of dependency injection and late-binding features that I wanted.

And MEF unfortunately required .Net 3.5 as a minimum whereas I had selected a target framework of .Net 2.0 for Gallio.  I briefly considered porting MEF to .Net 2.0 but gave up once I saw how much of System.Core it used.  Also it was clear that the attribute model would not work well for Gallio's late-binding needs so I would not benefit from those features.  Oh well.  I look forward to trying MEF out another day with a .Net 4.0 project perhaps.

So it just seemed more straightforward to start over which would give me a maximum of flexibility in the implementation.  As it happens, I have taken advantage of that flexibility many times over to make things better and I can say I am very happy I did not try to shoehorn Gallio into Mono.Addins or MEF.  For example, some of the plug-in metadata Gallio uses would be very awkward to implement and consume with either of these libraries.


Future Directions

Here are some things to expect from future versions of the Gallio plug-in model:

  1. A plug-in manager tool for downloading, installing, and maintaining plug-ins.
  2. A plug-in activation process to enable plug-ins to have more control over their early initialization.
  3. Extensible object dependency resolvers.
  4. More optimizations for start-up performance.
  5. Component scopes so that test frameworks can install special extensions while they run.  eg. custom object formatters for MbUnit.


Technorati Tags:

Friday, September 11, 2009

Announcing Gallio and MbUnit v3.1!

Gallio v3.1 is a major upgrade to the platform.  This release includes many new features, better performance, and improved robustness.


  • Video capture and embedding in test reports.
  • RSpec!
  • Support for .Net Framework 4.0.
  • Support for Visual Studio 2010 Beta 1.
  • Control Panel application.
  • Brand new plug-in model with improved startup performance.
  • Major internal redesign.
  • More MbUnit goodness.

Download here:

Documentation here:

Earlier release notes: v3.0.6, v3.0.6 update 1, v3.0.6 update 2, all versions

Installation Notes

We recommend completely uninstalling any previous installation of Gallio before installing the new one.  Be sure to shut down Visual Studio while uninstalling because some files may still be in use.

We strongly recommend installing KB963676 before installing Gallio.  This patch fixes some Visual Studio crashes that may occur while editing ASP.Net pages.

New and Noteworthy

Video Capture and Embedding

Gallio now includes support for capturing video screen recordings and embedding them in test reports.


Imagine you were writing integration tests for a Web or GUI application through the UI using a library like WatiN or White.  When the test fails, it is very handy to have a record of just what happened.


In the next couple of sections I'm going to show how you can capture and embed screen recordings like the following into Gallio test reports.

Screen Capture and Embedding

This is all it takes to capture and embed a screenshot in the test report.


Or if we just want to capture a screenshot when a test fails or is inconclusive, here's how we can do it.  We can also scale the image by 25% to keep the report small while still preserving enough detail to read.


As you can see the Capture class has some interesting methods.

Creating and Embedding Videos

A video is just an encoded sequence of frames.  So we can build up a screen recording by taking screenshots at intervals and adding them to an instance of the Video class such as a FlashScreenVideo.


Notice that you can create videos of anything you like.  You are not limited to screen recordings.

Screen Recording and Embedding

Gallio offers a few shortcuts to simplify screen recording in particular.

The ScreenRecorder class captures screenshots in a background thread and assembles them into a Video that can later be embedded.


The Capture class also provides a method for automatically embedding a screen recording based on the outcome of the test.  It starts a screen recorder in the background and when the test finishes decides whether to embed the video or discard it.

This is a very powerful one-liner...

Here we set things up to capture a screen recording at 5 frames per second and 25% zoom factor and cause it to be automatically embedded if the test fails or is inconclusive.



Raw screen recordings are very useful but we can enrich them with additional information.  For example, while playing back the recording, it can be useful to see a transcript of what the system was doing when it captured the frame.

Gallio supports applying any number of Overlays to any screen recording.  An overlay is a basically an object that paints itself onto an image.

We're going to use a CaptionOverlay to add a caption to the video as we record it.  We can change the caption between frames to display a variety of information.


That's a lot of work so the Capture class provides a few convenience methods for setting a caption overlay for its screen captures and screen recordings.


Magic Recipe for WatiN

Here's the whole recipe for hooking up automatic screen recordings with WatiN 2.0.

public abstract class WatiNFixture
    protected Browser Browser { get; private set; }

    public void SetUp()
        Logger.LogWriter = new GallioLogger();

        Capture.SetCaptionAlignment(HorizontalAlignment.Center, VerticalAlignment.Bottom);
            "Screen Recording",
            new CaptureParameters() { Zoom = 0.25 }, 5 /*frames per second*/);

        IE ie = new IE();
        Browser = ie;

    public void TearDown()

        if (Browser != null)
            Browser = null;

    private sealed class GallioLogger : ILogWriter
        public void LogAction(string message)

        public void LogInfo(string message)

        public void LogDebug(string message)
            // Ignore these messages.

public class SampleTest : WatiNFixture
    public void GoogleSearchAndVisitMaps()


        Browser.Link(Find.ByText("Ottawa, ON Canada")).Click();

        Browser.Link(Find.ByText("Parliament Hill")).Click();

        Browser.Link(Find.ByText("Full article")).Click();

        Assert.Fail("Just for show.");

RSpec and IronRuby

Now for something completely different: RSpec integration.

Big News

The big news here is that Gallio now supports running tests that are defined in files instead of just .Net test assemblies.  This means you can pretty easily create custom test framework adapters for any kind of file that you know how to process and then run those tests using Icarus and other tools.

Yes, that means you can implement 5 methods of ITestDriver (or one of the helper subclasses Gallio provides) and have a custom test framework of your own using whatever kinds test files you like be they spreadsheets, XML files, native executables, or programming language text.

RSpec in Action

Let's suppose we have implemented a "Bowling" class that computes the score of a bowling game.  (This example is borrowed from the RSpec site.)

class Bowling
    def hit(pins)

    def score

Obviously this implementation will not get us very far.  So we write some specs to guide us along.

require 'bowling'

describe Bowling do
  it "should score 0 for gutter game" do
    bowling =

    20.times { bowling.hit(0) }

    bowling.score.should == 0

  it "should score 300 for perfect game" do
    bowling =

    12.times { bowling.hit(10) }

    bowling.score.should == 300

  it "should score 20 for single pin hit each ball" do
    pending("Scoring to be implemented.")

RSpec + Icarus

Now we just add the bowling_spec.rb file to Icarus, and run...


RSpec + Icarus + AutoRun = Bliss

When programming in a BDD way you will probably find it useful to enable the Icarus auto-run feature.  Then whenever you edit the spec, they will be reloaded and re-executed.

It's a little slow right now but expect it to get better in future versions.


MbUnit Features

Yann Trévin has been busy cooking up new features for MbUnit v3.1.


The Retry class makes it easy to implement polling loops in tests.  Polling loops are useful when the test must wait for an asynchronous operation to complete but does not know how long it might take.


More information about Retry.Until.

Assert.Sorted and Assert.Distinct

Two new assertions for checking whether the elements in a collection are sorted or are distinct.

More information about Assert.Sorted.

More information about Assert.Distinct.

Assert.ForAll and Assert.Exists

Two new assertions for checking whether a property holds true for all elements of a collection or for at least one of them.  These assertions are incredibly useful.


More information about Assert.ForAll and Assert.Exists.

Assert.Throws for Inner Exceptions

Assert.Throws now accepts an optional second type parameter to specify an inner exception type.

More information about Assert.Throws in general.


Did you ever have a data structure that you wanted to check for equality but it did not override Object.Equals?  Ever grumble about having to implement this check manually?

MbUnit v3.1 includes a new feature called a structural equality comparer.  The idea is to make it super easy to compare all members of a structure according to some rule.  Basically you just provide a list of lambda expressions to select structure members to compare and then you optionally provide a comparison predicate.  MbUnit will then compare the structure member by member using the provided selectors and predicates.


More information about StructuralEqualityComparer.

EnumData, SequentialNumbers, RandomNumbers and RandomStrings

Yann wrote a bunch more nifty data source attributes.  Here they are in one big combinatorial test.



The [MultipleCulture] attribute runs a test repeatedly with different cultures.



The [Impersonate] attribute runs a test using different user credentials.



TestContext.AutoExecute makes it easy to register actions to perform when a test passes or fails without needing to write a [TearDown] method.

This example captures and embeds a screenshot in the test report whenever the test fails.


Control Panel

Gallio now has a control panel application where you can set all sorts of preferences.

Feel free to suggest other things for us to add to the control panel.

Gallio Runtime Settings

The Gallio runtime settings let you tweak some global parameters.  Currently it lets you set custom plug-in paths in case you have installed other Gallio plug-ins elsewhere in your system.

Expect this list to grow...


Icarus Settings

All of the Icarus settings have moved to the Control Panel so you can configure them in the same place as other settings.


TestDriven.Net Settings

Now we have a place to configure settings for TestDriven.Net.

The Frameworks page lets you configure whether Gallio will be the default or preferred test runner for different frameworks.  For example if you have csUnit installed and you prefer to use Gallio to run csUnit tests with TestDriven.Net then you can set Gallio's priority to "Preferred".  If you set Gallio's priority to "Default" then Gallio will only be used if there is no other installed test runner available for a particular framework.


AutoCAD Settings

Mike Sandberg contributed a new preference panel for configuring the AutoCAD integration.

The AutoCAD integration still supports the "AcadAttachToExisting" and "AcadExePath" runner properties but having a GUI is certainly much nicer...


Plugin Diagnostics

Just for completeness, Gallio also displays a list of all installed plug-ins.

(Later on we will be adding a proper plug-in manager with the ability to download and install plug-ins separately.)


Visual Studio Test Tools Enhancements

Visual Studio 2010 Beta 1

Gallio v3.1 now includes support for Visual Studio 2010 Beta 1 out of the box.


Data-Driven Test Results (Fixed)

Gallio now correctly displays the results of data-driven tests like MbUnit row tests.

In the following screenshot you can clearly see both test results of a data-driven test.  Previous versions of Gallio would only show one result.


AutoCAD Integration

In addition to the new preference panel, we have made a couple of minor enhancements to the AutoCAD testing experience.

Debugging AutoCAD Tests

With Gallio v3.1, you can now debug your AutoCAD tests using Icarus just like any other tests.

Previously debugging did not work because the Visual Studio debugger is unable to attach to a process that uses fibers (like AutoCAD does).  So Gallio v3.1 launches AutoCAD with the debugger attached from the start and it works.

We also support zero-installation execution of AutoCAD tests.  This means you can run tests on a machine with AutoCAD installed without having to separately install Gallio as long as the files have been copied to the local disk somewhere.

TeamCity Integration

Gallio v3.1 now automatically detects when it is being run by TeamCity and enables the TeamCity test runner extension.  This means you do not need the following in your build scripts any more: "TeamCityExtension,Gallio.TeamCityIntegration".

There have also been some fixes to more correctly output test results from parallelizable tests.


We have invested some time improving the performance of Gallio and MbUnit v3.1 in several key areas.

Startup Time

Gallio v3.1 is much faster to start up than previous versions of Gallio.

Much of this gain comes from three important changes.  First, the new plug-in model in Gallio exposes more declarative metadata up front so that we can defer loading assemblies until they are actually needed.  Second, once we have identified all of the plug-ins that are installed, we cache the composite metadata for subsequent runs.  Third, we generate XmlSerializers ahead of time.

On my slow laptop Icarus startup time dropped from over 20 seconds to about 2 seconds.  These startup time improvements also carry over to the Visual Studio and ReSharper integration.

Memory Usage

Gallio v3.1 uses significantly less memory when running multiple test assemblies than it did in v3.0.6.

Older versions of Gallio used to keep all of the test assemblies loaded in memory for the duration of the test run.  When running dozens of test assemblies together at once (say, during a continuous integration build) Gallio would end up consuming quite a lot of memory in proportion to the number of test assemblies.

Now Gallio v3.1 loads and unloads each test assembly before moving on to the next one.  This change improves responsiveness and keeps memory usage in check.

Debugging and Profiling

One of the more perplexing performance problems we addressed in MbUnit v3.1 was the performance of the debugger.

In older versions of MbUnit v3 it would sometimes take half a second or more to single-step while running a test in the debugger.  The problem is that the stack was just too deep.  During a typical test run, the stack could be 160 frames deep!

Now MbUnit v3.1 is more carefully tuned to minimize its stack depth.  We have reduced the effective stack depth by a factor of 5 so single-stepping is zippy and responsive just like it should be.

One happy side-benefit of reduced stack depth is that it significantly easier to figure out what it going on when running tests with a code profiler.

.Net 4.0 Support and x86/x64 Processor Architecture Enhancements

Gallio v3.1 includes out of the box support for .Net 4.0.  We also improved our support for running tests in different processor architectures.

One key change is that Gallio runs each test assembly in its own process by default.  Gallio automatically detects the required .Net runtime version and processor architecture by examining the assembly metadata.  You can run tests designed for different .Net runtimes or processors architectures side-by-side if you like.  All you need to do is compile your test assemblies with the right options.

It just works.


We have worked hard to improve the robustness of Gallio v3.1 while adding new features.

UAC Privilege Elevation on Vista and Windows 7

Did you notice that the Control Panel application displayed the UAC shield icon?  Here it is again:


The shield indicates that Gallio has detected that the Control Panel is running in a lower privilege environment and that certain settings that have changed require elevation.  Of course when you click on the button you will receive a UAC prompt after which Gallio will carry out the required operation in an elevated context.

ReSharper Integration Bug Fixes

We have spent some time improving the robustness of the ReSharper integration.  It used to throw up annoying exceptions here and there and occasionally would crash.  Hopefully this is all a thing of the past.

Here's some bad code that used to cause Visual Studio to crash but not anymore:

public class A : B

public class B : A

Gallio.Utility Power Tool

Gallio.Utility.exe is a new command-line application included with Gallio to perform various functions related to maintaining a Gallio installation.

These are the supported utility commands at this time:

  • ClearCurrentUserPluginCache:  Clears the plugin cache of the current user.
  • ResetInstallationId:  Resets the installation id.  The plugin list will be refreshed the next time a Gallio application is started.
  • Setup:  Installs or uninstalls components.
  • VerifyInstallation:  Checks for runtime installation errors.

More Goodies


  • MbUnit assertions offer EqualityComparison<T> and IEqualityComparer<T> overloads.
  • Parallelizable tests run with the correct number of threads and start up immediately without requiring any prior "warm-up" period as was seen in earlier versions due to some bad logic.
  • Support the use of Assert.Inconclusive and Assert.Terminate within Assert.Multiple blocks.
  • Contract verifiers can be "static" in which case they behave like static test factories instead of like dynamic test factories.  In a "static" contract verifier, each individual verification will appear as a separate test in the test runner.


  • Upgraded to csUnit v2.6.


  • Upgraded to NUnit v2.5.2 but retained support for NUnit v2.4.8 also.


  • Rewrote most of the MSTest integration to be faster and more robust.

Command-line tools:

  • Gallio.Echo.exe supports wildcards.
  • The NAnt, MSBuild and PowerShell tasks support specifying the Verbosity.
  • Echo support a /no-progress switch to disable progress reporting.


  • Icarus now has a "Recent Projects" menu.
  • Icarus test tree is a bit faster.
  • Lots of Icarus bug fixes.
  • New error dialog.
  • Support keyboard navigation.
  • Disabled the watchdog timer during debugging runs so you can debug at leisure without worrying about the test runner killing the process prematurely.

Test Reports:

  • Support embedded HTML content and Flash videos.
  • Workaround issues when clicking links to attachments in IE due to the Local Machine Zone Lockdown.
  • Display test kind icons in the report.
  • Added a condensed text report type.
  • Test output is normalized before writing it to the log.  This is to catch problems like attempting to write a null character or BOM into the report.
  • Test framework nodes are no longer emitted.

Debugging and Code Coverage:

  • Gallio launches the debugger with the "Managed and Native" debugging engine selected so that you can debug into native code from managed code.
  • NCover v1.5.8 works on x64 but only supports running tests in x86 mode.
  • Using NCoverExplorer or NCover.Reporting to merge NCover coverage reports when running test assemblies in separate processes.


  • Lots of bugfixes.


  • Gallio now supports zero-installation TestDriven.Net test runs with recent beta builds of TestDriven.Net.  I expect Jamie will say more about this feature soon...


  • MbUnit.Pex no longer included.  The Pex project has taken over the maintenance of this extension.


  • Added support for CruiseControl.Net v1.4.4 and more recent versions.


  • Yann performed a massive documentation sweep to clean up formatting.
  • Switched to Sandcastle instead of NDoc 2 Alpha.


  • Brand new test framework extension API.  Only 5 methods to implement.
  • Early Transition to a message-based protocol for test framework integration.
  • Massive refactoring of namespaces and interfaces.
Technorati Tags: ,

Thursday, July 30, 2009

Toward New Horizons

The short story is that I am now between jobs.

The long story is that I have left Ingenio / / AT&T Interactive and will be joining Google in late September.  Yes that's the same Google I turned down last year; my priorities and perspective have changed.

I am looking forward to living in Mountain View biking distance from work and walking distance to yuppie downtown amenities.  I also look forward to joining any number of Google's social and volunteer organizations.  I have pretty much decided that, as soon as I figure out how, I will find a way to teach the fine art (and joy) of programming and computer science to children, adult students and peers.

Now I have two months break!  Feels a bit like summer vacation.  Nothing planned but possibilities and opportunities abound everywhere.  I'll probably sing, play music, learn pastels and paint, work on Open Source, take a dip in a warm ocean someplace, and relax.

My last day at my old job was Friday the 24th so I am still getting over the early morning nagging sensation that I have to be someplace.  I'm sure that my coming week at Lark Camp in Mendocino will fix that.  :-)

Sunday, July 19, 2009

Coming Soon: Gallio and MbUnit v3.1

The next release of Gallio and MbUnit is just around the corner.  I need to work on a proper write-up of all of the new stuff but here are a few highlights:

  • Significantly faster start-up time.
  • Embedded videos in test reports including built-in screen recording.  (Try playing with the Capture class.)
  • Gallio can run RSpec tests via IronRuby.
  • New Control Panel application for tweaking global settings.
  • More MbUnit assertions and attributes for manipulating data and the environment.
  • More Icarus GUI goodness.
  • Better API documentation.
  • Much simpler story for test framework adapters and test runners.
  • Gallio can run tests in arbitrary files including tests written in non .Net languages given a suitable framework adapter (which you could write in a day).

The final release of v3.1 will probably happen within the next two weeks.

We're looking for beta testers.

To help us out, try out one of the recent v3.1 builds from:

Please report any suggestions or issues you find here:

You can also join our developer mailing-list:

API documentation:


Technorati Tags: ,

Friday, June 5, 2009

Upcoming Events

I will be attending ALT.Net Canada in Vancouver, BC from June 12th through 14th.  My plan is to follow that up with a week-long vacation and visiting friends and family in Ottawa, Toronto, Montreal or Kitchener-Waterloo.

I rather desperately need a vacation...

As for Gallio, I am currently investing most of my spare time into adding support for test files that are not .Net assemblies.  When I am finished, Gallio will be able to run tests written in other languages such as C++, Ruby, various XML-based DSLs or anything else that is represented as a file of a type for which a test framework plugin has been installed.  As a proof of concept Gallio v3.0.7 will include support for RSpec by way of the Dynamic Language Runtime.

Friday, May 29, 2009

Announcing Gallio and MbUnit v3.0.6 Update 2.

Today we are releasing Gallio and MbUnit v3.0.6 Update 2.  This is mainly a bug fix release.

Download here:

Documentation here:

Earlier release notes: v3.0.6, v3.0.6 update 1, all versions


  • [New!] Added [Parallelizable(TestScope.All)] and [Parallelizable(TestScope.Descendants)] to recursively mark tests as parallelizable such as all tests within a fixture or all fixtures in an assembly.
  • Fixed "test was orphaned" errors involving Parallelizable tests.
  • Upgraded adpater to v1.1 RTM. 
  • Added support for running NCover v1.5.8 as a 32-bit process on 64-bit machines.
  • Fixed a regression that was causing test reports not to be generated when canceled.
  • Fixed ClassCastExceptions in the ReSharper runner.
  • Fixed missing hotfix lightbulbs in the ReSharper within test files.
  • Fixed red strikethrough that would appear in the Unit Test Session window when running MbUnit tests declared in subclassed test fixtures.
  • Fixed a regression in the AutoCAD test driver.
  • Improved the handling of parallel tests so that TeamCity test statistics make more sense.
  • Improved the installer to support in-place upgrades.
  • Fixed a regression that occasionally would prevent dynamic tests from running.
Technorati Tags: ,

Thursday, May 28, 2009

Registry Weirdness, UAC and the Vista Virtual Store

It appears that two different can see a different view of the registry content.  I seem to recall seeing mention about registry values potentially being seen differently by elevated and non-elevated applications when UAC is active.

In this case, ProcessInvocation.exe sees the following value for a particular key:  (which is wrong!)


But regedit.exe sees the following value:  (which is correct!)

C:\Program Files\Gallio\bin\TDNet\Gallio.TDNetRunner.dll

The first value was used for local development of Gallio v3.0.6 but I deleted that value!  In fact I deleted it a week ago and I don't think I've recreated it since (because Gallio v3.0.7 uses different keys).

The second value was set by the Gallio v3.0.6 installer (uses the old key).  This is the value I expect to see globally.  All interesting applications were closed at the the time of installation.

So why are some applications seeing the first value and other applications seeing the second value?

No, this is not a simple question of refreshing or shutting down applications.  I have shut them both down and tried again and the weird view remains persistent!

Next up, reboot.  Argh.

After the Reboot...

Same behavior.


Here's what I found when I searched the registry for the incorrect value:  (SID masked)


Whoa.  So at least I'm not dreaming.

The UAC Virtual Store

On Vista, normal users are forbidden from writing to certain folders (like %ProgramFiles% and %SystemRoot%) and into the HKEY_LOCAL_MACHINE part of the registry.  Even local administrator users are forbidden from writing into these folders, unless elevated.

Well, not quite.  As a compatibility feature, instead of generating an error, a write by a non-elevated application running as a local administrator may be redirected to a Virtual Store on the file system or in the registry as appropriate.  The Virtual Store functions as a shallow per-user overlay of protected parts of the file system and registry.  Each user has a separate Virtual Store from all other users so misbehaving old-style applications can keep pretending they have write access to places they don't but the impact remains local to the user.

The file system Virtual Store is in %LOCALAPPDATA%\VirtualStore.  Here are a few things that mine contains:

  • _vimrc files
  • *.pyc files created by GNU Solfege
  • Reflector.cfg
  • Trillian crash dumps and user data (this explains a few oddities I've seen!)

The registry Virtual Store is in HKEY_CURRENT_USER\Software\Classes\VirtualStore.  Here are a few things that mine contains:

  • Old obsolete registry keys I created for debugging that got me into this mess.
  • A EULA key for Acrobat Reader.  (Nowadays I use FoxIt Reader.)
  • Configuration for a few audio codecs.
  • An MRU list for DirectDraw (weird).
  • A flag set by my 3G wireless software.
  • Configuration for OpenVPN.

What Actually Happened

Once upon a time, I ran a little script without elevation to create some registry keys for local development.  Since the script was not elevated, the new registry keys were created within the Virtual Store.

Later on, I ran a script to delete these keys.  But in the interim I had changed the script to run with elevation.  Because it ran with elevation it did not see the keys in the Virtual Store so it left them there.

Then I installed Gallio v3.0.6 which, being an installer, created some new registry keys with elevation in the expected location.

When I tried to run a test, the ProcessInvocation.exe component of TestDriven.Net enumerated these keys in the registry, but without elevation.  Consequently it saw the old keys in the Virtual Store and got extremely confused.



Normally the Virtual Store on Vista is not a problem.  Actually it's a pretty clever solution to a serious compatibility problem.  However, if you ever run into issues like mine you might just need to learn about it so that you can delete or repair the magic virtualized content if needed.

More info:

Technorati Tags:

Vista UAC and Dog Food

A few days ago I re-enabled Vista UAC on my development laptop.


I was developing a few features for Gallio that required being able to perform privilege elevations on Vista.  So unless I got my act together to play nice with UAC, those features were just not going to work!

With reluctance I re-enabled UAC.  Sometimes dog food, while nutritious, contains unpleasant additives.


Here's one of the new features from Gallio v3.0.7 in trunk:


When certain settings are changed, we show shield buttons:


And of course when clicking on one of those buttons we'll get the standard UAC elevation dialog.  I can't show you that because by design UAC blocks out other applications including SnagIt.

How it works (very briefly)

To display shield buttons, set the Button's FlatStyle to System and then send the BCM_SETSHIELD message to the button using SendMessage.  (Or borrow my ShieldButton class.  Ignore the Mono bits.)

Before performing privilege elevation, check whether it is even needed for the current user.  Here's one way.  A better way might be to examine the Win32 ProcessToken directly.

public static bool CurrentUserHasElevatedPrivileges()
    WindowsPrincipal principal = new WindowsPrincipal(WindowsIdentity.GetCurrent());
    return principal.IsInRole(WindowsBuiltInRole.Administrator);

To perform privilege elevation, first split the code into two parts: non-privileged and privileged.  The privileged part will have to run in a separate process one way or another.  Then decide how to perform the elevation using one of these options.

  1. Use the COM elevation moniker as in the CoCreateInstanceAsAdmin example to instantiate a COM object within an elevated process provided by the system.  This method is convenient but it requires that you have registered your privileged code as a COMVisible managed class ahead of time.  Consequently, we do not use this method in Gallio which is expected to be xcopy deployable with no prior installation of components required (besides copying files).
  2. Create a separate executable process that contains the privileged code.  Be sure to embed an appropriate application manifest like the following either using the Visual Studio manifest build

    option or mt.exe.

    Our incantation of mt.exe looks a bit like this: "mt.exe -nologo -manifest Elevated.manifest -managedassemblyname:Gallio.Host.Elevated.exe -nodependency -outputresource:Gallio.Host.Elevated.exe;#1".  Keep in mind that if you use mt.exe on a signed assembly that the signature will be invalidated and the assembly will need to be re-signed with "sn.exe -R ...".  You might consider delay-signing the assembly at first, then merging the manifest, then re-signing the assembly.  This way you can tell whether you're working with an assembly with a proper manifest because the original delay-signed copy will fail validation (normally) but the patched and re-signed copy will be good.

    Here is the Elevated.manifest file that we use for Gallio.Host.Elevated.exe:

  3. <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
      <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
      <description>Provides out of process hosting for Gallio components that require privilege elevation.</description>
      <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
          <requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
            <requestedExecutionLevel level="requireAdministrator" uiAccess="false"/>

    Launch the privileged process directly being sure to set a few extra properties:

    var processStartInfo = new ProcessStartInfo("PrivilegedApp.exe");
    processStartInfo.Verb = "runas";   // optional if you embedded a manifest
    processStartInfo.UseShellExecute = true;  // mandatory
    processStartInfo.ErrorDialog = true;  // mandatory
    processStartInfo.ErrorDialogOwnerHandle = ownerForm.Handle;  // recommended

Ok, I just glossed over a million little details...

If you are ever in a position to have to perform privilege elevation in a managed application, I highly recommend reading the relevant MSDN articles three times over.

Technorati Tags:

Tuesday, May 19, 2009

Gallio on Visual Studio 2010, Redux

After the Microsoft PDC of 2008, I released a variant of Gallio v3.0.5 with support for the Visual Studio 2010 pre-release bits.

So today I have been working on getting Gallio v3.0.7 running on Visual Studio 2010 Beta 1.

The migration has been pretty easy for the most part.  With the PDC bits, I had a hard time producing a build because I had to install all sorts of tools inside the PDC VM and deal with rather unstable bits.  With the Beta 1 release, the process is much smoother since I can just install the framework on the build server.  Visual Studio 2010 Beta 1 is working ok although I have filed a couple of bugs already.

Unfortunately since not all contributors to Gallio will be running VS 2010 anytime soon I will have to maintain a parallel set of project files and solutions.  I guess I will be maintaining *.vs2008.csproj and *.vs2010.csproj files side-by-side for a little while.   I wish Microsoft would invest some effort in providing a smooth backward-compatible upgrade path for projects to enable developers on newer tools to work with projects created using older tools without having to actually migrate them over.  (This is my 3rd Visual Studio upgrade and I'm getting really tired of this story.)


The first pre-release installer should be available later this week.

Looks promising so far...


Technorati Tags: ,

Friday, May 8, 2009

NDepend v2.12 Rocks.

I have used NDepend on and off for the past couple of years.  It has never been an everyday thing, but whenever I have an itch to find out just how convoluted my code dependency graph has become, NDepend has been there for me.

Full disclosure: Patrick Smacchia sent me a free professional license of NDepend to play with some time ago.  To be honest, I didn't really need the license because I was already using the OSS edition of NDepend at the time.  I just think this is a cool tool.  :-)

Download and Installation

Installing NDepend is pretty easy.  Just visit the NDepend download page, type in your email address for the OSS or trial version or your license code for the progressional addition, then download the NDepend ZIP file.  Extract the ZIP someplace useful (like C:\Program Files) then pin a shortcut to VisualNDepend.exe to your Quick Launch bar.

Tools Integration

Now launch VisualNDepend.  To enable Visual Studio and Reflector integration click on the button in the UI.  A couple more clicks and you're done.



I have to say, unboxing NDepend is very slick!  There are a bunch of links to little screencast demos to explain how stuff works.  I have to admit I have tool envy here.  I wish my tools could help the user along like this.

That said, I do wish NDepend (and Reflector also) had an MSI installer flavor.  It's harder to explain to others how to extract ZIPs and create shortcuts than to just ask them to run through a standard installer process.

Dissecting Gallio with NDepend

After installing the NDepend add-in for Visual Studio, I opened up the Gallio solution.  There's a lot of stuff in here, so for this exploration I'm going to start by looking at the dependencies within Gallio.dll.


It's been a few months since I looked at this so I'm cringing here...  What will I discover?

Up pops an instance of Visual NDepend with this dialog listing all of the assemblies in my solution.  Pretty slick.  I don't have to create a new NDepend project from scratch.  On the other hand, I'm only interested in Gallio.dll and I did right-click specifically on that project in Visual Studio so I will remove everything else.


NDepend Report

The next thing that pops up is an NDepend report.  It shows up in my default web browser (FireFox).  I think it might be cooler if it appeared inside of the Visual NDepend application itself using an embedded web browser (eg. System.Windows.Forms.WebBrowser) but this report is pretty useful anyways.

Bunch of metrics regarding both the source code and the compiled binaries.  Looks like Gallio.dll consists 66% of comments.  Heh.  There's all of the XML documentation!


One thing to keep in mind when reading the report is that not all of the information is equally useful.  NDepend computes lots of different metrics to help you find hot spots.  Of course, if there's nothing really wrong then what it finds might not be very interesting.  You need to read the report intelligently.

Top 10 Methods to Refactor?

For example, here are the top 10 methods in Gallio.dll that I should refactor, according to NDepend.


Whoa, so the top 2 are compiler generated and most of the others are pretty simple methods.  Based on the criteria used (see CQL below).


The main thing I'm hitting up against is the IL nesting depth and number of variables.  None of these methods have a particularly troubling cyclomatic complexity except for CreateFilteredClosure which has a CC of 20 but can't really be improved much more given what it does.

So in sum, I guess I'm doing ok!  Cool.  However I bet if I threw this at some production code of my employer, we'd find some interesting things to talk about.

Let's keep digging.

Finding Large Methods

Out of the box, the NDepend report shows a summary of large methods.  This is worth paying close attention to.

Here are the 10 biggest methods in Gallio.dll.


I'm amused that FindMiddleSnake made the list.  That is one monster method!  Unfortunately I can't really do much to improve it because of the nature of the algorithm.  Calculating diffs is hard stuff!  The topological sort is in a similar category.

However, the PluginCatalog.ApplyTo and DefaultRuntime.VerifyInstallation methods are long for no good reason.  So with a little help from ReSharper's Extract Method refactoring here's what ApplyTo now looks like:


Overlap with FxCop

Some of the metrics that NDepend computes out of the box produce similar results to those that could be obtained using FxCop.  This is rather interesting since NDepend's CQL language actually has the potential to be much more expressive and configurable than the FxCop verifications, if you like.  However there can be some quirks.

Here are some methods and constructors that appear in abstract classes that were marked "public" but that NDepend thinks could be "protected".


The NativeCodeElementWrapper, NativeMemberWrapper and NativeFunctionWrapper constructors I understand (fixed!), the others not so much.  TestTypePatternAttribute is a public attribute class whose constructor really does need to be public because it is public API although NDepend doesn't know that.  The NativeCodeElementWrapper.Target property is only used internally in Gallio.dll so it could be made protected or internal if desired.

What it comes down to is that you still have to use your head when you interpret the data.  It's worth the effort though!

Finding Inadvertent Coupling

Of all of the many metrics and views provided by NDepend, this one is by far my favorite.  It shows the afferent coupling (incoming dependencies) in blue, efferent coupling (outgoing dependencies) in green, and mutual coupling (both incoming and outgoing dependencies) in black.  The following chart is displaying coupling among namespaces.


Oh no!  There's some black in there.  The black means that some code in one namespace is using code in another namespace which also happens to use code in the former.

Namespaces are frequently used to separate subsystems from one another.  Coupling among namespaces can indicate one of the following problems:

  1. One or more classes are in the wrong namespace and should be moved.
  2. One or more classes have dependencies on the wrong things and should be refactored to use dependency injection or use inversion of control to access foreign services.
  3. The namespaces are not very cohesive and the subsystems they represent should be restructured to be more tightly encapsulated or have fewer responsibilities.
  4. There are common services partially defined in both namespaces that should be extracted and moved elsewhere.

To take a deeper look I just double-click on one of the black squares to drill down.


Ah ha!  It looks like the Gallio.Model.Diagnostics.ExceptionData class is being used by several of the classes in the Gallio.Runtime.Logging namespace.  This is bad.

The Runtime subsystem is the lowest tier of Gallio and provides the core foundational services needed to get Gallio up and running.   The Model subsystem is one of the tiers above the Runtime and its job is to define the test object model.  What we have here is a cyclic dependency that crosses tiers.

In a tiered architecture, dependencies should always flow from one tier down to the ones below it and never the other way around.  If you let dependencies flow both ways then you may quickly find yourself enmeshed in a bowl of spaghetti!

It looks like in order to fix this problem, I'm going to have to rearrange a few of these dependencies.  The upside is that the structure of the system will be cleaner when I am done.

CQL: A Recipe for Analysis

NDepend provides a code query language called CQL which enables all sorts of fancy analysis.  In addition to answering various questions interactively, you can incorporate NDepend CQL constraints into your build process such that the build will fail if a constraint is violated.  By using CQL as part of a continuous integration process you can validate system design conventions early and often.  For example, you can add a CQL constraint to detect when cyclic dependencies are accidentally created across tiers.

To be honest, I have not delved into CQL very much myself.  Using it as part of the build process looks like it could be a very useful tool for managing large teams of developers.  (I just need to find more time to do architecture work...)


NDepend is a good tool that repays careful analysis.  It won't fix your system design defects for you but it will help you find the trouble spots.

As a result of writing this post, I fixed a few big methods and performed a major refactoring of Gallio's primary namespaces guided mainly by NDepend's dependency matrix view.  This is not the first time I have used NDepend to improve Gallio.  Here is how that dependency matrix is looking now:


All in all, I feel much better now!