At work, some colleagues are developing a standalone application hosted within the Visual Studio Isolated Shell. This application makes use of the DSM extension for Visual Studio to generate source code based on diagrams, source code which should be stored within TFS. Unfortunately, Team Explorer does not integrate with the Visual Studio Isolated Shell
So, they use MSSCCI as a solution to access TFS. But they recently noticed that this solution was messing up their workspace when working in multiple branches.
Click to Read More
TFS can be accessed from the Visual Studio Isolated Shell using the MSSCCI provider for Team Foundation (<= here the link for the 32bits/VS 2010 version).
My colleagues reported however some troubles when working on Visual Studio Solutions branched, e.g., from an existing TFS folder $/TeamProject/Main onto a new branch $/TeamProject/Dev.
Assume that $/TeamProject is mapped in a local workspace on C:\TFS\TeamProject, that there is no other mapping in this workspace and that one checks-in a new Visual Studio Solution created in C:\TFS\TeamProject\Dev (with one sub-folder per included Visual Studio Project). By default, the resulting server items will be located in $/TeamProject/Dev with all projects’ sub-folders created “recursively” bellow.
Next, assume that one does a reverse integration of the Dev branch on the Main branch, that one checks-in the pending changes and that one opens next the Visual Studio Solution located in C:/TFS/TeamProject/Main.
It appears that, behind the scene, Visual Studio with MSSCCI will create new workspace mappings between $/TeamProject/Main/xxx and C:/TFS/TeamProject/Dev/xxx. Any “Get Latest” made on the Main folder in TFS will update the local Dev subfolders! And when one will later open the Visual Studio Solution in this local Dev folder, expecting to work on the Dev branch, one will actually be working on the Main branch ;)
The reason is that the Visual Studio Isolated Shell with MSSCCI is using absolute paths in the Visual Studio Solution Files as references to included Visual Studio Project files. Visual Studio with Team Explorer is using relative paths instead. And when one opens a Visual Studio Solution Files containing absolute paths, mappings are created in the workspace, between the “server” items and those local “absolute paths”. I.e.: the definition of the workspace will be like:
- $/TeamProject ==> C:/TFS/TeamProject
- $/TeamProject/Main/Project1 ==> C:/TFS/TeamProject/Dev/Project1
- $/TeamProject/Main/Project2 ==> C:/TFS/TeamProject/Dev/Project2
If you ignore that absolute paths are used in your Visual Studio Solution file and if you don’t pay attention to the server path of your pending changes, you will really be confused when your colleagues will complain that you didn’t check-in your new features in the right branch or when a Gated Build will start on the Main branch when you check-in your changes :D