visual studio .net general: I have a Team Project that will consist of 3 Visual Studio Solutions. Lets call them A, B and C.
Solution B requires DLLs built in solution A
Solution C requires DLLs built in solutions B and C.

The dependencies have been giving me fits for years in Visual Studio because some of the DLLs are Managed C++ and some are Managed
C#. I have arrived at the 4th 'solution' to the cross solution references. This one might actually be almost working. In this
'solution' I created a folder for debug and release under each VS Solution. I then changed all the projects to put all their
outputs into the single debug or release folder according to build type. This solves the CPP vs C# reference issues caused by CPP
and C# dlls having THEIR dependencies in different directories. Of course, I still have the problem of changeling from a release
to debug set of dependent DLLs but that is just yet another deficiency in VS.

Now for the question.
If I setup a batch build of this Team Project how does the build being done on the Build Server know where to pick up the
dependent DLLs for Solutions B and C. The paths in the VS projects are hard coded from the root of drive instead of relative to
the current solution/project. The output of the batch build is not in a consistent directory tree.

I hope that you do not tell me that I have to change my VS Projects to point to the drop point or some other directory from the
batch build, because in that case I any updates to VS Solution A would not be reflected in builds for B and C when I do normal VS
builds during the day.

-------------------------------------------
Roy Chastain
KMSYS Worldwide, Inc.

Hi Roy,

Based on your description, you have set the build path of solution A,B,C to
the same folder on the build server by creating a Build Type. Actually, to
the build process, solutions themselves do not have dependencies. In this
case, you only need to set the Build Path and (or) Drop Location of
solution D to the same as solution A,B,C.

If solution D depends on the built assemblies from solution A,B,C, it will
be better to put solution D project together with solution A,B,C, so that
the build sequence can be set in the solution.

If there is any misunderstanding, please feel free to let me know.

Kevin Yu
Microsoft Online Community Support

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================

(This posting is provided "AS IS", with no warranties, and confers no
rights.)

Apparently my description was not clear.
1) - There is a dependency between VS Solutions. Solution A contains 15 projects. Each of those produces 1 dll.
Solution B contains 6 projects (2 exe and 4 dlls) Each of those projects references one or more of the 15 dlls from Solution A
Solution C contains 20 projects (4 exe and 16 dlls) Each of these projects references MANY of the dlls from Solutions A and B.
There for there is a dependency. Solution A must always be up to date before B and C are generated and, if some parts of A
change, then B must also be regenerated before C and be built.

2) - No, I did not put the output of A, B and C in the same directory. I put the output of each solution into its on directory
EXAMPLE
Solution A, contains projects Core, CoreCPP and Crypto. Core and Crypto are C# CoreCPP is managed C++.
The default output directories would be
A\Core\bin\Release
A\Release (for the mC++ code)
A\Crypto\bin\Release
I have redirected all of the output to A\bin\Release
(this step was done on the advice of MS Support on a paid incident) The reason is because the mC++ dll causes other C# dlls to
also be copied into the A\Release directory and it uses a reference path to them in that location instead of the real location of
A\project\bin\Release and when all of these are referenced in the B and C solutions, VS gets totally confused and things that
there are 2 different version of many of the DLLs and produces about 1500 warnings. (This is a 2005 only issue - well, 2003
handled it better; but not correctly - when I switched my builds from 2003 to 2005 and the warning started the build went from 1
min to 15 mins for solution C.

Now back to the question.
In VS builds, the reference path to DLLS not contained in the solution is all important (as outlined above). How does the Batch
build done by build server know where to pick up dependent DLLs. If it is using the paths from the .cproj files they will be
1) on a different system
2) not the ones created in the batch build.

(PS. Combining these solutions does not make sense from an architecture point of view - A and B are both used by other solutions
that do not use C etc - and I have been told by more than one MS VS support person that I am already pushing the limits of VS with
the number of projects in the solutions as they currently exist.


[quoted text, click to view]
-------------------------------------------
Roy Chastain
KMSYS Worldwide, Inc.

Hi Roy,

From you description, it seem that your build process does not pick up the
referenced dlls from the correct location that they are newly built. Am I
right?

The batch build will get the reference dll from the location that .csproj
file specifies. So when you add reference to an assembly using an absolute,
it will always get the dll from there. Thus makes a lot of warning.

Is there any chance that you modify all the project reference to make them
reference to the output folder in A\bin\Release? In my opinion, currently,
there is little we can do in VS.NET to prevent this from happening besides
doing this, since the projects are seperated in 3 solutions.

Kevin Yu
Microsoft Online Community Support
==================================================

(This posting is provided "AS IS", with no warranties, and confers no
rights.)