Upgrading CAB solution to Visual Studio 2008 and making all the tests pass

For one reason or another we’ve recently upgraded the Microsoft Composite Application Block solution to a Visual Studioo 2008 solution. The conversion appeared to succeed, but when we tried to run the unit tests we had lots of failures. I then went through trying to figure out whether these failures represented functional failings in the CAB built from this source (this would be a ‘bad thing’) Or whether they were issues with the tests.

This post details the steps required to fix all the unit tests

Expected Exception Attribute not working

The first problem seemed to be that any test that had an ExpectedException attribute failed, with the reason being that an exception was thrown… hang on… isn’t this what we wanted? Seems that the attribute wasn’t being recognised by the unit test framework (MSTest). The cause being that the test projects had a reference to the wrong version of the MSTest dll. So although Visual Studio was using MSTest 2008 to run the tests it was looking for attribute definitions in another version of the dll… Seems like this should have been picked up by the conversion wizard. Anyhow, it’s a simple fix, remove all the references to Microsoft.VisualStudio.QualityTools.UnitTestFramework and add them again making sure you get the V9.0 dlls.

AppDomain Base Directory has changed

The next issue I resolved was a little more tricky. Several tests were failing in the FileStatePersistenceService, and after some digging it looked like it was because there were lots of relative addresses being used for generating files, the files were therefore being created in the AppDomain.CurrentDomain.BaseDirectory, but then being looked for in the Environment.CurrentDirectory. In MSTest 2005 these happened to be the same location. Due to a change in MSTest 2008 they are no longer the same. This page explained the problem and a fix, which simply involves adding a line to run before the test that changes the BaseDirectory.

AppDomain.CurrentDomain.SetData(“APPBASE”, Environment.CurrentDirectory);

Namespace changes on embedded resources

The next issue was one found in ReflectionModuleEnumeratorFixture and ModuleLoaderServiceFixture. Both of these test fixtures involved dynamically compiling classes from embedded resources. (I can’t help but wonder if this is overkill for a unit test). Anyway, this was kind of hard to diagnose, the only problem being that a stream was being created from the ExecutingAssembly().GetManifestResourceStream(input), and this was returning null. After debugging and looking at what was returned from GetManifestResourceNames() I noticed that there was a mismatch in the names being looked for and those used for the embedded resources. To fix the tests I changed all the calls to compile files in the constructor to reference the correct names. This involved replacing Microsoft.Practices.CompositeUI.Tests.Mocks.Src with Microsoft.Practices.CompositeUI.Tests.Instrumentation.Mocks.Src

Last Test – LoadModuleReferencingMissingAssembly

The final test to outsmart me was the LoadModuleReferencingMissingAssembly test, this test attempts to load a module that calls out to another module that has not been included  in the ModuleInfo. An exception should be thrown when the call is made to Module.load(). However in 2008 no such exception is thrown, with execution proceeding as normal. In 2005 a FileNotFound exception is thrown saying that it can’t find the referencedAssembly. In both cases the dll is present in the output directory. At the time of writing I have been unable to fix this test, I wonder if the issue is related to the AppDomain changes, but the proposed fix doesn’t seem to work.

Any suggestions more than welcome!


About Alex McMahon

I am a software developer, interested in .net, agile, alt.net. I've previously specialised with .net 3.0 technologies like WCF, whereas now I am trying to specialise in agile development and best practice and patterns. I am obsessed with looking at the latest technologies, tools, and methods, and trying them out. I am currently employed by Rockwell Collins in the UK.
This entry was posted in .net, CAB, Composite Application Block, MSTest, testing, Visual Studio 2008. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s