0

I'm running into a lot of problems sharing projects between solutions with VS 2010 and TFS 2010.

First issue is that everyone sets up their machine different, and create workspaces differently. Some use a single workspace for all projects. Some use a different workspace for each project. When you put two different projects into a solution from different parts of the tree, they don't necessarily map to the TFS tree structure (and generally don't).

So one person might have:

C:\Users\User\Documents\Projects\Project1
C:\Users\User\Documents\Projects\Project2

Another might have

C:\Users\User\Documents\Projects\Project1
C:\Users\User\Documents\SharedProjects\Project2

Another even does

C:\SharedProjects\Project2
C:\Projects\Project1

The problem is that the solution holds physical project locations, and everytime users get latest, they fight and create conflicts about project location.

I know, the easy solution is to mandate a single structure, but that's not going to work here.

Second problem:

We have some shared libraries that are the projects are included in different solutions across our tree. Some of these projects have different build configurations. One might have Dev, Test, Stage, Prod and another has Debug, Release, Prod.

This causes problems because the build configurations are stored in the project files. If a project tries to use a shared project, and the shared project does not contain a build configuration to match the solution, then VS locks up and causes all kinds of weird behavior.

Does anyone have any solutions to these problems? Is there any way to create local overrides for locations that do not affect all users? (Similar to the way you can set web server configurations on a per user basis)

Seems like these problems should have been figured out by now.

Erik Funkenbusch
  • 92,674
  • 28
  • 195
  • 291

2 Answers2

1

Recommendation 1 - seperate usage of solution files from your actual build system... Read the "Building Large Source Trees" section of this MSBuild Best Practices document below
http://msdn.microsoft.com/en-us/magazine/dd483291.aspx

Recommendation 2 - Do exactly what you said you couldn't do... Enforce some semblance of uniformity. Provide a TFS workspace template and/or state the 'build-approved' configurations. At some point people have to buy into this stuff or it's just not going to work.

Nick Nieslanik
  • 4,388
  • 23
  • 21
0

I had the same issue. It was taking so long to build the projects. I created master solution that hosts all web app and class library just for build and build time is really improved using that.

You can refer this post it might helps you.

TFS Build strategies for large projects

user1186065
  • 1,847
  • 3
  • 17
  • 22