Thursday, July 31, 2008 10:41 AMI am wondering what is a best practice for sharing project code. We have a few projects that are used in multiple solutions.
Should we use branching, creating release dlls or referencing shared projects directly?
Reading a previously posted message [http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=525206&SiteID=1] about sharing project code two methods are suggested: branching and referencing shared projects directly.
In the past we have referenced shared projects directly but when branching, relative paths no longer work and we have to manually fix references creating changes we don't want to be propagated to our main branch. This makes me wonder if referencing shared projects directly is such a good way.
I find branching to be a logical way to go for my team as we want isolation from everyone else. But here comes the problem. What happens with reocurring dependencies? When Project X (PX) depends upon "Shared Project A" (SPA) as well as "Shared Project B" (SPB) which depends on SPA. In this scenario I would have branched SPA and SPB into PX - SPA would however also have been branched into SPB hence there are now two SPA branches.
In the solution file for PX what SPA should be referenced - SPA or SPA'? As only one of them can be referenced would I have to merge SPA' into SPA and change the references from SPB accordingly? This would mean that the SPB branch contains changes we don't want merged to the SPB main branch.
I have read TFSGuide as well as well as the branching guides suggested in previous posts about branching but none have answers to this particular problem.
Is creating release dlls for sharing a bad idea?
I would very much appreciate if anyone has any suggestions on how to handle this scenario efficiently as everything seems to have a downside to it.
Thanks in advance,
Thursday, August 07, 2008 10:29 AMIs there simply no one that has experienced anything related to this scenario?
Hoping someone sees this.
Thursday, August 07, 2008 5:41 PMModeratorI don't understand the issue. Why are relative paths breaking? As long as you propagate renames/moves to other branches all at once, nothing should break. In the other model, why would you need to branch a 2nd copy?
Friday, August 08, 2008 1:55 PMDear Richard thanks for your answer.
I am new to branching and I may not be using the correct terminology but what I am seeing is dependencies becoming recursive ..
In this case my project PX depends on two projects: Shared Project A (SPA) and Shared Project B (SPB). SPB depends on SPA. In my case SPA is really a common utilities project.
When I set up SPB I branched SPA into SPB/Main/Source/SharedCode/SPA-Branch.
Now when I set up PX I branched SPA into PX/Main/Source/SharedCode/SPA-Branch and I branched SPB into PX/Main/Source/SharedCode/SPB-Branch.
What I have now are two branches of SPA:
Is this a wrong way to do it? In the SPB-Branch if I start referencing PX/Main/Source/SharedCode/SPA-Branch I may not have the same functionality as in PX/Main/Source/SharedCode/SPB-Branch/SharedCode/SPA-Branch.
What would be a solution to this problem?
Wednesday, August 13, 2008 11:15 AMRelative paths are not breaking and I am not doing renames or moves I simply have multiple branches of the same shared project as it is being used in other shared projects. And as I only have one solution file I am having difficulties with how to handle this scenario as I there may be changes in any or all of the different branches of the shared project.
I think I explained in the previous reply to this post why I have a multiple branches of the same shared project.
I am quite lost and it seems that I am approaching this incorrectly.
Should I be creating release binaries of shared projects instead?
I would very much appreciate any input.
Wednesday, August 13, 2008 3:18 PMModeratorYour way seems very complicated. I'm not sure it can work at all when there are multiple dependencies like you have now.
Here's what I would do:
/Branch1 (branch of Main)
/...same as above...
/Branch2 (branch of Branch1)
/...same as above...
Use relative paths to link the projects as necessary. For example, PX would have a reference to "..\Shared\SPA\SPA.csproj".
As long as every branch has the same structure, relative paths won't break.
Wednesday, August 13, 2008 4:26 PMOk I see what you are saying but the problem is really that PX, SPA and SPB are all part of different team projects.
Let me try and put this up in your structure
Problem arises in Px as there are Shared/SPA-Branch and Shared/SPB-Branch/Shared/SPA-Branch. Get it?
Wednesday, August 13, 2008 6:18 PMModeratorHmm, that's more troublesome. Two options as I see it:
(a) move SPA and SPB underneath PX\Main\Source so that they all have a common branch root
(b) use assembly references instead of project references. That is, check in a copy of SPA.dll and SPB.dll somewhere under PX\Main
(a) is better when the common libraries are closely coupled and/or change frequently. (b) is better when the libraries are more independent (perhaps owned by another team, or even a 3rd party company) and/or don't change very often.
Thursday, August 14, 2008 1:32 AM