In the past ten years I have used several different source control solutions including Visual Source Safe, Source Gear Vault, Subversion and finally Team Foundation Server (TFS). The issue with TFS, at least for me, is it is installed on premise. The problem with an on-premise installation is I need to be on the network with the TFS server in order to use it. And, by "on the network" I mean at the client location or attached remotely via VPN. I have yet to have a client willing to open up their firewall for direct TFS access, although I know that is an option too. So, when I attended //BUILD this year I was excited to learn about new service from Microsoft that could help ease my TFS access woes.
The new TFS service is TFS 2012 but hosted on Azure. I love it and I could spend hours writing about how to implement, use and configure it; that's not what this post is about. I want to focus on how to get the source code in the current source control system (whatever it is) into the new TFS Service.
To help with the demo, I created a sample project. It's simply an MVC site, a test project and a library. All of the projects and files are under the same solution folder and are currently hosted in an on-premise TFS 2010 server project collection.
I always include a folder called "Referenced Assemblies" for DLL references that are essential to the solution and would be required by other developers on the team. This way, the dev only needs to get the entire solution and magically all the reference pointers are working.
So, now that the solution is in local source control, it needs to be prepped for moving it to TFS Service.
Prepare for the migration
To begin the migration, I look through the solution projects and files to be sure no other team members have pending changes. Then, I do a "get latest" on the entire solution resolving any conflicts. From there, I navigate to the solution root. I think easiest way to do this is to click on the "Local Path" link in the Visual Studio Source Code Explorer:
I'm now all done with Visual Studio, so say I'll say my goodbyes for now and close it.
Clean the solution
For this part I am going to use CleanProject (a Visual Studio extension). The CleanProject extension is really sweet, it takes a solution folder and cleans all the unneeded items such as bin, obj and ReSharper folders AND most importantly of all it removes all the source control bindings. Don't worry, it doesn't touch the original folder, instead it creates a copy and does all the magic on that copy.
To use CleanProject, I navigate to the folder one level above the solution root; the solution's parent folder.
From there I just right click on the solution folder and choose "Clean, Remove Source Bindings and Zip Solution" which will do exactly that:
When it finishes I have a zip file of all the cleaned contents of my original solution folder:
There are many command line options for CleanProject. There's even one to just copy the files instead of creating a zip file, but, for simplicity, I am just using the context menu. For more information on the command line options, visit the CleanProject site on CodePlex.
Move the solution to a new location
Now that the solution is cleaned and zipped into a nice little package, I need to find a new home for it on my hard drive. I created a folder called CloudTFSService and I extracted the folder contents to that location. Here is a trick that I didn't see documented anywhere. Once I've extract the files, those files retain their attributes from the original location;namely, the Read-only attribute. I need to remove those attributes before adding the solution to the new TFS Service. To do this, I just right click on the new solution root, choose "Properties", uncheck the "Read-only" box and apply the changes to all subfolders and files.
Okay, now I'm all set to open my solution and add it to the TFS Service.
Add the solution to TFS Service
Before I go any further, I'll need to sign into my TFS Service account and add a new team project to hold the new solution.
Once the new project is created, I open Visual Studio and choose "Connect to Team Foundation Server..." which is either on the start screen or under the TEAM menu item.
From here I can add a new TFS server and instead of pointing to a local instance, I'll point to my TFS Service instance.
The connect dialog then asks me to provide my Windows Live ID credentials to connect and presents me with a list of projects. I then choose the project created in the previous step.
Next, I'll open the solution from the FILE menu by choosing Open -> Project/Solution.
Okay, I'm almost done. Now that I have the solution open, I'd better make sure it still builds! When I get a successful build, I then, right on the solution in Solution Explorer and choose Add Solution to Source Control...
Now here is another trick. For projects that only have one (and will only have one) solution, I delete the contents of the "Type the name for the solution folder" textbox. This creates the solution directly under the project root instead of creating another subfolder to house the solution. If in this case I was to leave the just how it is, my solution file would reside in $/SampleProject/SampleProject/SampleProject.sln instead of, simply, $/SampleProject/SampleProject.sln. Don't get me wrong, that convention is nice for projects that will contain multiple versions or many solutions, but this one is more simple than that.
Now, remember how I said I like to create a "ReferencedAssemblies" folder? Well, that folder has not been added to source control. I want to do that so all team members are working on the same versions of the references. It's pretty easy to do using the Source Code Explorer in Visual Studio.
To add the folder, I open Source Code Explorer, right click in the solution folder pane and choose "Add Items to Folder..."
Now I'll select the "ReferencedAssemblies" folder and choose Next (not finish). Then I make sure to INCLUDE any DLLs I want to be added to source control.
Once I have included the DLLs, I'll be able to click finish and the ReferencedAssemblies folder will appear in the list of solution folders.
So, what's left? Oh, yeah, I need to actually check in the solution to upload the files to source control. To check in the solution I right click on the solution in Solution Explorer and choose Check In...
That's it! I'm done.
In this post I demonstrated how to migrate an exiting source-controlled solution to the new TFS Service. Hopefully you will find a few useful tidbits in here to help you migrate your solutions.
Good luck and let me know how it all works out for you!