Microsoft Dynamics AX

Using Microsoft Dynamics AX

2009 Version Control
Integration
With Microsoft Team
Foundation Server
White Paper

This white paper describes how to use the version control

integration capabilities of Microsoft Dynamics® AX 2009 using
Microsoft® Team Foundation Server.

Date: July 02, 2009

Table of Contents
Introduction................................................................................................ 3

The Development Environment ................................................................... 4

Team Foundation Server ........................................................................................................ 4
Version Control Administration Server ..................................................................................... 4
System Settings ................................................................................................................ 5
Developer Machines .............................................................................................................. 6
Version Control Parameters ................................................................................................. 6

Security....................................................................................................... 7
Team Server Security ............................................................................................................ 7
Team Foundation Server Security ........................................................................................... 7

Daily Work .................................................................................................. 8

Object Life Cycle ................................................................................................................... 8
Add to Version Control ........................................................................................................... 8
Check Out ............................................................................................................................ 9
Undo Check-out ................................................................................................................. 9
Check In .............................................................................................................................. 9
Quality Checks .................................................................................................................. 9
Renaming Objects ................................................................................................................. 9
Deleting Objects ................................................................................................................... 9
Label Editor .........................................................................................................................10
Get Latest ...........................................................................................................................10
Synchronization ...................................................................................................................10
Synchronization Log .......................................................................................................... 10
Show History .......................................................................................................................11
Pending Objects...................................................................................................................11
Change List .........................................................................................................................11
Working Offline ....................................................................................................................11

Code Promotion ........................................................................................ 12

Layer Promotion ....................................................................................... 12

Build Process ............................................................................................ 13

Branching.................................................................................................. 14
Primary TFS Project..............................................................................................................15
Project Interaction ...............................................................................................................17

Labeling .................................................................................................... 17
Labeling as Part of a Proxy Build ............................................................................................17

Source Code Reset .................................................................................... 18

Best Practices ........................................................................................... 20

2

USING MICROSOFT DYNAMICS AX 2009 VCS INTEGRATION WITH TFS

Introduction
The MorphX® Integrated Development Environment (IDE) can integrate various Version Control
Systems (VCS). This white paper describes the following:
 The development environment
This section describes typical hardware and software topologies and setups that you use for
development under version control in the MorphX IDE in Microsoft Dynamics AX 2009.
 Security
This section describes how to implement security by controlling access to Team Server (the ID
server) and projects in TFS.
 Daily work
This section describes the version control functionality that you use daily when you develop under
version control. For example, checking an object in and out and using the history of an object to
investigate changes or roll back to a previous version of the object.
 Code promotion
This section describes the process of moving new or modified objects from the development
environment to the testing environment, and then to the production environment.
 Layer promotion
This section describes the process of replacing the entire layer Application Object Data (AOD) file
in the destination environment with the AOD file from the source environment.
 Build process
This section describes the process of promoting code that is in the version control system from
one environment to another using an XPO or AOD file.
 Branching
This section describes how you can use branching for remediation and bug fixes in previously
released versions without interrupting ongoing development activities.
 Labeling
This section describes how you can use labeling to mark milestones in the development lifecycle.
 Source code reset
This section describes how you can, as a last resort, reset your source code.
 Best practices
This section describes some best practices to follow while developing under version control in the
MorphX IDE in Microsoft Dynamics AX 2009.

USING MICROSOFT DYNAMICS AX 2009 VCS INTEGRATION WITH TFS

The Development Environment
The development environment consists of a server with a TFS installation, a version control
administration server, and various local development machines. For more information about setting up
these components, see http://go.microsoft.com/fwlink/?LinkID=152452.

Team Foundation Server

The Team Foundation Server should have:
 Microsoft SQL Server ® (local or remote)
 Microsoft Visual Studio® Team Foundation Server
 Microsoft Visual Studio Team Explorer
The SQL Server installation can be local or remote.
Note: If SQL Server 2008 is used, the Team Foundation Server SP1 Integrated Installation
process must be followed. For more information, see the Team Foundation Installation Guide for
Visual Studio Team System.

Version Control Administration Server

