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

• 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 ) 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.:

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

Woohoo!

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.

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.

In the last post, we installed the Ax database and Application files. This post will describe installing the remainder of the Dynamics Ax bits.

Installing an AOS Instance

In order for development to occur on a developers machine, a local AOS instance will need to be installed for each branch of TFS Version Control that will be used on the developers machine. This enables a developer to be independent of other developers, while integrating their source into the ALM process of TFS 2010.

• Start the Dynamics Ax install. Select the default language then select OK

• Select Next

• Accept the software licence then select Next

• Select Custom Installation then select Next

• Select the Application Object Server (AOS) and select Next. If you are installing on Windows 7, then a warning is shown regarding Windows 7 not being supported. Select Yes

• Accept Microsoft SQL Server and select Next

• If you are warned about pre-requisites then select the Install prerequisite software

• Accept the default install location and select Next

• Ensure that the database created earlier is selected then select Next

• Accept the defaults in the AOS: Locate the application files

• Accept the instance name and the port then select Next

• Select the Network Service then select Next

• Ensure that the Start the AOS instance after installation is completed is not selected then select Install

• Select Finish

• NOTE. This will need to be repeated for each “instance”. (e.g.: DEV, MAIN,REL,HOTFIX for our example)

Install the Dynamics Ax Client

If the Dynamics Ax development client has not been installed, then install as detailed below

• Follow the steps as above until you get to the Add or Modify components section.
• Select Client in the Base section then select Next

• Select your language then Next

• Select Install

Install Other Components as Needed

The other components can also be installed at this point. Note that WSS development would not be able to be installed on a client OS (e.g. Windows 7) as WSS 3 cannot be readily installed on Windows  7. For Enterprise Portal development, a separate Server Development machine would need to be installed, following the installation procedures as described in these blog posts. This is left as an exercise for the reader.

Notes

• Create a configuration for the instance that you want to connect to using the Microsoft Dynamics AX 2009 Configuration tool. Save the configuration file to a directory (e.g. C:\Program Files\Microssoft Dynamics AX\LocalConfiguration) and create a shortcut using the newly created configuration file as the target. An example of the Target setting for a shortcut is given below:

"C:\Program Files\Microsoft Dynamics AX\50\Client\Bin\Ax32.exe" "C:\Program Files\Microsoft Dynamics AX\LocalConfiguration\LMAx5_MAIN.axc"

• Ensure that the client has been started once, and that the instance has been configured and compiled. Also, ensure that the initialisation list has been completed.
• Copy your current source to the Appl\Instance directory, overwriting the source files that are installed by default. This will ensure that when we get to the Add to TFS step in the next post that your source code will be added. Example is given below:

C:\Program Files\Microsoft Dynamics AX\50\Application\Appl\LMAx5_MAIN

• Make sure that the following hotfix has been applied. This should enable the installation of the Reporting Services bits, but your mileage may vary. We had a lot of trouble getting the reporting services developments pieces to install, and ended up leaving them on the original server that was used for development:

https://mbs2.microsoft.com/Knowledgebase/KBDisplay.aspx?WTNTZSMNWUKNTMMYXUPYZQPOUXNXSPSYRYYMQTUNYUROMKPUTXTUVNQONXVWPPQN&wa=wsignin1.0#appliesto

• If you are installing on Windows 7, then you will not be able to install the Role Centre and Enterprise Portal components, or the Enterprise Portal Development bits.

The next post will get to the interesting bits, where we actually integrate the Dynamics Ax development environment into TFS 2010.

Before you install any of the Dynamics Ax components on any of the Development machines, there are a few things that you will need to determine first.

First, you will need to determine what your branching and release strategy is. This is the key step to getting your Dynamics Ax environment setup for ALM with TFS 2010. Some really great examples of branching strategies can be found in the Visual Studio Branching Guide 2010.

The example used in his blog series is one adapted from the branching guidance:

As can be seen above, there are 4 source branches which we will use.  Using the Branch Visualisation in Visual Studio 2010, we will end up with a branch hierarchy as shown below:

So, what we are going to end up with is 4 installs of Dynamics Ax that each correspond to a branch in the branching hierarchy. Note that this is only necessary if a development machine will be used for all branches. Typically, developers would only have a DEV and/or HOTFIX branch on their machines, as the other branches would be used by a team leader/manager to perform the merges and any release management.

The procedure outlined below will detail the install method used for the MAIN project. This is the first one that needs to be done,a s it is the main branch from which all the other branches will be created, and as such, makes it easier to manage the development setup process.

