I am wondering what is the best way to use workspaces in visual studio. We have 150+ webservices that are all part of the same team project $/MyTeamProject without being related at all. The reason for them all being part of the same team project as they are all maintained by the same group of people within our organization.
Each webservice has the following structure
$/MyTeamProject/WebService1
$/MyTeamProject/WebService1/Main
$/MyTeamProject/WebService1/Release/1.0
$/MyTeamProject/WebService1/Release/1.1
$/MyTeamProject/WebService2
$/MyTeamProject/WebService2/Main
... etc.
I am wondering what is the proper way to use workspaces with this setup as currently there is only mapping for the teamproject so all my webservices are part of the same workspace. Should I create mapping for the main branch and for each release branch as a separate workspace or should I map each webservice to its own workspace such as $/MyTeamProject/WebService1?
Any help would be appreciated.
I can't put each of the webservices as its own teamproject as the tfs is being shared between several groups with the same magnitude of projects and therefore we are limited by our own teamproject for all of the webservices.
You said that the webservices was not related at all. I then assume that they are released separately.
I can't see any reason to use multiple workspaces in your scenario.
I suggest that you remove the mapping from the top level project "MyTeamProject". Then you have flexibility to map the subfolders to whatever local folder you want.
If you have one workspace per webservice then you will get 150*#releases workspaces. This will get really hard to manage for build versions, labelling etc. Fewer workspaces will mean less builds to manage.
I would recommend having a workspace per release. Generally you would probably only be working on one release at a time and this will allow you to manage all code for a single release effectively. Also you can then map your workspaces on the client into a more logical structure as you allude to in the question.
For example
\Projects\MyTeamProject\Main\WebService1
\Projects\MyTeamProject\Main\WebService2 ...
\Projects\MyTeamProject\Release1.0\WebService1
\Projects\MyTeamProject\Release1.0\WebService2 ...
\Projects\MyTeamProject\Release1.1\WebService1
\Projects\MyTeamProject\Release1.1\WebService2 ...
etc
Related
I have a class library project to be shared by two different solutions in Visual Studio 2017. The solutions are mapped in two different workspaces. I cannot find a way to get the shared project under source control in both solutions. Any suggestions?
I'm assuming that you have two separate Team Projects, each with its own TFVC repository. Underneath one of those Team Projects (say, TPA), you have a common library that you'd like to share with a solution located in Team Project B (TPB).
You can't do what you're asking to do -- even if you could do it, you shouldn't. You don't want to fork the source code and maintain two copies of it. What you want to do is one of the following:
Map a single workspace containing all of the Team Projects and use relative
paths for references. This isn't great, ideally each Team Project is considered a totally separate entity.
Put everything in a single Team Project and maintain a single workspace for everything.
Turn the shared component into a NuGet package and use a Package Management feed. Each consumer of the shared component can then reference a common NuGet package.
I'd say #1 is already excluded as an option. Each Team Project should be an independent entity with nothing shared between it. Since you have things shared, you've chosen the wrong organizational structure. Stop using multiple team projects.
Option 2 is okay, but it's a little bit clunkier.
Option 3 is the preferred, modern way of managing cross-project dependencies. I'd strongly recommend looking into implementing this pattern. If you adopt this pattern, maintaining multiple team projects becomes acceptable again -- you have one Team Project that acts as a publisher of shared components, and another that acts as a consumer. That's sufficiently isolated to consider them independent of one another, and thus an acceptable candidate for multiple Team Projects.
It's worth noting that the modern thought among most experts in this area is that maintaining a single Team Project for all related applications is the correct approach. I've seen teams with hundreds of members and dozens of applications using a single properly organized Team Project with no problems.
While I agree with Daniel on the fact that this is probably a bad idea and that there are alternatives, it's perfectly possible; there's one restriction though: each workspace must have its own copy of the shared project on your hard drive, they can share the remote copy on the server. This si very similar to a distributed source control model and can work just fine.
To make this work, first create one workspace and map the folders locally:
Workspace 1
$/Common/ => c:\src\1stProject\Shared
$/ProjectA/Solution => c:\src\1stProject\SolutionA
Then create a second workspace:
Workspace 2
$/Common/ => c:\src\2ndProject\Shared
$/ProjectB/Solution => c:\src\2ndProject\SolutionB
This way both projects share the same server location and changes made to Shared will directly impact both SolutionA and SolutionB. Locally though, each solution will have its own local pending changes etc.
This solution will work as long as both Team Projects are in the same TFS Project Collection.
The only limitation is that these projects can't be placed in a subfolder of each other, so you can't do this:
Workspace 1
$/Common/ => c:\src\1stProject\SolutionA\Shared
$/ProjectA/Solution => c:\src\1stProject\SolutionA
Nor can both workspaces map to the same local folder:
Workspace 1
$/Common/ => c:\src\Shared
$/ProjectA/Solution => c:\src\1stProject\SolutionA
Workspace 2
$/Common/ => c:\src\Shared
$/ProjectB/Solution => c:\src\1stProject\SolutionB
Alternatives
Nuget
Instead of using shared sources directly, add a NuSpec to the Common project and build & publish the NuGet package to the VSTS package management feed of the VSTS account. Add a NuGet reference to SolutionA and to SolutionB. That way the binaries of Common are shared among SolutionA and SolutionB, but common is maintained independently. This way it's also easier to update SolutionA at a different cadence than SolutionB (this is also the biggest pitfall for this solution).
Git & Submodules/Subtrees
Convert the TFVC repositories to Git repositories. That way you can use Subtree or Submodules to reference Common directly from the SolutionA repository and the SolutionB repository.
MonoRepo/One Project To Rule Them All
Merge all your TFVC repositories into a single TFVC repository, that way both projects can easily live inside the same workspace. Technically this isn't needed to put both projects in the same workspace, but it is easier. It results in a very similar solution as described above:
Workspace Single
$/Project/Shared => c:\src\Shared
$/Project/SolutionA => c:\src\1stProject\SolutionA
$/Project/SolutionB => c:\src\2ndProject\SolutionB
Would result in the same as the following cross-project layout:
Workspace Single
$/CommonProject/ => c:\src\Shared
$/ProjectA/ => c:\src\1stProject\SolutionA
$/ProjectB/ => c:\src\2ndProject\SolutionB
Note
In any cross-project setup, the UI of both Visual Studio and VSTS will fight you. The VSTS team has been working on the ability to make individual Team Projects portable across accounts. In order to do that features like these will need to be dropped at some point. The UI in VSTS build, for example, will not show any other Team Projects in the Source picker. If you type the paths manually they will work (as long as you configure the build to have a Collection Level scope).
Advice
The Nuget solution is the most reliable solution for the type of problem you're trying to solve. The VSTS Package Management feature will allow you to easily share the Common project across multiple projects and even across other VSTS accounts is you want to in the future. It's the most reliable solution.
If you need to be able to edit the files in either solution, I highly recommend you look into Git Subtrees or Git Submodules. Git is the future in any case and these features will allow you to achieve what you need in a much easier to sustain way. They do come with a steep learning curve though.
I am looking for some ideas and suggestions on how to implement a class hierarchy type of structure of VS projects in TFS.
Specifically, I want to have a "base" project which will contain all the common functionality the rest of the projects will inherit. When the changes are needed in the "base" project it should be relatively easy to propagate these changes to the rest of the projects which are based on this "base" project.
The obvious approach is to branch other projects from this "base" project and merge up the tree from this root project when there are changes but I've never tried that before and would like to hear from someone who attempted something like this before or has extensive enough experience with TFS to be able to point to inherent issues or pitfalls of such idea...
The projects in source control is actually folders. So your question is somehow the same as how to structure your folders in TFS.
Your base project is the some concept of main in branch which is root folder that acts as a container folder for your main source tree, together with accompanying project artifacts such as design documentation, scripts, and test cases. The Main folder also usually contains your Visual Studio Solution (.sln) files.
In TFS you could convert a folder to a branch.Then you just need to branch your base project to other projects. After have a branching relationship, you will be able to merge changes between the 2 branches. Besides you could also use branches to accomplish the following goals:
Manage concurrent work by multiple teams on the same codebase
Isolate risks that are introduced by different sets of changes to the codebase
Take snapshots and then support subsequent isolated changes (for example, to create a release branch)
Although you can still branch and merge among folders, the best practice for your team is to branch and merge only among branches.
When you perform branch operations, branches have important advantages over folders. Branches support version control features that provide extra visibility into your branch structure and into where your changesets have merged. (For more information, see these wonderful links: Visual Studio TFS Branching Guide)
For inherent issues or pitfalls of such idea, one thing is you might have to resolve conflicts when you get, check in, merge, or unshelve. Another thing is permission. It's better to avoid everyone have permission to merge changes from the “derived” projects back to the "base" project.
Besides you can create multiple teams in the same Team Project and you can nest them to facilitate hierarchy. If you are interested, you could check this blog which shows how to configure that.
We are thinking of making a distinct collection for code that is shared between our software products. We would then have a collection for the software projects. This would be done for organizational purposes. Would it be possible for a solution to reference c# projects that are in two different collections?
A solution can have files from anywhere, since they need to be mapped to a loal disk for Visual Studio to open them, but when spreading the code over multiple collections Source Control integration will break. Team Explorer requires all code to come from the same collection, and it favors solutions where all code is from a single team project, in those cases the other features will work best.
Other features in VSTS and TFS will be harder to use when your work is spread across multiple projects and/or collections. Test Plans, Agile tools, Team capacity and a few other items are purely scoped to the Project level. working in multiple projects at the same time will make it much harder for a team to use the tools properly. Many TFS consultants implement a "One project to rule them all" strategy because of these reasons. Putting all code and all work in one teamproject.
The XAML and 2015 build engine can only access sources from a single Project Collection at a time. So while it's possible to setup a number of local workspaces that each map to different team projects and/or project collections, this is not available when using the standard build servers that ship with TFS. Other build tools, such as Team City can be linked to multiple Source Control providers at the same time.
Now that it's possible to have multiple Git Repositories under the same Team Project, that approach makes even more sense.
Other things that will be harder may include branching structures, it will be very hard to manage the different versions of your code when they're spread across collections, since Labels and Branches can't cross collections and are hard to maintain when working in multiple projects.
A better solution for you would probably be to have your shared code in a separate team project or project collection, but not include it directly in your other projects in the form of Visual Studio Projects. Instead, have your shared projects stored as NuGet packages, either on a private NuGet feed or on a VSTS account with Package Management enabled.
That way your other projects will build faster (which can be significant when setup correctly), will use the binary versions of your shared libraries and have less unwieldy solutions.
One disadvantage of putting all code in a single team project or project collection is that it's harder to maintain the security. Project Collections for a natural boundary inside TFS, one that's harder to accidentally misconfigure or to break out from.
As #jessehouwing said solutions can have files from multiple collections. Each collection has a local workspace from where you attach project/files to your solution.
Where I disagree is that this is actually a good idea. There is no problem having 10+ collections, each for specific purpose.
For example 1 for generic projects that nobody will update unless necessary. One to store scripts. Basically think of it as library bookshelf. All similar stuff to some degree should be kept close.
Another plus is a security since one team can have access to some collections but not other. It is an obvious plus.
As to time difference, does really 1-2 sec make difference to anybody. Add one more agent and you will save time because locally building makes no difference.
As to Labels specific purpose strategy helps to overcome those problems.
Overview
I am using VisualSVN in Visual Studio, VisualSVN Server on Windows, and of course, TortoiseSVN. I wanted to know what the best method of sharing multiple projects over multiple solutions was, and if there was a better method.
Layout
My Repository kind of looks like this (not their real names):
Library.Common
Library.Web
Library.DB
Library.CMS
Customer1.Site
Customer2.Site
Process
To create a new site that contains common projects:
Create Repository in SVN-Server, e.g. "Customer3.Site"
Create Web site using Visual Studio 2008, named "Customer3.Site", VisualSVN used to commit to the repository created in step (1).
Edit properties of Customer3.Site and specify the necessary projects as svn:externals, e.g. "Library.Common", "Library.DB", etc.
Perform an update, to get these external projects, and add them to my solution in Visual Studio, add the necessary references to the Customer3.Site web project and hit build.
So far so good.
The Problem
All this works fine, I am happy that if I have to modify any of the core Library projects I can do so right in the same environment and commit them to the repository. As more and more customer sites are built, I will then have to keep track of what I've done and remember to SVN Update and rebuild those sites which seems quite a long-winded task.
Is there a better way of doing this, a more best-practice solution? Am I breaking any fundamental SVN laws by doing it this way? I want to find a good solution that doesn't cost too much time and isn't overly complex either.
I've been facing a similar issue ... I am setting up a base install package for WordPress, something we would use to quickly get a site setup, it contains the core of wordpress + a set of baseline plugins, both third party and custom ones we've created. Everything pretty much comes from SVN.
Different plugins have different versions/tags and to setup an svn external pointing to a specific tagged version per project would be a nightmare ... only to then have to go into each and every project and do a property adjustment and then an update.
What going to be implementing is a vendor branch with specific versions as needed. All I should then have to do is update the client sites, since they will always be pointing to the latest versions (under my control in the vendor branches).
As to your problem, and also in my case: I would probably write a commit script to update all projects automatically when something in the vendor branch is updated.
Scenario:
Currently we have a single solution supporting a single deployable entity, a WinForm/WPF client, this solution has a layer architecture with projects representing various layers (Data, Business, UI). We will be introducing other deployable entities such as a LiteClient, a Server and an RIA.
We are considering a restructure where we will have multiple solutions, one per deployable entity (Client Solution, Server Solution, RIA Solution etc), these solutions will share various projects, e.g the Data layer project. This is essentially the Partitioned Single Solution recommended by Microsoft's P&P group (http://msdn.microsoft.com/en-us/library/Ee817674(pandp.10).aspx)
Question:
Apart from the admin overhead of this approach, is there any serious real world gothas waiting for us, if we adopt it.
This is a reasonable and normal approach. At the end of the day, the Visual Studio solution is simply a collection of projects with deployment information.
In order to reduce possible dependency issues, make sure you use a build server (TFS or otherwise) that takes care of compiling and deployments.
If you change something within the shared projects, you have to check if that didn't break the dependent projects. If you keep those projects in seperate solutions you have to remember to recompile them each time you modify the shared projects.
That's a drawback that I can see.