The version control administration server should have:
 Microsoft SQL Server (local or remote)
 Microsoft Dynamics AX® 2009 Developer installation (with AOS)
 Microsoft Dynamics AX 2009 Team Server
 Master repository folder
 Visual Studio Team Explorer
The SQL Server installation can be local or remote.
Note: If SQL Server 2008 is used, the Team Foundation Server SP1 Integrated Installation
process must be followed. For more information, see the Team Foundation Installation Guide for
Visual Studio Team System.

USING MICROSOFT DYNAMICS AX 2009 VCS INTEGRATION WITH TFS

System Settings
The global version control settings that are made by the Administrator are set on the System
settings form in Microsoft Dynamics AX. Use the System settings form to specify the Team Server
information and best practice settings. Before you configure the global version control settings, you
must enable version control on the Version control parameters form.
You can specify the following settings on the System settings form.

Setting Description
Status line The text entered for the status line will appear as a caption at the bottom
of the Microsoft Dynamics AX client.

Microsoft SQL Server or Oracle Specify the database type.

Team Server name Specify the name of the Team Server (ID server) you set up.

Team Server Database name Specify the name of the ID server database you set up.

Compiler warnings If set to Reject, the code to check in cannot contain compiler warnings.

Compiler errors If set to Reject, the code to check in cannot contain compiler errors.

Compiler to-dos If set to Reject, the code to check in cannot contain to-do comments.

Best practice errors If set to Reject, the code to check in cannot contain best practice errors.
This setting does not affect objects that have best practice warnings or
information. For more information, see Best Practices for Microsoft
Dynamics AX Development in the product documentation.

Run title case update If selected, the name of each object is checked for correct casing.
Application object names, such as methods or table fields, should begin
with a lowercase letter. Incorrect casing is fixed. For more information,
see Naming Conventions in the product documentation.

Object rules Object types or names can be prohibited in the Object rules tab. For
more information, see the product documentation.

Additional subfolders You can select where new objects are created by using the Additional
subfolders tab. More than one folder can be specified, and the
developer will be prompted to choose one of the locations when a new
object is created. A description should also be provided for each folder
value.

Test project Specify the test project to run when you check in code.

USING MICROSOFT DYNAMICS AX 2009 VCS INTEGRATION WITH TFS

Developer Machines
Each developer machine should have:
 Microsoft Dynamics AX 2009 Developer installation (with AOS)
 Microsoft SQL Server (local or remote)
 Local repository folder
 Visual Studio Team Explorer (optional)
The SQL Server installation can be local or remote.
Note: Consider the folder you choose for the local repository folder. If a Team Explorer instance
that runs against the source control server shares a local repository folder with a Microsoft
Dynamics AX 2009 client and a change is checked in by using Team Explorer, the Microsoft
Dynamics AX 2009 client will not reflect those changes when you synchronize the Microsoft
Dynamics AX 2009 client unless you select Force when you synchronize. Installing Team Explorer
on developer computers is optional.
Each developer machine must have a complete local installation of Microsoft Dynamics AX 2009, with
the exception of SQL Server, which can be shared. If SQL Server is shared, each developer should
have a separate Microsoft Dynamics AX database to avoid conflicts during development. Virtualization
of the development environment is typical.
Although it is not a functional requirement for TFS, developers should run a 3-tier thin client to
implement optimal client/server code.

Version Control Parameters

Local version control settings are set by the administrator on the version control administration server
and by developers on each developer machine.
You can specify the following settings on the Version control parameters form.

Setting Description
Source control status Set to Enable to work under version control.

Version control system Set to Team Foundation Server to use TFS for version control.

Repository folder Specify the repository folder you created.

Color checked-out objects in the AOT If selected, objects will be blue in the AOT of the developer who checks
out the object.

Warn when reverting objects If selected, the developer will be warned before objects are reverted.

Team Foundation Server URL Specify the TFS URL. The default port is 8080. For example,
http://fts:8080.

Team Foundation project name Specify the project you created in TFS.

USING MICROSOFT DYNAMICS AX 2009 VCS INTEGRATION WITH TFS

Security
There are two security aspects for version control integration with TFS:
 Access to Team Server (the ID server)
 Access to various TFS projects

Team Server Security

