creating references that span TFS projects in a branched environment

Question

We are using TFS and Visual Studio 2008 Team System to do our development
and configuration management.  We have branched all of our TFS projects in
order to isolate the development, QA, and production environments.  We use
the TFS build server to produce the build outputs and have added copy tasks
to copy the outputs of the latest successful build to the appropriate build
output location (on a separate server).  Corresponding to each TFS project,
we have a folder in the build output area that has 3 subfolders -- DEVEL,
QA, and PRODUCTION.  We are only interested in keeping the outputs from
the latest successful build on this other server.

One of things we of course want to ensure is that if project x has a
reference to a DLL generated by project y (where x and y are different
TFS projects), that the corresponding branch (DEVEL, QA, or PRODUCTION) is
referenced. 

For our web site projects, we can accomplish this by updating the .refresh
files to specify the appropriate folder (DEVEL, QA, or PRODUCTION) in the
folder path to the dependency.  For our projects that use .csproj files, we
would have to change the references to point to the appropriate path and
make sure that we don't merge the .csproj file from DEVEL to QA since that
would overwrite the references with incorrect paths (i.e. pointing to
DEVEL instead of QA).

My question is:  is there a better way to do this?  What would be ideal is
if references could be specified with a variable in the folder path and
if the TFS build (and also the Visual Studio build) could set this variable
to the appropriate value (DEVEL, QA, or PRODUCTION) depending on whether
a build is being performed on the DEVEL, QA, or PRODUCTION branch.

So the reference would look something like:

\\servername\buildoutput$\project_y\%branch%\name_of_vstudio_project\some.dll

and %branch% would get replaced with DEVEL, QA, or PRODUCTION.

When I posed this question on the forums a year and a half ago, one person
(non-Microsoft) suggested putting the generated objects for project y into
Source Control.  Since we are not interested in keeping multiple versions of
the generated objects (only those from the latest build) and since source
control really should be for version control of source code rather than
generated objects, this suggestion did not appeal to us.

Thanks,
mkedwards

Answer 1

Hello mkedwards,

Thanks for your post.

When you mentioned "a reference to a DLL generated by another project", do you mean it is a DLL file reference instead of project reference?
Project reference is recommended here. It searches for project output path for DLLs.

If file reference is necessary here, please take a look of the answer from Jakob:
http://social.msdn.microsoft.com/Forums/en-US/tfsbuild/thread/fc3d0d7d-c391-426a-a6a1-11fd73ad5a1e

You can build the projects in project folder and copy binaries to output folder afterward.

Hope it helps.

 

Hongye Sun [MSFT]
MSDN Subscriber Support in Forum
If you have any feedback on our support, please contact msdnmg @ microsoft.com

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.

Answer 2

Is this issue resolved? Thanks.

Hongye Sun [MSFT]
MSDN Subscriber Support in Forum
If you have any feedback on our support, please contact msdnmg @ microsoft.com

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.

Answer 3

Hongye,

My apologies for not getting back to you sooner.  In response to your question about the type of references we are using:

We are currently using mostly file references.   The important thing to keep in mind is that the references in our web site project are to DLLs generated in different Team projects (not simply to projects in different solutions that exist within the same Team project).   But regardless of whether we are using file references or project references, I'm not sure that I see an effective remedy to the question:  how can I specify a reference that will work in a branched environment, such that the DEVEL branch of the web site project picks up the DLLs from the DEVEL branch of the "external" Team project, and likewise for the QA and PRODUCTION branches.

In the case of project references:
Will relative paths in .csproj files work across Team project boundaries and still allow me to not hardcode the name of the branch (DEVEL, MAIN, or PRODUCTION) ?   I rather doubt it, but if there is a way, please enlighten me ... a concrete example would be nice.

In the case of file references specified in .refresh files:
I would of course rather not specify hard-code paths to the DLLs that include the name of the branch, and that's why I suggested that it would be nice if I could be a path that used a variable in it, like so:

\\servername\buildoutput$\project_y\%branch%\name_of_vstudio_project\some.dll

Right now, we are using file references and instead of merging the .refresh file, we edit them separately on each branch of our web site project.

If I am correct in assuming that no effective remedy exists for the issue I'm raising, then I sincerely hope that you will pass this question on to the TFS architects, so that a simpler and more effective way can be devised.   I almost wonder if this would be easier to accomplish if we used MSBUILD directly instead of using TFS build.  Sometimes, more flexibility can be obtained from a lower-layer interface.

By the way, you state:  "You can build the projects in project folder and copy binaries to output folder afterward."
Can this be done in a way that will work across Team projects and in a branched environment?  If so, can you provide a concrete example of how this would be done?

Thanks for listening,
Mike


 

Answer 4

Hello Mike,

Thanks very much for your feedback.

I understand your problem. Referencing between different team projects is a common senario in a big project. Usually, we versionize the binary of the referenced project and check in it to the referencing project's source control to solve this problem. So that the reference path can be coded as relative path.

The binary can be checked in by TFS build automatically. For example:

1. Binaries are located in folder $ProjectA\BranchA\References\some.dll
2. In ProjectB\BranchA, it checks in some.dll to ProjectA\BranchA automatically after a successful build
3. In the referencing project, you can use relative path like: ..\References\some.dll to reference the DLL

In this way, the hard coded string of ProjectA and BranchA are only in team build project file.

TF command line tool can check in files in TFS Build.

For your feedback, I will forward it to appropriate channel. The best channel is to submit a suggestion on the http://connect.microsoft.com site. Thanks.

Hongye Sun [MSFT]
MSDN Subscriber Support in Forum
If you have any feedback on our support, please contact msdnmg @ microsoft.com

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.

Answer 5

Hongye,

Thanks for your reply, and yes please do forward this discussion to the appropriate channel ... it would be nice to eventually see a solution supported by Team System that doesn't require checking binaries into source control.

We will consider using that approach as an interim solution.

Mike