Visual Studio could not load file or assembly; maybe cached?

Question

When I run unit testing to serialize to an xml file, I keep getting error message:

Could not load file or assembly 'Company.Fin.Bank.Common.XmlSerializers.dll, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.

I guess Company.Fin.Bank.Common.XmlSerializers.dll may be in cache somewhere but it is impossible to find this dll, even though i don't need that dll. I want to remove it. But where can i find it? is it possibly in a cache? if yes how can i clean the cache from VS? This problem is very new to me.

What a weird part is that i used another laptop (win 7) to run the unit testing, there is no error message i got - it worked. but when i used my own laptop (win 8) i keep getting error message. I have no idea why.

I hope to find solution from you. Your help means alot. Thanks!!!

Answer 1

That assembly is dynamically generated by the framework (XMLSerializer)

In .Net implementation, the XmlSerializer generates a temporary assembly for serializing/deserializing your classes (for performance reasons).

Also, this may be normal behavior - is it stopping your application from running?

Answer 2

even though i don't need that dll

Visual Studio will usually remove unneeded DLLs. Typically this is caused by dependencies (which are harder to keep track of).

I want to remove it.

Check in the References of the project in the Solution Explorer. If any of them have a yellow triangle that means they can't be found (the project may still compile and run if you aren't actually using that reference).

is it possibly in a cache?

As Daniel Kelley mentioned C:\Windows\assembly and C:\Windows\Microsoft.NET\assembly are where the global assembly cache is located. If it isn't there check the Hint Path of the reference (it will show up in Properties).

Good luck finding your reference, keep in mind that you need not only the actual DLL but all of its used references in most cases. Also a decompiler like DotPeek can be useful if you need a more discreet way of looking at references.