Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
C#.Net And Version Control
Message
From
26/05/2009 23:23:20
 
 
To
26/05/2009 10:22:19
General information
Forum:
ASP.NET
Category:
Third party products
Miscellaneous
Thread ID:
01401711
Message ID:
01402153
Views:
55
Tim & Randy,

As usual, it all depends on what you're doing and how you've organized your work. In our case, we use TFS, and it gets picky about some things. Since you *have* to work integrated with TFS, you *have* to check in solutions *and* projects. (I should probably say we never found an easy way to work with TFS in a non-integrated manner ... we may have missed something). Some things were easier when we used to use Source Safe way-back-when.

Anyway, we handle common projects two different ways:

1) All our "Framework" projects are always included in every solution. Yes, we could have opted to just reference our Framework's DLLs instead, but for a multitude of reasons, this is the way we decided to go. Consequently, each application (.sln) has it's own copy of the Framework projects (meaning lots of copies of those in TFS, but who cares ... it's only disk-space). It's easy to keep it all in sync with TFS's merge capabilities (developers are not allowed to make changes to Framework classes ... if they do, I will overwrite them when I merge my new Framework changes ... too bad for them if they screwed up and did this without telling me!! <g>)

2) We have some common components projects in a few Library types of solutions. These library solutions exist only to have a common place to keep common non-Framework projects. Those projects are referenced by other solutions with DLL references. And, as we all know (or should know), we can add reference paths to the project properties, so it doesn't matter if you keep your files in a different folder than the next guy. The reference paths are kept in a .csproj.user file which doesn't get checked into TFS, only the .csproj does.

We've just had to find some creative ways to work with TFS. Some of it's quirks are annoying, but all-in-all it's not bad. I've gotten used to it.

~~Bonnie




>Hi Tim,
>I agree with you. Some developers may need a project reference when working on multiple related projects, where other developers may only need an assembly reference. I've found that this is a hassle if your solution is under source control.
Bonnie Berent DeWitt
NET/C# MVP since 2003

http://geek-goddess-bonnie.blogspot.com
Previous
Reply
Map
View

Click here to load this message in the networking platform