When Team Server (the ID server) is installed, you create a new group called Dynamics Team Server
Users. Any computer that uses Team Server must be a member of this group. To add developer
machines to this group, the administrator follows these steps:
1. Click Start > Administrative tools > Computer management.
2. Expand Local Users and groups.
3. Click Groups, and then double-click Dynamics Team Server Users.
4. Click Add to add a new member.
5. Click Object Types.
6. Select the Computers check box, and then click OK.
7. Click Locations to change the location (if needed).
8. Select a location/domain from the list, and then click OK.
9. Type the object/computer name for each developer computer, click Check Names, and then click
OK.

Team Foundation Server Security

TFS has security related to the specific development projects that are in the TFS environment. Each
user must be granted access to the appropriate projects in TFS through explicit permissions or
through membership in a group that has sufficient permissions. To add developers to this group, the
administrator follows these steps:
1. Open Microsoft Visual Studio.
2. From the View menu, click Team Explorer.
3. Right-click the appropriate project and then click Team Project Settings > Group Membership.
4. Select the appropriate group and then click Properties.
5. In the Add Member frame, select the Team Foundation Server Group or Windows User or
Group, and then click Add.
6. Add the users in the Select Users, Computers, or Groups window. Separate each user name
with a semicolon.
7. Click OK twice.

USING MICROSOFT DYNAMICS AX 2009 VCS INTEGRATION WITH TFS

Daily Work
The typical version control tasks that you perform are:
 Add objects to version control
 Check out objects
 Check in objects
 Rename objects
 Delete objects
 Work with labels
 Work with object versions
 Work offline

Object Life Cycle

The following diagram demonstrates the life cycle of AOT objects under version control.

There are two ways to create a new object.

1. Create a new object in the AOT in the usual way.
2. Overlayer an existing object. Because objects are stored per layer in TFS, overlayering an object
will effectively create a new object.

Add to Version Control

After an object has been created, it must be added to version control. The object can then be checked
out by other developers for development activities. To add an object to version control, right-click the
object and then click Add to Version Control. After you add an object to version control, you must
check it in.

USING MICROSOFT DYNAMICS AX 2009 VCS INTEGRATION WITH TFS

Check Out
When version control is enabled, you have read-only access to AOT objects. To edit an object, you
must check it out. Checking the object out will not lock the object, so other developers can also check
out the object and edit it.

Undo Check-out
You can choose not to check your changes in to version control. If you undo check-out, your changes
will be discarded and the object will revert to the version of the object that is in the repository.

Check In
To persist the changes you make to a checked-out object, you must check the object back in.
When you check an object in, the Check in form displays. All the objects you check in will be accepted
or rejected. By default, the Check in form will display all objects you have open. You can remove
objects from the list by pressing ALT+F9. When you check in objects, provide a detailed description of
the work you did in case you later decide to revert to a particular version of an object.

Quality Checks
The code you check in must comply with the quality checks that are set up by the administrator on the
System settings form. The available checks are:
 Compiler errors
 Compiler warnings
 Complier to-dos
 Best practice errors

Renaming Objects
After an object has been added to version control, it can still be renamed. When an object is renamed,
a copy of the object is created with the new name and the object with the old name is deleted. To
complete a deletion, the object must be checked in. To check in an object for deletion, use the
Pending objects form.
Even though a new object is created when you rename an object, the history of the deleted object is
maintained. When you rename an object, you must update all references to the object. To update
interdependencies between objects, do as follows:
1. In the AOT, right-click the object you have renamed and then click Add-Ins > Cross-reference
> Used by.
2. Check out all the objects that are listed.
3. Update the references and then check in the objects.

Deleting Objects
You can delete objects that are under version control as you would ordinarily delete an object. The
deletion will take effect when the object is checked in. Use the Pending objects form to check in the
object. You can undo a deletion before you check the object in.

USING MICROSOFT DYNAMICS AX 2009 VCS INTEGRATION WITH TFS

Label Editor
Working with labels is similar to working with application objects. To change a label, you must check
out the label file. To check out the label file, do as follows:
1. Click Microsoft Dynamics AX > Tools > Development tools > Label > Label editor.
2. Click Version control and then click Check out.
When you have finished adding or editing labels, check the file back in.
Label files allow multiple check-outs. When you create a new label, Team Server (the ID server)
allocates a new ID number while you have the label file checked out. This prevents a possible conflict
in the label IDs if two people add labels at the same time. If the value of the label changes since you
last checked out the label file and you attempt to edit the same label, your change will be rejected.
The rejected changes are displayed in the Infolog. You can then check out the label file again to
resolve the conflicts. To minimize the risk of conflicts, the label file should be checked out only for
short periods of time.

