Controlling the Visual Studio workspaces to your Dyn365FO developers

Introduction

At the time of writing, doing development for Microsoft Dynamics 365 for Finance and Operations (FnO) require a dedicated development machine. This machine is pre-configured with Visual Studio extension that allow for achieving FnO development. One important and perhaps peculiar fact with these environments is the fixed disk location where you can create, edit, save and build your modifications. The folder is more often referred to the "Package Local Directory", but I will use the acronym PLD in the rest of this article. This is the folder containing the packages/modules, and you may have them either with or without source code. Typically vendor solutions are shipped only in their binary form, meaning you do not have the "design time" metadata, but only the "run time" payload. As for Microsofts own packages/modules, you will typically have both the metadata and the binaries, allowing you to view and step through code while developing and debugging. And of course, your customizations (assuming you are a developer) will have its metadata, and after your local first build, its binary counterpart (plus other artifacts, depending on what you're creating).

Workspace

This post is about the "workspaces" in Visual Studio.

So what is the deal with the "workspace"? Well, it is a necessity when you want to develop. It is basically what defines the paths to your local copy of the code you are sharing with the rest of the team. And for FnO there is one path that is fixed, out of the box, and that is the PLD.  You are free to setup other folders, and share them with the team, but the workspace needs to have at least one entry that refers to the PLD. All customizations you want to share with the team, and share with the BUILD machine, needs to be in the PLD, and added to source control and committed to the central code repository.

Ok, so that is all fine. Any other considerations?

Yes! The developer who creates the workspace actually ends up being the "owner" of the workspace, on that machine. So if another developer connects to the same machine and wants to develop, using their own user and credentials, the second developer needs to be able to work against a workspace pointing to the PLD. Otherwise, the second developer is blocked from doing development.

So what's the problem? Well, by default, a newly created workspace is private and only the owner of the workspace can use it. To make things worse, any other user who wants to create their own workspace on the same machine will not be able to point it to the PLD. Only one workspace can point to a single folder at that machine at a time, and the PLD is such a fixed single folder (at the time of writing).

There is a solution, though. The initial owner needs to change the workspace from "Private" to "Public", allowing any other developer connecting to the same machine reuse the initial workspace.

This is a simple solution where the same development machine is shared between developers. It is also smart if for any reason a developer has pending changes on that machine, then takes a few weeks of holiday, and another developer needs to connect and commit them. Yea, that can happen.

Administer the Workspaces

Ok, so what if the developers create the workspaces themselves, and set them up as Private, forgets and then someone else have to reuse it. Or if you simply want to go through and check the created workspaces out there.

Well, the workspaces and information about them is also stored centrally, and someone with the "AdminWorkspaces" privilege can change them (a permission by default granted to the Azure DevOps (VSTS) Organization Security group called "Project Collections Administrators").

So in this post I will show how you can do this. There are several articles and posts out there discussing this, but it's always nice to share this in the context of Dyn365FO development, in my opinion.

If you have the necessary permissions, you can run the "Developer Command Promt for VS2015" available on one of your development VMs. I here assume you have run Visual Studio at least once, and connected to your Azure DevOps (VSTS) organization you are working towards.

If you run the following command, it will list all the workspaces created.
tf workspaces /owner:*

You will see a list of workspaces by the name, owner and machine. The next thing you can do is edit one of the workspaces by running the following command:
tf workspace WORKSPACENAME;OWNER  

When referring the owner, use the email address for simplicity.

The workspace form now lets you change the properties like permissions from Private to Public, and you can even change the owner (again, use the email address) if you for example need to take over the workspace of someone who has since been deleted as user.

You can also remove old and obsolete workspaces by using the following command:
tf workspace /delete WORKSPACENAME;OWNER

It goes without saying, changing the workspaces while they are in use, is obviously not very smart. Change the workspaces with care, or you might ruin someone elses work and day.

Using Team Foundation Sidekicks for VS2015

There is another option as well, a free tool that also lets you administer workspaces, if your user has the necessary permissions.
You can download it from here:
http://www.attrice.info/downloads/index.htm#tfssidekicks2015
(Tip! Use Google Chrome to download the MSI, if Edge/IE blocks you)