Skip to content

Integrating Dynamics Ax 2009 with TFS 2010–Part 6: Integrating with TFs 2010


In the last post, we detailed the Dynamics Ax installation steps. We are almost there now!

It has been a long journey to get to this point, with a lot of setup required before we can actually integrate  Dynamics Ax with TFS 2010. But we made to here, so let’s jump in.

Create the MAIN Branch in Visual Studio 2010

Before we can actually integrate Dynamics Ax with TFS 2010, we will need to create a source repository or Team Project, depending on your strategy. For this blog series, we have used the following branching strategy:


As such, we created a Team Project (using the Agile 5.0 template), and created the main source folders, as can be seen below:


The branch hierarchy would look like the following:


NOTE: The example  above is the completed example, and shows the branches. It also demonstrates that the project can be used for more than just Dynamics, with other project types being used as well.

  • If you need a new Team Project, then create one using the desired template. This post assumes that a Team Project has already been created, and that it houses other project types (e.g. DotNet, VB6, etc.)
  • On the development machine where you are performing the initial integration, create a mapping between the Source Control for the Team Project and your local drive.
    • Create a folder on the local disk that will house the project. A recommendation is that the initial setup be mapped at a high level, to reduce confusion between workspaces. (This will become apparent a little later on, so for this demo follow this recommendation. Later, you may wish to change this). The example below shows a local folder of C:\Workspace\<user name>\<team project name>. This has been chosen as there may be more than 1 person logging in to the machine to do work. This will keep the workspaces separate from others on the machine.

e.g. C:\Workspace\Richard\LMApps

Create Workspace Mapping for Initial TFS Setup

To be able to create the folders etc., you will need a source to local drive mapping at the Team Project level. This will enable us to create branching structures, and will separate the Dynamics Ax workspaces from an Administration workspace. This sounds confusing at first, but if you follow these instructions, you *should* be ok. No guarantees though Smile

    • Create a local folder to house the Team Project mapping

e.g. C:\Workspace\Richard\Merge\LMApps

    • Open Visual Studio 2010 Team Explorer. Connect to the TFS server, and open the Source Control node from the Team Explorer snap-in. Select the project node in the Folders pane of the Source Control Explorer. Right-click the project and select Map to local folder option
    • Select the folder created above then Map. At this stage, do not get the latest as there may be other code that is not relevant to this set of posts.
    • Create the initial folder structure in TFS and check-in. The higher level folders will now look something like below:


  • Also set up any Areas and Iterations that you require, as well as any security.

Connect the Dynamics Ax MAIN Instance to TFS

  • If you have not already done so, copy your existing source over the top of the default installed source on the development machine. For example, for the MAIN instance of Dynamics Ax installed on the machine, copy the source to the following directory:
  • If you have not already done so, create a configuration file for each of the installed Dynamics Ax instances. This is done using the Microsoft Dynamics AX 2009 Configuration utility that would have been installed with the client. Ensure that the correct settings are used (e.g. that the right AOS server is selected, that the correct layer has been selected, and that the correct Development key has been entered). Save these configuration files to a central location (e.g. C:\Program Files\Microsoft Dynamics AX\LocalConfiguration)
  • Also create the shortcuts and place them on the desktop. This is not necessary, but helps to standardise the installation.
  • Start Dynamics Ax. Navigate to the Microsoft Dynamics –> Tools –> Development Tools –> Version Control –> Setup –> Parameters menu.


  • Enter the TFS parameters on both tabs




  • If you get an error like that shown below, it means that the Team ID server information will need to be entered. Double click the error.


  • Enter the name of the server that is hosting the Team ID server (e.g. the TFS server) and choose the database that was setup when the Team ID Server was installed. Select OK


  • An Infolog dialog will be displayed that should look similar to that shown below. Close the dialog


  • Close the version Control parameters dialog, then reopen to ensure that TFS has been successfully bound. Close the Infolog screen then close Dynamics Ax. We found that this is the area that gave us the most issues, but should work as described above.

Fix the Source Control to Local Path Mappings

Assuming the above process worked as shown above, then what has happened is that Dynamics Ax has created a new workspace for the Dynamics Ax instance, and mapped the root of source control to the path selected above.

i.e. $/LMApps –> C:\Workspace\Richard\LMApps\DynamicsAx in the example shown above.

This will need to be changed so that the TFS workspace is mapped instead to:

$/LMApps/Source/MAIN/DynamicsAx –> C:\Workspace\Richard\LMApps\DynamicsAx

This is the critical part, as it will allow us to have multiple instances of Dynamics Ax on a developer machine with different mappings.

  • Open Visual Studio 2010 Team Explorer and connect to TFS. Open the Source Control Explorer and open the Workspace dialog using the drop down and select Workspaces


  • Select the XXXX_AXWORKSPACEX workspace and select Edit


  • Change the Source Control Folder to point to the correct place in the source control tree




  • Select OK. You will be notified that the workspace has been modified and that you will need to get the latest source to the local folder. Select Yes


  • Close the Manage Workspaces dialog, and start Dynamics Ax from the shortcut created earlier. You should get a dialog similar to the one shown below. If not, then something has gone wrong (obviously Winking smile ) and you will need to investigate further.


  • If it has worked,however, we now need to add the source to source control. To do this, we are going to create a project to hold only our changes (e.g. the VAP layer), rather than place the entire base objects in TFS. To do this, open the Projects dialog. Create a new Project, and filter for the objects that you want added to TFS. (e.g. all VAP layer objects)


  • Select the objects then Right-Click –>Add to Version Control.


  • Depending on the number of objects selected, this may take a while. To verify that the objects are being added to TFS, open Visual Studio 2010 and open the Source Control Explorer. Select the correct workspace then navigate to the source container where the source is expected to be.


  • In Dynamics Ax, right-click the selection then select Check In


  • Ensure a comment is provided then select OK


