Visual Studio 2010 error connecting to TFS 2017

One of the reason why I always suggest of keeping TFS upgraded is the compatibility matrix. Microsoft ensure that old tools (like VS 2010) always can connect to latest version of TFS, but the opposite is not true. This means that new version of Visual Studio could have problem connecting to older instances of TFS.

Keeping your TFS updated will guarantee that you can use TFS with newer and older tooling (yes, even Visual Basic 6 can work with TFS 2017)

But even if the compatibility matrix confirm that you can use VS 2010 to connect to TFS 2017, you probably need to install some additional software, to guarantee the connection. As an example you can receive the following error when you try to connect to TFS 2017 TFVC repository from VS 2010.

The user name <guid> is not a fully-qualified name, parameter name workspaceOwner

This error happens because you lack some required update to connect to TFS 2017 from VS 2010. For VS 2010 to connect to VSTS / TFS 2017 these are the steps you need to take.

  1. Visual Studio 2010
  2. Team Explorer 2010
  3. Visual Studio 2010 SP1
  4. Visual Studio 2010 GDR for Team Foundation Service
  5. Visual Studio 2010 Compatibility Update for Windows 8 and Visual Studio 2012

This sequence of steps is taken from the Exceptional link of Jesse Houwing . This link will specify you all service pack and patch you need to install to connect to various version of TFS. I strongly suggest you to bookmark that link, because it can really save you when you have old client (like VS 2010, VS 2012) that experiences difficulties connecting to the newest version of TFS / VSTS.

Gian Maria.

Using a different unit of measure in task planning in TFS

With TFS 2012 you can do work planning with the new agile board, where work is decomposed from PBI to task and task are usually estimated in hours.


Figure 1: Task estimation is made in hours.

Using hours is only a matter of convenience, but many agile team does not like hourly estimates and prefer using some other empirical values such as Effort, Story Points, or Cup Of Coffee, where the latter is the number of Cup Of Coffee you need to finish that task 🙂 (dev are caffeine addicted). Avoiding using hours, gave the idea that we are not estimating precisely, especially because we are interested in team Velocity and not knowing how many hours do we need for a certain task. For this example suppose our team is used estimating in coc = Cup Of Coffee, and we want the board to reflect this fact.

The crude fact is that the Estimated effort for task in TFS is just an integer number, and TFS does not care if this number is actually representing hours, Cup Of Coffee or whatever else, it is just a number that can be aggregate with the add operation. The only problem is that the board shows 4 h, and this immediately gives you the idea that you need to plan in hours.

If you want to show something like coc = Cup Of Coffee, you first need to import in your computer the CommonConfiguration of the process template with the command

witadmin exportcommonprocessconfig /collection:http://localhost:8080/tfs/fabrikamfibercollection /p:"test project" /f:c:\temp\commonconfiguration.xml

This is issued against the Brian Keller’s Virtual machine, you should only change the address of the collection to match your collection and the name of the project to match your project. Once the file is downloaded you can edit the xml file changing the Microsoft.VSTS.Scheduling.RemainingWork (I’ve used scrum template), and change the format from {0} h to {0} coc.


Now you should update the team project with this new configuration with this command:

witadmin importcommonprocessconfig /collection:http://localhost:8080/tfs/fabrikamfibercollection /p:"test project" /f:c:\temp\commonconfiguration.xml

Basically is the same command as before, just change the command from exportcommonprocessconfig to importcommonprocessconfig. If you open again the board you can now verify that the format used to represent the amount of work is now expressed in Cup Of Coffee.


Figure 2: Task estimation is now show as Cup Of Coffee unit of measure

The only change is the label: coc instead of h, all the rest is the same because it is just a change in how the RemainingWork value is formatted to the user. This changes is reflected in all the part of the agile planner, as an example the capacity of the team is now also measured in Cup Of Coffee.


Figure 3: Capacity of the team uses the same format, so you have now capacity in Cup Of Coffee

If you always use a different unit of measure instead of hours, you can simply download the entire process template, change the xml file and upload the process again on the server, so every new Team Project created with that template will use this new configuration. Just remember that, if you update a common process template, you should  pay attention when you will upgrade TFS with newer version, because you should double check if automatic process template upgrade procedure have not broke the standard upgrade procedure. You can find lot of detail on procedures needed to upgrade process template in MSDN, especially the second link, that shows how to update the process manually if the automatic procedure does not work.

Gian Maria.

Team Foundation Service, december update

One of the great advantage of using Tfs on Azure, called Team Foundation Service, is that you never should worry for update of the server, because everything is managed by the TFS team. If you already have an account, you probably noticed that the UI is radically changed, as described in Brian Harry’s post, new features were added, a new UI is available and everything was done without any need for you intervention.