Get Latest
To synchronize a single application object to get the changes that other developers have made to an
object, use the Get latest command. You cannot use this command when you have the object
checked out.

Synchronization
After you create a local repository folder on your developer machine, you must synchronize your local
repository folder with the objects in the version control system to populate your local repository.
Later, you can synchronize your local repository with the version control system to reflect changes
made by other developers.
To synchronize all objects, click Microsoft Dynamics AX > Tools > Development tools > Version
control > Synchronize. Synchronization does not affect new objects that you created or objects that
you have checked out.
Consider the folder you choose for the local repository folder. If a Team Explorer instance that runs
against the source control server shares a local repository folder with a Microsoft Dynamics AX 2009
client and a change is checked in by using Team Explorer, the Microsoft Dynamics AX 2009 client will
not reflect those changes when you synchronize the Microsoft Dynamics AX client unless you select
Force when you synchronize. Installing Team Explorer on developer computers is optional.
If you select Force, all application objects will be synchronized, even if they have not changed. A
forced synchronization can take a long time. Consider installing a new build as an alternative.
If your version control system is set up to include folders in addition to those used for the AOT and the
label files, you can choose which of these folders to synchronize. This is done on the Pick folders
form that opens after you click OK on the Synchronization form.

Synchronization Log
TFS tracks object versions on the client. When you synchronize, the latest version is copied from TFS
to your local repository. Each file must be imported into Microsoft Dynamics AX to be reflected in the
AOT. A log entry is created for each file to validate that each file is imported. If the synchronization
fails, use the Synchronization Log form to select the paths of failed elements and then click
Process.

10

USING MICROSOFT DYNAMICS AX 2009 VCS INTEGRATION WITH TFS

Show History
You can view the history of an object. You can view the version number, the action performed on the
object, the date and time of the action, the user who performed the action, the change number of the
action, and the check-in comment.
You can get more historical information by using the following commands on the History form.

Command Description
Change list Displays a list of other objects that were included in the check-in with the
object.

Compare Displays the Comparison form that allows you to perform a line-by-line
comparison of two versions of an object. The Comparison form lists all
checked-in versions of an object and all normal layer object versions.

Open new window Opens the AOT with the selected version of the object to investigate
object properties.

View file Opens an .xpo file of the specified object version in Notepad.

Pending Objects
You can view a list of objects that are checked out by using the Pending objects form. You can select
objects to check in or you can discard the check-out. Depending on the version control settings, other
developers may be able to work concurrently on the same objects you have pending. From the
Pending objects form you can also create a project or import objects.

Change List
You can track all check-ins performed in TFS by using the Changes form. You can view the change
number, the date and time of the change, the user who submitted the change, and check-in
comments. You can see the objects that are included in a change by clicking the Contents button.
The initial change includes all AOT objects. If you click the Contents button for the first change, it will
take a long time to open the Contents form.

Working Offline
You can still develop in Microsoft Dynamics AX when you are not connected to the version control
server. Check out the objects you want to modify before you go offline, and then check them in again
when you are reconnected.
You cannot create object IDs when you are offline. You must be connected to Team Server (the ID
server) because it controls the allocation of object IDs. If you need to create an object that requires
an object ID, follow these steps:
1. Create the new object offline.
2. Export the object.
3. Connect to version control.
4. Delete the new object.
5. Import the new object (this will assign an object ID).
6. Add the object to version control and check it in.

11

USING MICROSOFT DYNAMICS AX 2009 VCS INTEGRATION WITH TFS

Code Promotion
Code promotion consists of deploying new or modified objects from the development environment to
the testing environment, and then to the production environment. This process varies based on the
architecture of the version control environment and the version control system settings. For example,
you can utilize a single TFS project environment or a multiple TFS project environment. In a single
TFS project environment, a single TFS project contains all the code to be deployed to the testing and
production environments. In a multiple TFS project environment, multiple TFS projects contain all of
the code to be deployed to the testing and production environments. Both processes vary based on
whether the system settings allow the check-in of objects that contain errors or warnings. We
recommend that you temporarily change these settings to be more permissive prior to the build. You
can then enable the settings again and check items out and check them in to enforce the best practice
checks.

Layer Promotion
Layer promotion (or migration) is a method of deploying changes to another environment. In layer
promotion, the entire layer Application Object Data (AOD) file in the destination environment is
replaced using the source environment. You can only use this method if all modificat ions in the
destination environment are included in the source environment, and there is no in-progress
development activity in the source environment.
The following steps demonstrate how you can deploy changes to another environment using layer
promotion.
1. Check users.
Make sure that no users are using the destination environment.
2. Stop AOS.
Stop the Application Object Server (AOS) service on the source and destination environments.
3. Rename the AOD or label file.
Rename the appropriate AOD or label file in the destination environment. For example, change the
axcus.aod file to axcus.aod.old.
4. Copy AOD or label file.
Copy the appropriate AOD or label file from the source environment to the destination
environment.
5. Delete AOI file.
Delete the Application Object Index (AOI) file from the destination environment.
6. Restart AOS.
Restart the Dynamics AX Object Server service on both environments. Restarting the service on
the destination environment may take several minutes because the AOI file must be rebuilt.
7. Synchronize the database.
Synchronize the SQL objects by using the Synchronize Database process (Administration >
Periodic > SQL Administration > Table Actions > Synchronize Database).
8. Validate.
Check the updated environment to make sure all objects function correctly.
9. Recompile.
Optionally recompile the application if you discovered issues when you validated (Administration
> Periodic > Compile application).

12

USING MICROSOFT DYNAMICS AX 2009 VCS INTEGRATION WITH TFS

Build Process
The build process varies with each deployment based on the architecture of the version control
environment, the version control system settings, and the involved projects. The following serves as
an example for how a build process can be implemented. For a typical build process, do as follows:
1. Consolidate code.
If a single Microsoft Dynamics AX project is to be deployed, skip this step.
If the code is contained in a single TFS project environment, the code can be consolidated to a
single repository by synchronizing the master build with the version control administration server.
If the code is contained in multiple TFS projects, you must create a master build of each TFS
project. Then create a master repository by copying all the master builds into a single repository.
Note: Make sure that objects that are in multiple repositories are not overwritten. Any
duplicate object issues must be resolved before you continue.
2. Create a single master .xpo file.
Create a single master .xpo file from the repositories created in the previous step.
If a single Microsoft Dynamics AX project is to be deployed, right-click the project in the Projects
form and click Export. The entire project will be consolidated into one .xpo file.
If the code is contained in a single TFS project environment, create a master .xpo file. Right-click
the root node of the AOT and then click Export. Specify the appropriate layer in the Application
Object Layer field.
If the code is contained in multiple TFS projects, create a consolidated master build. To create a
consolidated master build by using the CombineXPO tool, do as follows:
1. Create a directory called CombineXPO.
2. Copy the CombineXPOs.exe tool to the CombineXPO directory.
Note: The CombineXPO tool can be found at
http://go.microsoft.com/fwlink/?LinkId=156593.
3. Copy the repository layer folder (for example, usr, cus, var) to the CombineXPO directory.
4. Remove .xpo files that are not incuded in the build (optional).
5. Create a batch file named runme.bat. This will create a single .xpo file based on the VCS
layer file.
6. Add instructions to the batch file. For example,
CombineXPOs.exe cus MasterBuild.xpo
7. Run the batch file.
8. Check users.
Make sure that no users are using the destination environment. Optionally restart the AOS.
9. Deploy the .xpo file.
Deploy the .xpo file to the destination environment by clicking the Import button.
10. Synchronize the database.
Synchronize the SQL objects by using the Synchronize Database process (Administration >
Periodic > SQL Administration > Table Actions > Synchronize Database).
11. Validate.
Check the updated environment to make sure all objects were imported and compiled.

13

USING MICROSOFT DYNAMICS AX 2009 VCS INTEGRATION WITH TFS

12. Recompile.
Recompile the application if you discovered issues when you validated (Administration >
Periodic > Compile application).