Create the DEV Branch

Now that we have the main source added to TFS, we can now start to branch the code so that the other environments can be integrated into TFS. For the examples above, we are going to branch and check-in the $/<ProjectName>/Source/MAIN/DynamicsAx to $/<ProjectName>/Source/DEV/DynamicsAx

  • Navigate to the source directory you want to branch in TFS Source Control Explorer, then Right-Click –> Branching and Merging –> Branch


  • Choose the target location then select OK


  • Check-in the branched code. Ensure a comment is provide then select Check In



  • You now synchronise your code with the associated AOS server, so that the database is in synch with the code. Ensure that the Force option is selected, as this will do a full synchronise.:
  • image



Repeat the above steps for each environment that you want to set up, for example a DEV environment.


If you have gotten this far, then you are almost there. Go and have a rest, and have a beverage of your choice. You have earned it. Smile

Next Steps

In the last past, we will wrap up the process, as well as give some tips on how to manage the development process with Dynamics Ax, including how to do the check-ins and daily development tasks.

18 Comments leave one →
  1. San permalink
    17/05/2011 2:31 am

    Hi Richard, very useful article. i have a question for you:
    – How do i change my AX Client to point to a different branch in TFS’s TeamProject ?
    Thanks in Advance,

    • 17/05/2011 5:47 am

      To change which Source Control path is mapped for an AX Instance, you need to edit the workspace for that instance. This is done in Visual Studio using the method described in “Fix the Source Control to Local Path Mappings” above.

      The AX client will use the details in the workspace, so you do not set it directly, but rather indirectly in the TFS workspace.

      Did that answer your question?


      • San permalink
        17/05/2011 6:29 am

        perfect got it, Thanks Again.

  2. San permalink
    19/05/2011 7:38 am

    Hi Richard, another question for you: can i check-out an entity(let’s say a Table) in 2 layers Cus and Usr ?
    Here is the detailed scenario: at my workplace’s AX implementation – our Vendor makes changes at CUS layer and we make changes at USR layer so that we can easily differentiate the changes and roll-back to CUS layer changes if needed.
    Now that we are planning to integrate our AX with TFS, as part of testing different scenarios i added an entity(CustTrans table) into TFS at both CUS and USR layer. Now AX is not allowing my Vendor to check out this CustTrans table at CUS layer, it is throwing this error message:
    “An object that exists in a higher layer cannot be checked out.”

    i am able to check-out CustTrans table at USR layer. If this is the way it works then how are we going to apply the patches from MS where they make changes at lower layers ?
    Any info about this wud be a grt help.

    Any info reg this would grt help

    • Mark permalink
      11/01/2012 7:33 pm

      Hi San, hi Richard
      I’m interested in this scenario, too. Does anybody of you have any further insights regarding that subject? Any information would be appreciated.
      Kind regards, Mark

      • San permalink
        08/08/2013 3:45 am

        Hi Mark, once AX 2009 is integrated with TFS I think it makes sense sticking to one layer for everyone (Vendor and Internal development). Let TFS handle the versions and change-sets.

  3. Neeharika permalink
    23/11/2011 6:26 pm


    Thanks for your reply for my query.
    When can we expect the next part?
    We are trying to branch the code based on releases like 5.0,6.0 etc… so wen 5.0 release is done ,we can work on 6.0 branch and not to touch 5.0 branch again.

    How to do that?

    Give some suggestions.


    • 29/09/2012 10:33 am

      If you look at the post above, there are examples of branching(DEV, HOTFIX, etc).
      This is the same as doing a 5.0, 6.0 release etc. Simply branch, then set the workspaces as described above. That should give you what you want.

      All the best with it 🙂

  4. abc permalink
    23/11/2011 8:49 pm

    good post

  5. Ashish permalink
    16/05/2012 3:09 am

    Truely Awesome Post……..

  6. Christian permalink
    29/09/2012 5:37 am

    Great post! Release helps.

    One question to avoid confusion on my side. In the 2nd screenshot you have additional projects like AX_MAIN, AX_HF, IMS etc. Are these relevant for the post or is only the LMApps relevant?


    • 29/09/2012 10:31 am

      Thanks. The other projects are not relevant to the post. They are just examples of how you can have multiple AX projects in 1 Team Project

      • Christian permalink
        03/10/2012 1:49 am

        Hi Richard,

        I am trying to set up my TFS quite close to your blog. When I look in TFS branches called “usp” and “usr” are being created. You seem not to be working with these. Do I need them? Can it be avoided, that they are being created so developers do not get confused where to check in new objects?

        Thanks for you reply.


      • 03/10/2012 5:25 am

        For my copy of Dynamics, I only have a key to use the usr layer. In the screenshots, the usr folder has not been shown, and it is beneath the DynamicsAx folder

        Hope that was what you were asking about



  1. Dynamics AX development using TFS 2010 « Enhance ALM's Blog
  2. Integrating Dynamics AX 2009 and TFS 2010–6 part series | My ALM Blog

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: