All,
Please be aware that when you move a project, the dll references are not recalculated. The project is re-opened in its new location, and visual studio reads lines like the following
<Reference
Name = "MyEmployer.Common.BusinessLibrary"
AssemblyName = "MyEmployer.Common.BusinessLibrary"
HintPath = ..\..\bin\Debug\MyEmployer.Common.BusinessLibrary.dll"
/>
However should we have moved the file to a different depth in the tree, then the relative part of the path (..\..) will not find the MyEmployer.Net folder. Now IF you have overridden your reference paths or VS has done it for you, then you will of course end up with a csproj.user file that contains lines like this…
<VisualStudioProject>
<CSHARP LastOpenVersion = "7.10.3077" >
<Build>
<Settings ReferencePath = "C:\PVCS\Development Database\MyEmployer.NET\bin\Debug\" >
These .csproj.user files override the paths supplied in the HintPath in the project, and these files should NEVER be checked into source control (http://msdn2.microsoft.com/en-us/library/ms171339(VS.80).aspx) as they are re-created every time you open a solution. But if you don’t have a .csproj.user because you restored from source control into a clean directory, then you don’t find the files in the first place, unless the HintPath is accurate. If you do find a project in this state then you have to delete all the references to MyEmployer dlls and point them back to MyEmployer.Net/bin/Debug.
The moral of this story is…
Before checking in a copied project, please check its references by closing Visual Studio, deleting your all .csproj.user files and then re-opening the solution. If VS can’t recreate the links to the dlls then neither will anybody else (or an automated build system) that checks it out to a clean directory.
This will hopefully avoid anybody else wasting time looking for this problem.
Al. (Feeling much better now he’s had a rant)
PS. This problem only exists for projects that use binary references (a reference that points to a dll) instead of project references.