A place for spare thoughts


MSTest and SEHException

Filed under: Unit testing — Ivan Danilov @ 18:10

Corporate standards sometimes are evil thing, you know. And so on one of my work projects I’m forced to use MSTest.

So today I’ll describe the history of one problem I faced with Microsoft testing framework.

So, I’ve been writing some unit tests happily when strange message from next test run made me crazy:
‘Test method Test threw exception:  System.Runtime.InteropServices.SEHException: External component has thrown an exception..’

Without any clues what is the cause. Googling on the problem gave only not very helpful complaint about the same problem. After some time of trials I was able to narrow problematic case to the following:

public class FailingTest
    public void Test()
        var mocks = new MockRepository();
        var someService = mocks.Stub<ISomeService>();
        someService.Expect(s => s.Method()).IgnoreArguments().Return(null);

ISomeService is some interface from third-party vendor placed in it’s own assembly (let it be ‘Interface.dll’ for convenience) referenced from test project. MockRepository is part of Rhino Mocks (I’m just too lazy to rewrite code again without it, the problem is not specific to Rhino Mocks in any way).

But could it be some my error? I decided to check — referenced nunit.famework.dll, replaced [TestClass] with [TestFixture], [TestMethod] with [Test] and run. Success was the result. Well, something wrong with MSTest not my test code.

Maybe problem is within VS test runner? But ReSharper runner and VS integrated runner shows the same… Nevertheless I tried mstest.exe command line also. Same failure. Hmm…

It turned out that MSTest saw that Interface.dll has reference to some other assembly, Other.dll and tried to load it when testing. Why does it do such thing is mystery, but it does. If you put Other.dll to references of our test project – test will succeed. If you have no reference and no Other.dll accessible to the test – you’ll have adequate error message about MSTest can’t load required assembly named Other.dll. But (the most frustrating case!) if you have no reference to Other.dll but have it accessible (for example placed in the bin\Debug of test project) — you’ll have that terrible SEHException without any information.

The scenario is not as theoretic as you could think. Imagine TFS build server (God save us from it). With default settings it will put every resulting artifact (compiled assemblies, debug symbols, referenced assemblies that have Copy local=true etc) to the same Binaries folder. And if you have complex solution where Other.dll is actually used somewhere – it gets copied to Binaries. And if test project doesn’t have reference – you’ll have SEHException. Ghrrrr!




Filed under: wpf — Ivan Danilov @ 16:22

Well, it’s a shame for me but until today I wasn’t aware of BooleanToVisibilityConverter existence in the WPF library. And wrote custom classes with almost the same code again and again.

This class supports two way conversion and could handle bool and Nullable<bool> as its input.

Hope this will save time for someone who like me tries to invent a wheel again 🙂


Missing WPF menu items in Visual Studio

Filed under: VisualStudio, wpf — Ivan Danilov @ 12:21

Probably you as me often were confused by the fact that some useful menu items are absent in the Add New Item in Visual Studio when you are working with Class Library.

When adding item into WPF Application you have this menu:

But with Class Library you have only this:

It turns out that you should be adding not Class Library if you want to work with WPF features but rather WPF Custom Control Library project. And then you will have all you need. I find it myself while reading Karl Shifflett’s article. Thanks, Karl! 🙂

Everything is great. Except the fact that you could already have Class Library with hundreds files inside. What should you do in this case? Replacing project and adding all your files again not seems like a good idea. So lets find out what is the difference between the project files from Visual Studio’s point of view.

I’ve created new solution, added there WPF Custom Control Library and plain old Class Library. The diff between the WpfControlLibrary1.csproj and ClassLibrary1.csproj you could see below:

The interesting point is highlighted. Its the only significant difference. In order to have XAML-related menu items in your project you have to paste this line to your *.csproj file:



Blog at WordPress.com.