Microsoft Dexterity crashes when checking resource version information and status from repository with Visual Studio Team Services - Part 1

This is the first of two articles in which I will highlight a couple issues we ran into with Dexterity, after our migration from Visual SourceSafe (VSS) and Team Foundation Server (TFS) to  Visual Studio Team Services (VSTS). While my initial intent was to simply dive into the issues at hand, I figured I wouldn't be succesful in getting the message out without a full background in which I would explain the migration process both the Visual Studio and Dexterity configurations required to work with VSTS.

The Migration

Ahhh, the brave new world!

Just recently I worked with my team to migrate our source code repository from VSS and TFS to VSTS. Our main goal was to make our code accessible 24/7/365 from anywhere in the world by standardizing access for all of our developers and providing a unique, consistent experience. After all, accessing code in two different repository systems is not precisely an ideal situation. We also wanted to consolidate source control servers and streamline our IT infrastructure.

VSTS is a collection of Microsoft online services for development teams to share code, track work, and ship software -- for any language. The majority of our code happens to be Microsoft Dexterity code, although we carry a good amount of Visual Studio code. The added advantage is we could use our Microsoft Organizational Account -- the same one used with Office 365 and Microsoft Azure -- to access the online source control repository, which meant less administrative work for our IT personnel.

To perform the migration to VSTS, we first had to move all our source code repository to TFS. To move to TFS, we downloaded and used the Visual SourceSafe Upgrade Tool for Team Foundation Server which allowed us to consolidate all our code in one single place and make sure we accounted for everything prior to the big push to VSTS. Once we had all our code inventory in place, we then used the same tool to move the repository to VSTS.

Surprisingly, this was a pretty straight forward process and we were able to come out on the other side with just a couple of incosequential warnings.

The Configuration

In order to connect to our online repository, we first register the VSTS service with Visual Studio. After all, Microsoft Dexterity leverages the Visual Studio libraries to facilitate this process.

Add Team Foundation Server (Team | Connect to Team Foundation Server)

Once the connection to the online repository is in place, a workspace must then be setup to allow for local caching of resources in the repository -- Visual Studio also uses this to allow developers to work offline from the repository.

Visual Studio Workspaces
After creating the workspace, the next step called for downloading the content of the repository or specific project onto the local cache folder, using the Get Latest version option in the Source Control Explorer pane in Visual Studio -- this is probably the only thing different when compared to VSS.

Source Control Explorer
The rest of the setup happens in Dexterity, where it is necessary to edit the source control settings to point to the online repository. Dexterity 12 (12.00.0323.00), Dexterity 14 (all builds), and Dexterity 16 (all builds) have native support for a Team Foundation Server provider -- I guess, it is worth mentioning that the Dexterity Source Code Control Service (DSCCS) has been deprecated in favor of the much more robust providers.

Source Control Options in Dexterity
As customary with Dexterity, it is then necessary to update the source code control state for the resources, if this is an existing dictionary or update the dictionary with the content of the repository in the project, if this is a new dictionary.

At this stage everything seemed to work as expected. We completed some tests checking out, editing, and checking in resources and life was good up to this point.

Tomorrow I will talk about the issues that we encountered and the main reason for this series of articles.

Until next post!

Mariano Gomez, MVP


Thank you for the post. Here is a solution to a problem I had related to that.

When I first tried to setup Dexterity with the "Team Foundation Server 2013" provider I experienced this issue:
"The source code control provider did not initialize properly"
That was the error message and no more detail was given.
I already had Visual Studio 2015 setup on TFS properly but that was not enough.

The solution was to install Visual Studio 2013 and configure TFS in VS2013 first.
Then I was able to configure Dexterity 14 to use Visual Studio Online.
Marcos said…
Hi Mariano. Where did you find Dexterity 12 (12.00.0323.00)? The latest version that was provided with GP 2013 R2 is 12.00.311.
I would be very grateful if you could provide me with a link to download it.
Thanks in advance

Mariano Gomez said…
Thanks for your post.

Mariano Gomez said…
You can find Dex 12.00.0323 at

CustomerSource access required.

Martin said…
is it possible to connect previous versions of dexterity to team services? i'm still using versions 9, 10 and 11
Mariano Gomez said…
I really have not ran any test with previous versions of Dexterity. Since Dex is highly reliant on Visual Studio to connect to Team Services, I would be surprised that older versions of Visual Studio could do this anyways, so I'm going to go out on a limb and say it is not possible.
Unknown said…
Mariano, I'm confused. I have dex16 installed and vs2015 installed. VS2015 is connected to my vsts just fine, (i can see all my vs projects just fine). My question is this: Do we still have to install TFS with the 2015 versions? I also don't understand the root directory. Shouldn't that point to my url? It looks like yours points to a local directory.
Mariano Gomez said…

Sorry for the late reply.

You do not have to install TFS, but you do have to have Visual Studio as Dexterity uses the Visual Studio libraries to connect to Team Services. When you connect Visual Studio to VSTS, you are in effect connecting to the URL. However, your projects will show up under the URL in Visual Studio. These need to be mapped to a local folder. Visual Studio and Dex use the files in those folders to check in and check out changes with the repository.

Popular posts from this blog

Power Apps - Application Monitoring with Azure Application Insights

eConnect Integration Service for Microsoft Dynamics GP 2010

Troubleshooting the Microsoft Dynamics GP 2013 Web Client - Part 3