Team Foundation Server workspace (creating a working copy of a part of TFS repository) can be by default used by a single user only – by its owner. A problem occurs, for instance, if Dynamics AX is installed (including a connection to TFS) by an administrator account and other user (users) then uses this environment. Dynamics AX shows the following error message to the other users when it starts:
Team foundation server error
The working folder {path} is already in use by the workspace {workspace name} on computer {computer name}.
Team Foundation Server 2010 (but not its lower versions) allows to easily solve this problem by declaring a workspace public. Then other users can either perform all actions just as the owner (Public workspace) or they can use the workspace without a possibility to change the configuration or perform check-in (Public workspace (limited)).
This setting is defined in Edit Workspace dialog:
Edit Workspace dialog can be open in Visual Studio by File > Source Control > Workspaces… and clicking Edit… button.
It can be even started from command line, for example:
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE>tf workspace MyWorkspace123
Great post, Martin! Public workspaces do enable some scenarios in the ‘shared AOS’ development model for AX. I have also been experimenting with this and wanted to point out a couple of behaviors that you should know about if you plan to leverage this:
1. Any file checked out is shown to be checked out to the owner of the workspace. Specifically, if Dev2 checks out a file in a workspace that Dev1 created, the file will show as being checked out to Dev1.
2. Any file that is checked out is checked out to the workspace. The impact of this is that Dev2 can check in a file that was checked out by Dev1. This is the case regardless of whether the “Enable multiple check-out” flag is set. This flag locks a file, but it is locked to a workspace and not to a user of the workspace.
Microsoft has also recently authored a white paper on shared AOS development. It can be found at http://www.microsoft.com/download/en/confirmation.aspx?id=26919.
Dave Froslie
Software Test Architect
Microsoft Dynamics AX
Hi Dave, thank you for the excellent comment. I must admit I completely missed that white paper.
The points you mentioned are not so surprising, but the white paper contains some issues which I’ve never thought about – e.g. the need to use a separate AOS to debug IL code.
We’re planning to move to TFS in the near future so this is very relevant topic for us. BTW I like the idea to have isolated development of AX solutions, but the reality is that most of partners are quite satisfied with shared development environments, so they have no strong reason to completely change their approach.