Another advantage of this approach, is that we can benefit from regular updates of TFS, instead of waiting for 2 years before the next release is available. As Brian stated

We are now trying to transition our “major” update cycle to monthly.  I won’t promise that we’ll have major new features every month but we’re going to try to move to a cadence where we have new features show up in more months than not.

This is really cool and is another great advantage of using Team Foundation Service. In this new release, alerts were introduced:


Figure 1: The alert control panel.

The alerting system is something that is available in TFS from long time, but it was not available on the Team Foundation Service until this release, mainly because it needs a complete new Web Interface to manage alters. (Actually in TFS 2010 you can manage alerts from Visual Studio). As an example, this is the interface that permits you to add an alert whenever someone do a check-in in the project.


Figure 2: All possible check-in alert available in Team foundation Service

The cool part is that everything is done from a Web Interface that is fast, fluid and really efficient, when you select a check-in rule (in figure2 I choose to have an alert when any checkin occurs) another dialog permits me to refine the alert.


Figure 3: Check-in alert rule dialog.

As you can see, setting an alert on checkin is matter of few clicks. Clearly you can setup alerts for Work Items modification, for Builds and for Code Reviews (a new feature of next version of VS+TFS).

If you did not subscribe yet to this preview, check Brian’s post with a new invitation code (TfsDecUpdate), you can find details here.

Gian Maria.

TFS Pills: merging conflicts during unshelve.

Shelvesets are a really useful concept in TFS, and you should be aware that thanks to Power Tools you can even do a Merge during an Unshelve in case of conflicts. As an example suppose this simple and stupid scenario, you have this code.


Figure 1: Original Code

Now lets generate a conflict with Shelveset; simply typing some text.


Figure 2: Modified code, insertion of a simple comment.

I’ve simply typed some comment into the class, now Shelve the file without preserving pending changes, the file reverts to the code in Figure 1, now modify again the comment of the class as shown in Figure 3       

Figure 3: Another modification done to the class, this modification conflicts with the version in Figure 2.

Now check-in and commit this code (this simulates the situation when you need to suspend with shelve the work you are doing to accomplish higher priority task), then unshelve the previous shelveset, as you can verify the code revert to that one shown in Figure 2, and you lose the modification of the last check-in. This happens because the unshelve operation does not trigger a merge in case of conflicts. If you looks at the output windows you should find a message telling you that a newer version exists in source control as shown in Figure 4


Figure 4: A warning by the source control, a newer version of the file exists.

Now you should simply reissue a Get Latest command and TFS will present you a list of all conflicts that originates from the unshelving operation.


Figure 5: Issuing a Get Latest will trigger the conflict windows that shows each file that conflicted after the unshelve operation.

This is a situation where you have a simple conflict when a file that got in the shelveset was modified and checked-in after the shelve operation, you can merge with the tool of choiche, accept both the comment and check-in, to proceed to the next example. The situation of the file is now represented in Figure 6 and this is the starting point of another example of merging shelvesets when a conflict happen between two users


Figure 6: Both comment where accepted during the merge.

Another type of conflict arise from unshelving conflicting code from another developer. Suppose Dev A and Dev B start both from the code in figure 6, Dev A types a third line of comment telling “third comment lineand shelve the code. At the very same time Dev B does a conflicting modification, typing a third line of code that states “conflicting third comment line” and after this modification, she receives a call from Dev A that asks to review his shelveset. If Dev B try to unshelve the shelveset from Dev A she got the error in Figure 7


Figure 7: It is not possible to unshelve because of conflicts.

This happens because the standard unshelve operation does not permits to handle conflicts, if Visual Studio unshelve a conflicting file from Dev A, all the modification pending from Dev B will be lost. This is an annoying situation that you can solve with Power Tools.

If Dev B want to merge the code in the shelve of Dev A with her current code, she should open a Visual Studio Command prompt, move to the workspace where the project resides, then issue a tfpt.exe unshelve command directly from command line. The command line utility will open the same UI to unshelve that you got in Visual Studio, but now, when she browse to the shelvesets of Dev A and try to unshelve, she got a nice windows that shows all conflicts.


Figure 8: Tfpt.exe unshelve presents you a list of all conflicts that occurred during the unshelve operation