Branching
Branching enables concurrent development within the Microsoft Dynamics AX 2009 environment and
provides a means of remediation and bug fixes in previously released versions without interrupting
ongoing development activities. This concurrent development is accomplished by providing each
endeavor by a developer with a separate source code repository that contains the specific items and
version that is needed to complete the effort. For an example of how you can incorporate branching,
see the Microsoft Dynamics AX 2009 Branch Support Plan using Team Foundation Server that is
included at the end of this white paper.
Branching occurs when a snapshot of code is taken at a specific point of the main, or baseline, project.
This baseline is usually represented by a label. The snapshot is known as the child branch, and the
source of the snapshot is called the parent branch. Merging is the process of copying the source code
to a separate TFS project, or synchronizing changes between two separate projects or branches.
Merging takes place only within TFS.
Basic development practices can be applied in this environment. No development activities occur
directly on the main (baseline) branch. Changes that are made in development branches are merged
into the main branch. There is no direct interaction between any other branches.
The main TFS project is branched to create the development project. Changes made in the
development project are merged into the main branch for testing. The merge from the development
branch to the main branch can be automated by using a script. If the merge is automated, consider
your development practices and best practice settings. If the best practice settings are set too low,
you may not want to automate merging because it is important to keep the main branch functional.

The release branch is a contingency branch that is used for hot fix development for released versions.
This branch is created for either remediation or to address issues that arise in released versions. After
the development activities are completed on this branch, the changes are merged into the main
branch, and then to the development branch. The labeling of releases is a prerequisite for branching
at a point in time.
Each branch must be deployed to a stand-alone TFS project to continue development activities within
that branch. Changes to the child branch are synchronized using a TFS process called merging.

14

USING MICROSOFT DYNAMICS AX 2009 VCS INTEGRATION WITH TFS

Primary TFS Project
In some cases, a primary project is created to group all development activities into a single TFS
project. This is optional and has no direct interaction with Microsoft Dynamics ® AX. The following
example shows a primary TFS project for development. In this case, all activity that is not related to
Microsoft Dynamics AX is stored in the primary TFS project with child projects for each of the branches
used for Microsoft Dynamics AX development. The child projects are required because the version
control integration does not recognize the layers that are used in the primary project. The version
control integration requires definition and layer folders immediately below the project level.

This example illustrates the practice of creating separate project branches. In this case, devTeam1
represents developers working in geographically or functionally separate areas. Each separate
development branch requires a separate intermediate TFS project and a separate development
environment for development activities. This concept can also be used for the release project to allow
for remediation and issue management in multiple versions of released code.

15

USING MICROSOFT DYNAMICS AX 2009 VCS INTEGRATION WITH TFS

If you use a primary TFS project, institute a best practice that requires all updates to be merged from
the intermediate TFS projects to the primary TFS project. Do not merge intermediate projects with
each other. The following diagram demonstrates the interaction between the primary and intermediate
projects in TFS.

16

USING MICROSOFT DYNAMICS AX 2009 VCS INTEGRATION WITH TFS

Project Interaction
The configuration of the interactions is as follows:
 Automated script (moving code between intermediate and primary TFS projects)
o DAX DEV (DMODAX09)  TFS DMO DEV Primary Project
 Manual script (moving code between intermediate and primary TFS projects)
o TFS DEV  DAX DEV
o DAX MAIN (Dynamics MAIN)  TFS MAIN
o TFS MAIN  DAX MAIN (Dynamics MAIN)
 Manual human intervention (moving code between branches in the primary TFS project)
o TFS DEV  TFS MAIN
o TFS MAIN  TFS DEV
o DAX REL  TFS REL
o TFS REL  DAX REL
o TFS MAIN  TFS REL
o TFS REL  TFS MAIN

Labeling
In TFS, labels are used to mark milestones in the development lifecycle, particularly product releases.
Labels are important to release branching, where the main project is branched at a point in time for
remediation or issue management. Labels can be applied to source code through one of the following
methods:
 Using the command line utility
 From the TFS context menu
 Automatically during the build process in TFS
The TFS build process requires the installation of the Team Foundation build utility, which is typically
installed on a separate machine. You can use the build utility to create a proxy build that will label all
the source code in the project based on parameters that are entered during the build process. These
labels are stored in TFS and can be used for subsequent branching. For more information on labeling,
see the Team Foundation Server Administration Guide.

