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.
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:
This forces VS to generate the file. I then had to copy that file manually to the directory it was looking for it in:
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.