Friday, March 16, 2012

Migrating from MorphX version control to TFS version control - Part 2

In Part 1 of this article I described a method to migrate MorphX version control data into TFS version control using the TF.exe command line utility and an x++ job. In Part 2 I will touch on some of the difficulties I faced and give a little more detail on how I overcame them.

First, in order to use TFS 2010 source control with Microsoft Dynamics AX 2009 you first have to install Team Explorer 2008 and the forward compatibility patch. This requirement is detailed elsewhere, so it was not a surprise to me. However, when I tried to install the forward compatibility patch I kept getting an error message saying that the patch wasn't applicable to any of my installed applications. In order to successfully install the patch, I had to re-install SP1 for Visual Studio 2008 after installing Team Explorer 2008 even though I had installed it earlier. Once I did this I was able to install the forward compatibility patch. Of course, this is not necessary to complete the steps in Part 1 of this article, but it is something you will want to do eventually.

In order to use the /author: parameter of tf.exe to submit your check in as another user, that user must first be granted the "Act as another user" in TFS admin console.

The code in Part 1 of this article uses a tf.cmd batch file instead of calling the tf.exe file directly. A major benefit of this is for debugging purposes. The batch file can contain a call to the tf.exe and then the second line of the file can contain a "pause" so that you can see the output from .exe. Otherwise the window for the executable closes too quickly and you cannot see any error or success messages. This is vital when first setting up and making sure this is working. Here are the contents of the tf.cmd file I used:

"C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\tf.exe" %1 %2 %3

Of course, I recommend setting up a test Team Project in TFS to verify this code is working correctly for you, and then using the TFS Admin Console to delete the Team Project and create a new one once you have verified everything is working correctly. During testing you will likely need to submit some files, delete them from source control and resubmit them. By creating a new Team Project you can maintain clean history.

Finally, after running this job to recreate all of your check ins in TFS you want to be able to verify that everything created successfully and no objects were left out in error. One way to do this is to simply create a project from layer, enable source control, check out all objects from within Team Explorer (or Visual Studio 2010), and relaunch the client to confirm all of the objects in your layer project are "colored" blue denoting they have been checked out. If you see any objects that are not checked out you can modify the job to debug further what the issue is, or depending on the severity and importance of maintaining exact history you may just want to add to version control and move forward. To create a project from a layer go to Menu > Tools > Development tools > Code upgrade > Compare layers. Name the project something like DEV_CUS, select CUS (or whatever layer you are coding in) in the source layer, and leave the reference layer set to SYS. Do not check the "only include element present in both layers" check box. Running this will create a Private project from all objects in the source layer.

[Note: In a future post I will share a tool I wrote that can be used to parse the exported project into individual xpo files. This is useful to compare code installed in separate environments such as a Test and Production enviroment for differences.]
[Update: See my post here for parsing xpo files]

I hope this article helps supplement my previous article on migrating source code from MorphX to TFS.

No comments:

Post a Comment