Unit Test Adapter threw exception: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information. – Part 2

In a previous post I wrote about a problem I had with running unittests, which resulted in an exception with the message ‘Unit Test Adapter threw exception: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.’.

This morning, on my new project, I ran into the same problem after I deleted my TFS workspace locally and got everything new from the server in a different location (a new workspace). So I looked back at my previous post, tried what I wrote there, and….. still the exception . To see if it would lead to more information, I started the tests in debug mode. And… all tests passed as usually. Strange…
I found the problem eventually. The assembly being tested was strongly named. Because we use the code coverage from the unittests, we had to re-sign the assembly tested after instrumentation and we set this up in the Code Coverage section in the testrunconfig.testrunconfig. Now what was the problem? The path to this key file was wrong! I made the mistake that the location pointed out there was a absolute location, instead of a relative location compared to my testrunconfig. So I changed this, cleaned my solution, rebuild the solution and ran the tests. And all tests passed again.

Another lesson learned. Whatch out that you don’t accidentally have absolute paths when referencing stuff which is located in your source control tree.

Local folder already mapped in workspace

I’ve got a small server at home where I also run TFS on for my personal projects and for playing around with it to try some stuff.

Since TFS 2010 Beta 2 is available I wanted to work with VS2010 and TFS 2010. As I’m just a geek who wants to play around with it at home, I didn’t plan how to do this change etc. Because I didn’t care much about the history in source control, I decided to simply reinstall my server (I was already planning to do this as I wanted to use SQL Server 2008).

All went pretty well when installing and configuring. But then yesterday I wanted to add all the source I had on my local machine to the source control. And then the probleem started.
I got the message stating that I already had a workspace mapping for the local directory. WOOPS…. And I couldn’t connect to my old TFS server anymore because I destroyed that completely .
So I hadn’t got a clue what to do, because for as far as I know, the workspace mappings were registered at the server, not locally. I already removed the source control bindings from the solution, but that was not enough. Still getting the error.
It took me quite some time to find that the workspace mappings are also cached on your local machine. I finally found the mapping mentioned in the folder C:\Users\[USER]\AppData\Local\Microsoft\Team Foundation\2.0\Cache\versioncontrol.config. I deleted it from there and I could finally add my source to source control again.

Lesson learned: Think twice before doing a format on my server and try to do some planning / impact analysis before throwing things away, even when I do it on my ‘playing around environment’.

Edit: this is the location on a Windows XP machine: C:\Documents and Settings\[USER]\Local Settings\Application Data\Microsoft\Team Foundation\2.0\Cache

Unit Test Adapter threw exception: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.

I’ve been banging my head on this error for the last hour. I tried to run a set of unittests from the project we’re currently working on. The tests worked fine.
Then I took my shelveset and for some reason the tests didn’t execute anymore and all gave the error message “Unit Test Adapter threw exception: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.”. What???

First I tried all the default actions for trying to resolve problems with running tests:
1. Clean the solution
2. Complete rebuild of the solution
3. Refresh the Test View window.
4. Closing Visual Studio and reopening the solution

Unfortunately, none of these actions had the desired effect.

Eventually I was comparing all changes made to the code in source control. What I noticed was a difference in the solution file. The following three lines were missing:

GlobalSection(TestCaseManagementSettings) = postSolution
    CategoryFile = Solution.vsmdi
EndGlobalSection


I added these lines again and it worked .

Those vsmdi files are driving me crazy sometimes. Haven’t used them for anything yet and got a lot problems of them when building and running tests (for a while Visual Studio kept adding them; at one point I had 20 vsmdi files in my solution directory).

But to make the story short, I can run the tests again and it had to do with something missing in the solution file.