Problems running unit test in Visual Studio

When I run the Release build of my (VS 2008 .NET) unit tests, I get the following exception:

System.IO.FileLoadException: Could not load file or assembly 'arcVegaORM, Version=1.0.3856.24327, Culture=neutral, PublicKeyToken=0dd85ae1d99ddbee' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040).

I do not get the exception when I run the debug build tests.

The unit test framework is copying an old version of the 'arcVegaORM' assembly into the TestResults\Out folder. I do not know where it gets the old version from - it does not match the version in the proj开发者_JAVA技巧ects bin\Release folder.

I am beginning to think there is a bug with the VS.NET unit test framework, and that it has the old version cached.

One thing to check would be the GAC (global assembly cache). You can do that by opening windows explorer and typing in c:\windows\assembly in the address bar (assuming your OS is installed on the c drive).

It may be getting the assembly from the GAC instead.

Other things to do would be to clean the solution and do a rebuild all to make sure you don't have any old assembly references.

Also, if this is a web application, it always helps to stop IIS and then go clean out the C:\WINDOWS\Microsoft.NET\Framework\framework_version\Temporary ASP.NET Files folder.

TIP
The other thing to use is the .Net reflector. You can see what dependencies the assembly has, and you need to make sure they are all present on the target machine.

The way to do this is to install the reflector, then run it, then drag your assembly into it and you can see the assembly's dependencies. You need to make sure every one of those dependency dll's is available on the target machine, and also, the version number must be correct if they are signed assemblies.

TIP2
Note that sometimes you get issues where assembly A is bound against version xxx of assembly B, and assembly C is bound against version yyy of assembly B. In other words, 2 different assemblies in your project are bound against different versions of the same assembly. This is the modern day version of DLL Hell. The way to hack around this is to use assembly rebinding. You can read about it here.

I have now found a post on the MSDN Forums - it seems to be a bug:

http://social.msdn.microsoft.com/Forums/en-US/vststest/thread/af530ba8-1299-4113-a5fe-4f6b009fa599

!! If I turn off code coverage, then the tests run fine !!