views:

214

answers:

4

For about 2 weeks now, I have been unable to run any UnitTests (built in VS unit tests) for a project. Previously everything worked fine. The error message is:

Could not load file or assembly 'C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\MyProjectName.XmlSerializers.dll" or one of its dependencies.

The project references System.Xml.Serialization and uses the XmlSerializer class; just like many other classes/projects I've written. For some reason, only this project is affected. It builds fine, runs fine, I just can't run my unit tests.

I've checked the directory, and all the dlls in that directory are Microsoft dlls. The dll that it is looking for obviously is not a Microsoft dll.

Anyone have any ideas?

Edit: It apparently has something to do with using the XmlSerializer and it generating that file automatically instead of using sgen.exe. Here is a link to the MSDN article. From what I've been able to find, it has something to do with using the serializer with generics. None of the sources I've found seem to offer any way to make it actually work.

A: 

try to copy all your source files somewhere, then delete the project and try to make it from scratch. Maybe something happened with project dependencies

Nikita Borodulin
+3  A: 

First enable loader logging (using FUSLOGVW.exe from the SDK) to confirm what is not being found.

Then use Reflector on all your assemblies to find the one that is trying to load the non-existent assembly. If you find no such assembly it must be being loaded dynamically, in which case attaching to AppDomain.AssemblyResolve should allow you to identify where.

Richard
A: 

Is your computer 64bit? I got the same error when trying to run a 64bit dll with NUnit that was set to work as an x86 assembly (using corflags).

You can probably find out from the error message (use FUSLOGVW.exe lick Richard suggested).

If that is the case you can either sent the dll or NUnit to run as the correct assembly using corflags.

Dror Helper
A: 

Solution

As it turns out, the problem was with VMWare. I installed the latest version of VMWare, and it installed it's tools to debug in a VM. Something it installed or changed caused this problem. When I uninstalled VMWare, the problem went away. So, I reinstalled VMWare without installing it's debugging capabilities and the problem did not come back.

Workaround:

I still have no idea why this problem suddenly started occurring, but I found a hack to make it work.

I had to go to project properties => Build Events and add this line to the Post-build event command line:

"C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\sgen.exe" "$(TargetPath)" /force

This forces VS to generate the file. I then had to copy that file manually to the directory it was looking for it in:

"C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies"

Now it I can run my tests and step through them. The problems I have now are 1) I have to remember to copy the dll to that directory every time I change something in the classes that I am serializing, and 2) I now get a ThreadInterruptedException when a test finishes running; thus 3) I can only run one test at a time.

Not a good solution, but at least I can limp through. Unfortunately, redoing everything, as Nikita Borodulin suggested, is not an option.

John Kraft
I think Nikita is suggesting removing/deleting the *.sln/csproj file(s), create a new project/solution (same directory) and re-add the files. Maybe something goofed up along the way.
KevinRF