Labeling as Part of a Proxy Build

You can use automated labeling, bug tracking, and project management functionality of TFS by
creating a build that is generated by TFS. This build corresponds to the build that is generated by the
MorphX IDE. The TFS proxy build generates a build number and a corresponding label for the sources
that match to the Microsoft Dynamics AX work. The label and build number can be used to manage
work items, associate bugs with builds, and merge code like any other project using TFS.
To create the proxy build, do as follows:
1. Open Microsoft Visual Studio.
2. Create a new project (File > New > Project).
3. In the New Project window, select the Empty Project template. Select the Create directory
for solution and Add to Source Control check boxes. Name the project and click OK.

17

USING MICROSOFT DYNAMICS AX 2009 VCS INTEGRATION WITH TFS

The TFS proxy build is a Visual Studio project with a single build target that does nothing. You can
insert a custom batch file into this task to perform activities. For example, an empty Microsoft Visual
Studio project may look like this:

<?xml version="1.0" encoding="utf-8"?>

<Project ToolsVersion="3.5" DefaultTargets="Build"
xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
</PropertyGroup><Target Name="build">
<Message Text="This is an empty build task"/>
<!--Insert any custom build scripts here
<Exec Command="myCustomBuild.cmd"></Exec>
-->
</Target>
</Project>

Create a new TFS build definition by using the steps outlined at

http://go.microsoft.com/fwlink/?LinkId=152448.
You can schedule the TFS build on an appropriate interval. Associate it with builds that are generated
from the MorphX IDE so that the label that is generated from TFS matches the build you are testing.
You can also create labels using the Team Explorer user interface. For more information, see the Team
Foundation documentation.

Source Code Reset

As a last resort, you can reset your code. Resetting your code involves rebuilding a release
environment based on the current production environment, deleting downstream TFS data by using
the TFS merge function, and then refreshing the downstream data based on the rebuilt release
environment. This is a lengthy process. The phases that follow explain how to do this and should be
followed sequentially as given.
Phase one
In Microsoft Dynamics AX, you must first export development activity that is not included in the
production environment in preparation for the source code reset. Do as follows:
1. Make sure all code is checked in. Make sure any code that is not under version control is exported
to .xpo files. You can import that code after the reset is complete.
2. Synchronize the master development installation.
3. Export the version control modifications that are not in the current production environment to .xpo
files.
4. Perform the above steps for all other projects that are affected by the source code reset.

18

USING MICROSOFT DYNAMICS AX 2009 VCS INTEGRATION WITH TFS

Phase two
Delete all data in the release or hot fix project. This serves as a starting point. Cascade and delete
activities to the other affected projects and branches. Do as follows:
1. Stop automated update scripts that affect the projects and branches that are involved in the reset.
2. Select the project that will serve as the starting point for the reset and delete all TFS data below
the folders that are designated as merge folders. In a TFS project that is associated with Microsoft
Dynamics AX, the layer folders are usually the merge folders. Delete the contents of these folders.
For example, cus or usr.
3. Use the TFS merge functionality to merge the delete activity to all other projects and branches
that will be affected by the reset. The merge relationships between the projects or branches
should be set up prior to the reset.
4. Note: Merge the delete activity. Do not delete the data in each project. Deleting the data in
projects and branches will destroy the relations between the objects.
5. Repeat the activity merge for each project and branch that is affected by the reset.
Phase three
Reset the source project to the state of the current production environment and merge the repository
to all related projects and branches. Do as follows:
1. Stop the Dynamics AX Object Server service for the source project environment.
2. Copy the layer folder (for example, cus) from your local repository to the Temp directory. Delete
the layer folder in your local repository.
3. Delete the axapd.aoi index file from the development database folder. This folder is usually
located at Program Files\Microsoft Dynamics AX\50\Application\Appl. Rename the layer AOD files.
For example, axcus.aod and axusr.aod.
4. Make sure all users are logged out of the production environment.
5. Stop the Dynamics AX Object Server service on the production environment.
6. Copy the layer AOD files from the production environment to the source project environment.
7. Open Microsoft Dynamics AX in the source project environment in the layer that contains the
modifications.
8. Create a new VCS repository. Click Microsoft Dynamics AX > Tools > Development tools >
Version control > Setup > Create repository. The Create repository command adds all
objects in the current layer to the VCS and checks in the activity.
9. Use the TFS merge functionality to merge the delete activity to all other projects and branches
that will be affected by the reset. The merge relationships between the projects or branches
should be set up prior to the reset.
Note: Merge the delete activity. Do not delete the data in each project. Deleting the data in
projects and branches will destroy the relations between the objects.
10. Synchronize the master development installation and import all modifications that you exported in
phase one.
11. Repeat the activity merge for each project and branch that is affected by the reset.

