In a project I am working with, I was migrating some projects from V1.1 to V2.0 of .Net, compiling and building all very happily, until another developer grabbed the latest code from source safe and found that a bunch of assembly references were invalid and therefore the project could not build.
Due to the large nature of the application, many parts had been broken into individual assemblies, with only those assemblies being referenced, not the project themselves.
In my migrated projects, it turned out some of the assembly references which I re-added, were not being resolved. Upon closer inspection of these project files, I saw the following:
<Reference include=”MyAssembly, Version=18.104.22.168, Culture=neutral” />
Obviously there is no path in there so it could not be resolved, however in some other projects in the same solution, and referencing the same assembly, I saw:
Which was being resolved successfully, as you would expect because of the extra <HintPath> element. I found in the offending project, that adding other assemblies from the same directory as the "MyAssembly" still yielded no <HintPath> element. So what was the difference between the 2?
After some investigation, I found that the offending project had some ReferencePath directories defined, one of the directories defined being the location of "MyAssembly", whereas in the working project, no ReferencePath settings were there. The ReferencePath settings can be seen by right clicking on your project in Visual Studio 2005 and selecting properties, then the ReferencePath tab.
The ReferencePath settings are actually stored in a .user file, which are not normally checked in, so when the developer got the latest code, the project file contained no <HintPath> settings, but also, his project had no ReferencePath settings defined, therefore the assemblies could not be resolved, and the build failed.
If you are setting up solutions and projects for your company, particularly large complex solutions, it pays to be aware of this behavour.