I originally wrote the previous article – Shared vs. isolated Dynamics AX environments – primarily as an introduction to this post and to be able to refer to it. It provoked unexpected amount of discussion – and that’s great. The comparison of both approaches should help you to choose the most suitable one and point out some problems that may need to be dealt with. This post describes how to solve one of these problems – namely how to use multiple Team Foundation Server workspaces in a shared environment of Dynamics AX 2012 (not supported by default). The previous article should have shown you that you may want to use entirely different approach.
AX2012 supports only a single TFS workspace and that is created as private, so version control in such environment can’t be used by anybody but the owner of the workspace. One solution is a public workspace - that works well as long as you are aware of its limitations. Strictly speaking, the public workspace is – from TFS perspective – still used by a single user – its owner. For example, if a file is checked out from version control, TFS knows in what workspace the file is used and knows what user owns the workspace. But it knows nothing about what user currently uses this public workspace.
If you want to use the environment for normal development, public workspace probably won’t suit you very well. So if you plan using shared AX2012 environment and TFS, you should think about how to solve this problem before starting the implementation.
You probably won’t do without multiple workspaces and as it was said, AX2012 doesn’t support them out of the box, therefore it requires a code change. Every user should have his own (private) workspace, but because common code is used in shared environments, workspaces need to use the same code as well (see also AX TFS FAQ). The solution is to create a separate folder (and workspace) for every user and redirect them to a single common folder. You can use junction points or symbolic links for this purpose.
That’s exactly what is provided by the extension described below. It allows defining workspaces for individual users and creating symblic links right from Dynamics AX. And of course, it changes application logic to use these new workspaces.
Addax
Before describing the extension itself, I must mention one more thing that the extension depends on and that is included in the .xpo. I developed a simple system for my own needs to manage various developer-oriented extensions and the modification for private workspaces is one of its plugins. Although I currently don’t plan to publish any other plugins and having a whole system for a single plugin is obvious overkill, I’ve decided that it may be useful for others, at least for inspiration.
I call it Addax, which is an abbreviation for Addons for AX and also an animal. 
Installation
The zipped .xpo is downloadable from here. Import it to Dynamics AX 2012 (developed in RTM version).
The .xpo contains several standard objects – not many, but still you should ensure yourself that there is no conflict.
Version control setup
Version control setup doesn’t contain any parameters for individual workspaces. The folder set as Repository folder is simply used as parent of all workspaces.
When you finish the configuration described below, come back to this dialog and enable version control.
Plugin activation
In the imported project (AddaxWorkspaces), find and run the AddaxPlugin menu item. The form doesn’t contain any plugin in this moment, so search for plugins by pressing Update plugins button. Activate User repository plugin and go to configuration by the Configure button.
Workspace configuration
Configuration is simple – just create a new record, choose a user ID and save. The path to the workspace is automatically assembled from the repository path (defined in version control setup) and user’s Alias.
The corresponding folder is created simultaneously with saving the record:
Here are symbolic links for users administrator and hal and a common folder Shared which all links point to (and which is also created automatically).
You can easily see the target object in link’s properties.
When deleting a record in the form, the corresponding link is removed too.
This solution has some theoretical limitations, for example it can’t be used for two users with the same alias (but different domains) but I don’t think it is a real problem.
Workspace is not everything
It’s great to have a separate workspace for every user, nevertheless AX 2012 expects that there is just one workspace. For example, if AX needs a list of checked-out objects, it asks TFS for objects in the given workspace. It obviously knows nothing about other workspaces.
Could it be changed? Sure, it could. I didn’t implement it simply because I haven’t needed it so far.