Install a Dynamics Ax Instance for the MAIN branch

• Start the Dynamics Ax install. Select the default language then select OK

• Select Next

• Accept the software licence then select Next

• Select Custom Installation then select Next

• Select Database and Application Files then select Next

• Enter the name for the database (e.g. LMAx5_MAIN) and then select Next

• Enter the name for the AOS server (e.g. LMAx5_MAIN) then select Next

• Select Next on the Application Files: Select a country or region

• Select Install

• Select Finish

The next post will describe installing the AOS server instance for the MAIN branch.

Software development is complex, and becoming more complex every day. Consumer products such as the iPhone and iPad are driving users expectations for software to be more polished and feature rich. In the past, users were far more forgiving on software and web sites, but these days that is not the case. As software becomes more complex, so does the process involved in producing high quality software.

Software engineers are being asked to cope with more rapid change, while the expectations are constantly rising. Today, a large number of software projects fail for a number of reasons, due in part to failure to manage the development process, or using a process that does not fit the product.

Development frameworks, such as SharePoint or Dynamics Ax, are a response to this complexity. By providing a framework in which to develop an Enterprise application, the plumbing layers are abstracted away from the developers, allowing them instead focus on the problem at hand.

However, there are still issues when it comes to multi-developer development in such frameworks. Traditional software development using traditional tools such as IDE’s relied heavily on a Version Control Systems to assist developers in managing a codebase across a number of developers. These tools allowed a number of distributed developers to work concurrently on a codebase to produce a software result.

A lot of frameworks, however, are not designed with this in mind. Case in point, Dynamics Ax was not designed with Application Lifecycle Management in mind. Integrating Application Lifecycle Management tools and practices into these types of frameworks can further increase the productivity gains that come from using a framework.

This series of posts will detail one method of integrating Dynamics Ax with Team Foundation Server 2010. By integrating Dynamics Ax with TFS 2010, the Application Lifecycle Management tools and reporting that TFS 2010 gives to traditional Software Development can now be realised with Dynamics Ax.

Just to note that these posts have been written as a guide for those that, like me, have found little detailed public information on integrating Dynamics Ax 2009 with TFS 2010. Whilst a number of posts do mention that it is possible, they are short on detail and implementation guidance. I hope that these posts will be useful to someone who is looking for a realistic integration scenario.

So without further ado, lets start!

Overview of the Problem

Recently, a client approached us with an interesting problem: How to integrate TFS 2010 with Dynamics Ax. This was indeed an interesting problem for a number of reasons:

• Dynamics Ax is a recentish Microsoft acquisition, and as such has it’s own way of doing things
• Dynamics Ax is very much a Business server, with a different language (X++) and different way of developing
• Was not designed with Version Control in mind, with capability provided in later releases
• Expertise in Dynamics Ax is hard to find, as Dynamics Ax is sold more as a partner product, rather than an end-user product such as other Microsoft software.

This posed a number of challenges, one of which was the lack of public documentation. Most of the documentation (and even the service packs and patches) are only available via Partner Source or Customer Source, which are programs run by Microsoft that requires more formal registration than other Microsoft products.

So, with that in mind,we set off to investigate a method that would allow the client to use TFS 2010 to manage their current agile process.

The first problem we had to overcome was the installation of Dynamics Ax itself. Since this was the first time I had ever installed Dynamics, it was going to be an interesting process.

Installation Overview

Dynamics Ax is made up of the following components:

• An AOS Server that provides a service that manages the Dynamics object
• A database that holds the Dynamics Ax configuration
• A Client that is used to develop with
• Other development services, such as SharePoint integration and reporting services

From a high level, the following are the steps we took to integrate:

• Install TFS as usual.
• Install a Team ID Server
• Install a Development machine
  • Install SQL Server 2005 + SP2
  • Install Visual Studio 2008 + SP1 + TFS 2010 Cumulative Update
  • Install Visual Studio 2010 Team Explorer
  • Install any other software that is required (e.g. Office, SQL DB 2008 R2)
  • Install an instance of Dynamics Ax
    • Install an AOS client and server instance
    • Install the developer instance and any supporting components (e.g. Biztalk integration)
  • Prepare TFS 2010 for Dynamics Ax
  • Prepare Developer machine for TFS 2010 Integration
  • Integrated Dynamics Ax with TFS 2010 and the Team ID Server
  • Modify the Dynamics Ax TFS Workspace
• Development tips and tricks

So look out for the first of these posts over the next week!