19

USING MICROSOFT DYNAMICS AX 2009 VCS INTEGRATION WITH TFS

Phase four
Clear each developer installation and synchronize each developer installation to the respective master
development installation. Do as follows:
1. Stop the Dynamics AX Object Server service on each developer installation.
2. Copy the layer folders from your local repository to the Temp directory. Delete the layer folders in
your local repository.
3. Delete the axapd.aoi index file from the development database folder. This folder is usually
located at Program Files\Microsoft Dynamics AX\50\Application\Appl. Rename the axcus.aod file.
4. Restart the AOS in the development installation.
5. Open Microsoft Dynamics AX and check the AOT to ensure that there are no customizations in the
cus layer.
6. Click Microsoft Dynamics AX > Tools > Development tools > Version control >
Synchronize. Select the Force option.
7. Import .xpo files that are not under version control.
8. Verify that all objects were included, and repeat for each developer installation.

Best Practices
Some recommended best practices are as follows:
 TFS merge relationships and paths should be defined in advance. Always begin merge
activities at an endpoint in the path.
 If a primary project is used, merge activities should always begin in an intermediate project
and flow through the primary project to all remaining projects and branches.
 A viable MorphX project structure should be established for each implementation. This is
important to restore incomplete work if a TFS reset is required. Some options include:
o One project that contains all of the objects and modifications for a project or phase.
o One project for each planned modification. The project structure mimics the AOT
structure.
o One master project where each modification is a subproject. The subproject structure
mimics the AOT structure.
 Rules should be established for the check-in of in-process modification activities.
 The TFS SQL databases should be included in a SQL Server maintenance plan and in the
network backup plan.
o Include Report Server and WSS databases in the backup plan.
o Full and transaction log backups are required because many of the TFS databases use
a full recovery model.
 A data recovery process for TFS data should be established.
 The Microsoft Dynamics AX 2009 Team Server database should be included in a database
maintenance plan.
 Security should be proactively managed. If Team Explorer is installed on each developer
installation, developers should only have access to the TFS project they use. Only
administrators should have access to all TFS projects.

20

USING MICROSOFT DYNAMICS AX 2009 VCS INTEGRATION WITH TFS

 21

USING MICROSOFT DYNAMICS AX 2009 VCS INTEGRATION WITH TFS

Microsoft Dynamics is a line of integrated, adaptable business management solutions that enables you and your
people to make business decisions with greater confidence. Microsoft Dynamics works like and with familiar
Microsoft software, automating and streamlining financial, customer relationship and supply chain processes in a
way that helps you drive business success.

U.S. and Canada Toll Free 1-888-477-7989

Worldwide +1-701-281-6500
www.microsoft.com/dynamics

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the
date of publication. Because Microsoft must respond to changing market conditions, this document should not be interpreted to be a
commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of
publication.
This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED, OR STATUTORY, AS
TO THE INFORMATION IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of
this document may be reproduced, stored in or introduc ed into a retrieval system, or transmitted in any form or by any means
(electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission o f
Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject
matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this
document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

© 2009 Microsoft Corporation. All rights reserved.

Microsoft, the Microsoft Dynamics Logo, FRx, Microsoft Dynamics, SharePoint, SQL Server, Team Server, Visual Basic, Visual
Studio, Windows, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation, FRx Software
Corporation, or Microsoft Business Solutions ApS in the United States and/or other countries. Microsoft Business Solutions ApS and
FRx Software Corporation are subsidiaries of Microsoft Corporation.

22

USING MICROSOFT DYNAMICS AX 2009 VCS INTEGRATION WITH TFS