Monday, July 22, 2013

Thanks for Saying Thanks!

A few months back, I received a nice email from the folks at SEP for my blog notes on SEP TeamWorks. It’s nice to know that someone is paying attention:

My name is Adam Scroggin and I am the product owner for SEP TeamWorks.  I came across your blog today ( and just wanted to say thanks for the write ups you did.  If there are any features you want added, feel free to contact me.

Keep on writing! Adam

Adam Scroggin | Software Engineering Manager

Appreciate the feedback, Adam. I have a few more blog posts to add regarding using the tool with TFS. I’m sure you’d be happy to learn that teams within my organization continue to adopt the tool for its ease of use.

Thursday, July 18, 2013

Unhandled exceptions in WPF applications

When it comes to unit testing there are a few areas of the application where I am comfortable not getting coverage. There are some areas of the application, typically in the UI, that are generally difficult to unit test but can be easily verified if you run the application manually. There are a few other places where testing is very difficult to validate such as the global error handler for your application. For the global error handler, you have to live with some manual testing and assume you’ve got it right.

Today I discovered one of my assumptions about the global error handler was completely wrong. My app was crashing and displaying error messages; I assumed it was crashing, logging to a file and exiting politely. It was not. And as always, I’m writing this as a reminder for you and myself.

As most know, the best place for a global exception handler is to attach an event handler to the DispatcherUnhandledException event of the application. It’s important to set the the Handled property of the UnhandledExceptionEventArgs to true to prevent the app from crashing.

However, this will only capture exceptions on the UI thread. All other exceptions will look for an event handler on that threads’ stack. If no event handler is found it will bubble up to the AppDomain’s handler. So to capture these exceptions you should add an event handler to the AppDomain’s UnhandledException event.

In contrast to the UnhandledExceptionEventArgs, UnahdledException does not have a Handled property. I assumed that the purpose of this handler was so that we could log the error and go on about our business. As it turns out, if your code reaches to this event handler it is completely unrecoverable. As in Bill Paxton, “Game over, man!” – your app is going to crash and show a nasty error dialog. The only way to prevent the dialog is to use Environment.Exit(1);

namespace MyApplication
    public class MyApp : Application
        private static ILog Log = log4net.LogManager.GetLogger(typeof(MyApp));

        protected override void OnStartup(StartupEventArgs e)

            // handle all main UI thread related exceptions
            Application.Current.DispatcherUnhandledException += DispatcherUnhandledException;

            // handle all other exceptions in background threads
            AppDomain.CurrentDomain.UnhandledException += AppDomainUnhandledException;

        void DispatcherUnhandledException(object sender, System.Windows.Threading.DispatcherUnhandledExceptionEventArgs e)
            // prevent unhandled exception from crashing the application.
            e.Handled = true;

            Log.Fatal("An unhandled exception has reached the UI Dispatcher.", e.Exception);

            // shut down the application nicely.

        void AppDomainUnhandledException(object sender, UnhandledExceptionEventArgs e)
            var ex = e.ExceptionObject as Exception;

            Log.Fatal("An unhandled exception has reached the AppDomain exception handler. Application will now exit.", ex);

            // This exception cannot be handled and you cannot reliably use Shutdown to gracefully shutdown.
            // The only way to suppress the CLR error dialog is to supply "1" to the exit code.

If you want to gracefully exit the application regardless which thread created the Exception, the recommended approach is to:

  • Handle the exception on the background thread.
  • Marshal the exception to the UI thread and then re-throw it there.
  • Handle the exception in the Application.DispatcherUnhandledException handler.

There’s no easy way out here and means you need to fix the offending code. My recommendation is to use the AppDomain UnhandledException as a honey pot to find issues.

High five.

submit to reddit

Monday, July 08, 2013

DeploymentItems in Visual Studio 2012

A frequent concern with writing unit tests with MSTest is how to include additional files and test data for a test run. This process has changed between Visual Studio 2010 and 2012 and it’s become a source of confusion.


With Visual Studio 2010 and earlier, every time you ran your tests Visual Studio would copy all files related to the test to a test run folder and execute them from this location. For local development this feature allows you to compare results between test runs, but the feature is also intended to support deploying the tests to remote machines for execution.

If your tests depend on additional files such as external configuration files or 3rd party dependencies that aren’t directly referenced by the tests, you would need to enable Deployment in your testsettings and then either specifying the deployment items in the testsettings file or marking each test with a DeploymentItemAttribute.

What’s changed in Visual Studio 2012?

Visual Studio 2012 has a number of changes related to the test engine that impact deployment. The most visible change is that Visual Studio 2012 no longer automatically adds the testsettings file to your solution when you add a Test project. The testsettings file can be added to your project manually, but it’s generally recommended that you don’t use it as it’s for backward compatibility and not all features within Visual Studio 2012 are backward compatible. Microsoft Fakes for example are not backward compatible.

The biggest change related to deployment is that Visual Studio 2012 tests run directly out of the output folder by default. This adds a significant speed boost for the tests but it also means that if your tests are dependent on files that are already part of the build output, you won’t need to enable deployment at all.

Another interesting change is that if you include a DeploymentItemAttribute in your tests, Deployment will be automatically enabled and your tests will run out of the deployment folder.

More information can be found here.