Dynamics AX 2012 - Visual Studio Team Services Custom Work Item Fields Break Version Control (Error TF237121)

We've been using Visual Studio Team Services (VSO) on several projects as or project management and version control solutions for Dynamics AX successfully for several years.  Recently though, AX occasionally presents us with one of these gems when logging into the client:


"TF237121: Cannot complete the operation. An unexpected error occurred." and "Failed to update metadata cache. (Object Model)".

You may have seen this error before.  Generally, from my experience, this coincides with an update that Microsoft has pushed to VSO.

The fix is generally quite simple:  Navigate to C:\Users\[Your User]\AppData\Local\Microsoft\Team Foundation\3.0\Cache and delete all the files in that directory.  You may see several versions; 3.0 is the version AX 2012 R3 uses.

Upon clearing the cache and restarting the AX client, the issue goes away and you can happily version control again.

However, a few days ago, this fix stopped working for us.  No matter how much I cleaned the cache, the error persisted.

So why does the cache clearing fix suddenly stop working in this case?

Well, it turns out, with Microsoft's latest patch to VSO, they added the ability to customize work items.  You can now add new fields to any work item type.  For example, in our project, I wanted a field to track if a work item needed a Hotfix or Model to be installed in order to resolve the issue.  I customized the VSO process, and added the following field to the Bug Work Item type:

This is where our issue comes.  The WorkItemStoreProxy in object \Classes\SysVersionControlWorkItemProviderTFS in AX does not know how to handle this new field in the work item, and gives us the errors above.

There are two options to fix this.  The first is to remove your customized field from the fields tab of the work item (simply removing form the layout won't work).  Don't worry, the data in the database is still there; it just isn't served from the service when querying the item.  The downside is that you can't use the customized field any longer (removing any benefit from customization in the first place).

The second is to use the fix found (found in this thread).  Upon commenting out the following code in \Classes\SysVersionControlWorkItemProviderTFS, appears to fix the problem:

While this will allow check-outs and check-outs to function correctly, this breaks the ability to link work items to a change via the work items tab.

I've filed a ticket with Microsoft to resolve the issue.  I will update this post with the results of that ticket.