Now you can try automerge, and if it fails, you can press the “Resolve” button (or you can directly go for the “resolve” button without try automerge if you do not like to automerge conflicts 🙂


Figure 9: Resolve conflict during unshelve.

In Figure 9 you can see how to ask for a manual merge. Pressing OK Will open the standard tool for merging, you can now do a manual merge and save the result of the merging. Taaadaaaa, thanks to Power Tools you are able to unshelve conflicting shelvesets made by other developers.

Now what happens if Dev B want to revert to the original code she has before merging with the shelveset of Dev A? No problem, because the tfpt.exe unshelve command had created a backup shelveset with all the pending changes just before the merging operation, so if you want to dischard all the modification and revert to the same code that you have prior of the unshelve operation, you can issue another tfpt.exe unshelve operation, choose the backup shelveset (it has the same name of the unshelved shelveset with the string _backup appended), and when the Resolve Unshelve Conflict windows appears (Figure 9) you can simply choose to undo my local changes and take the shelved changes, and you are done.

Happy shelving.

Gian Maria.

Manage disconnected team with TFS

Suppose you have this scenario, a team is working on company office to create some software that communicate with some complex hardware that will be deployed to a foreign country. When is time to set up everything in production the team goes physically to that foreign country and they will modify the software on the field doing final adjustments but usually they have no connection to the central office. How could you manage to keep your source code aligned when the team is on remote site not being able to access the central TFS?


If no local person will access the team project during the period in witch the team is in the remote site, you can create a Project Collection dedicated to that team, then when the team will move to the remote site, they detach the collection, bring it with them with another installation of TFS, and when they’ll come back into the office, they will reattach the collection to the original TFS.

If people from central office should being able to access the Team Project from central office, while the team is working on code on customer’s remote site, Integration Platform could be the solution.

You starting creating another installation of TFS (usually on a virtual machine), and create a Team Project with the same name of the original Team Project or a similar name like original name portable, then install the Integration Platform on this Virtual Machine and configure an integration between the two Team Projects. First of all open the Integration Platform interface, choose “Create New” and then choose Version Control if you want to keep in sync only source code, or VersionControlAndWorkItem if you want to keep in sync both WI and Source.


Figure 1: Choose to synchronize only version control if you are not interested in Work Items.

Now you need to specify the two Team Projects that you want to keep in sync, you can store the credential to access those two server in Windows Credential Manager, the final configuration should resemble those one in Figure 2.


Figure 2: Configuration of Integration platform to keep in sync TailSpin toys and another Team project on a portable Virtual Machine.

Now you can press “save to database” and the configuration is ready to be executed simply pressing the start button. When the integration runs, you can be presented with conflicts, this is an example.

A namespace conflict has been detected between the source and the target system for the following item: $/TailSpinToysPortable/BuildProcessTemplates/UpgradeTemplate.xaml;39

The problem is that the destination Team Process Template already contains that specific file (it is a default file for a Team Project), so you need to resolve these conflicts simply telling to the Integration Platform the changeset you want to keep for each conflicts. Since this is the first synchronization between a full project and an empty one, the only conflict you can find is in the three default build template files.

Now you can stop the synchronization, take the Virtual Machine with you and let call it REMOTE TFS. When you are in the remote customer’s site all team members will create a new workspace against REMOTE TFS. During the typical working day, the remote team will operate on REMOTE TFS, then you need to synchronize everything with the central server when you are able to reach your primary server again. Usually this happens when the team returns to the central office. Now you will open the Integration Platform interface again, open the right synchronization project  and press start again, now all the modification done to REMOTE TFS will be migrated to your central TFS.


Figure 3: The integration platform tool moves back all changeset to the central TFS machine.

If you do not create a user mapping between the two machines, you will end up with warning message in the Integration Platform log telling you that it could not find the identity xxxxxxxxxx. This happens if the two tfs does not belongs to the same domain (es. you have no Active Directory in your organization), so you need to manually modify the XML configuration file adding User mappings. The drawback of not creating the mapping between users is that all check-in are made with the user that you use to connect to TFS in the integration platform. As an example I modified some files on REMOTE TFS, then issue a sync and I see that all check-in were made by Abuobe. In this situation you should look at check-in comment to understand witch is the original user that issued this check-in

modification to the interface (TFS Integration from ‘ (VC)’ Id: 139;CreationDate: 2011-08-12 16:56:38 UTC;)((Edited by WIN-Y4ONZS094UP\Administrator))

The comment contains the original comment (modification to the interface) as well as complete note from Integration Platform on the original check in date, and the original user that issued the check-in.

To minimize the chance of conflicts during the integration, I strongly suggest to the remote team to create a branch in the original TFS before the synchronization starts, then during remote work they will work on that branch against the REMOTE TFS, no one from the central office should touch that branch. Finally when the team returns to the central office you start again synchronization from the Integration Platform and you are sure that no conflict will occour. When the sync is complete, that remote branch is now the “release” branch, because it contains the code that is actually running in the customer factory.

If you choose a sync configuration that will keep in sync even the Work Items, the remote team is able to create bug, issue to keep tracks of what is happened during remote development :).