Don’t ask me why I did it because I don’t have a good answer. Just because I can probably.
I have a solution with several DLL projects some of which depend on others. They all reference (via project references) a common “Library” project for instance. All of these are then referenced by the main application project. It occurred to me to set the “Copy Local” property of references to things like the Library to False. Why have all that junk copied to your output folder when it’s not really needed there? The main executable has a reference to all of them anyways so it just works. Besides, all of the .NET Framework references are set to false.
Well, mostly works.
The solution also contains a Unit Test project. This project has a reference to the Library as well as the DLL under test. (let’s call that one “Bob.dll”) The Unit Test project will not compile. It gives the error that it could not load the file or assembly Bob.dll or one of its dependencies blah blah blah. To which I reply, “F**K you Bob.”
You can also end up with misleading errors stating that namespaces don’t exist for your using statements for assemblies that are unrelated to Bob. It all depends on which file in what order they can’t be loaded or maybe on how many angels can dance on the head of pin. Probably the latter.
After making sure that the Unit Test project had a reference to all of the same things that Bob is dependent upon and that they were set to copy them locally, it still wouldn’t work. Same error. The only thing that fixed it was to set “Copy Local” to true in all projects. Further experiment shows that this only need be done for Project references. If you are referencing a third-party binary, it appears to be ok with that whether it’s in the GAC or not.
The real bitch of it is that the whole solution compiles and runs fine with the exception of the Unit Test project.
I know I sort of asked for it but still, that is messed up.
Just because I can…