when I include some projects in my solution and change the references to Project References, some times it is still loading the wrong assembly because there is something else that is calling it FIRST, and that thing is not included in my solution. when number of projects increases it gets harder and harder to find out those porjects... who do you deal with this?
I use the Lexware Assembly Reference tool... gives you a menu option under the Tools menu in VS, and lets you see whether references are assembly or project references, the hint paths to dlls, copy-local, specific-version, and other reference properties. It also lets you edit these properties in one window.
http://assemblyreftool.codeplex.com/ for Visual Studio 2010
http://www.codeproject.com/KB/macros/Lexware_AssemblyReference.aspx for Visual Studio 2005/2008
Also note: If a project has a project reference, and you have that project in a solution, but the referenced project is not included, the referenced project will not build, and you will use the locally-copied dll in the bin folder of the referencing project (i.e. whatever the last successful build of the referenced project was). If there is no local copy of the referenced project's dll, the build will fail.
If, in the heirarchy of build order, a project is compiled first but has an older build of the referenced dll, that's the one that you get stuck with for higher-up builds. Reason being that the referenced dll is copied to the bin folder. So when the second project compiles, it looks for a reference to the lowest dll in the root-compiled project, and finds there's already a copy in the bin folder (albeit an older version).
The solution:
(1) Include the referenced project itself in your solution
(2) Change the project references to dll references, and reference a local, controlled version that you compile independently.
(3) Manually change the build order of the projects (not recommended)
A diagram to hopefully make that clear:
Solution
|
--Project 1 (references project 2 and project 3)
| \bin
|
|
--Project2
| \bin
| \proj4.dll (v1.5)
|
--Project 3
\bin
\proj4.dll (v1.2)
When the solution builds, project 1 forces a compile of project 3 first, and copies all related dlls to its bin folder. The structure now looks like:
Solution
|
--Project 1 (references project 2 and project 3)
| \bin
| \proj3.dll
| \proj4.dll (v1.2)
|
|
--Project2
| \bin
| \proj4.dll (v1.5)
|
--Project 3
\bin
\proj4.dll (v1.2)
Project 2 gets compiled next, but because by default specific-version is set to false, project 1 will see it already has a version of proj4.dll in its bin directory which is good enough for project 2. Therefore it will only copy proj2.dll over, and the structure looks like:
Solution
|
--Project 1 (references project 2 and project 3)
| \bin
| \proj2.dll
| \proj3.dll
| \proj4.dll (v1.2)
|
|
--Project2
| \bin
| \proj4.dll (v1.5)
|
--Project 3
\bin
\proj4.dll (v1.2)
Please feel free to correct me, anyone, if they disagree. But I'm pretty sure this is why you're seeing what you're seeing (if I understand the question).