Nov 17, 2011
Filed under: #daxmusings #bizapps

During the beta program and even up to the last few months before the launch, I have talked a lot with Microsoft expressing the concerns and issues we were having with AX 2009 and TFS, and offering suggestions on what would ease some of the pains of the integration that existed. Unfortunately, not all of these issues have been resolved. Some are fundamental problems in the way things are architected, other issues are unique to AX compared to other IDEs that TFS integrates with. Luckily, there are nice improvements in AX 2012 as well. I will give you an overview here, and post detailed information in follow-up blog posts.

The Bad (I’m one of those people who wants to hear the bad news first)

The major issue that existed in AX 2009, unfortunately still exists today: the TFS integration in AX 2012 does NOT support multiple developers in the same environment. This is a fundamental issue that unfortunately cannot be solved easily. I’ve had numerous discussions about this with Microsoft, and there is no good solution yet. It’s part AX and part TFS that is the problem. Microsoft has come out with a whitepaper on the topic, suggesting to use public workspaces. Sad to say I had coined that idea to Microsoft back in January, but we had decided this solution would not work well. Somehow this ended up as an official whitepaper (some of the people I talked to at Microsoft were surprised about this as well). In any case, the public workspace does NOT work well. There are other workarounds (basically still the same ones I have blogged about for AX 2009) but they are not pretty. We’ve used them for quite some time now with AX 2009, and they have served us well without any problems. More on this later. The other frustrating topic is models. The beauty of models is they support the object sub-level granularity in the AOT, meaning that one method can be in one layer/model, another method on the same class can be in a different layer/model, etc. This is the basic premise for models to work: you can install a model that adds a method to a class, without needing the whole class in the model. That way you can install numerous models without having to merge the code. The TFS integration however, is file-based using XPOs. The current XPO format as it has existed in AX for a while, does NOT support this granular model. You CANNOT export just one method, you have to export the main class element with it (class properties including “extends” property etc). Yes, you can have an XPO of a class with just one method, but you’ll still have the class itself in the XPO. This effectively BREAKS the granular storage. Obviously this must have been a big consideration for Microsoft when creating the TFS integration. Since you include the class declaration itself in the XPO, how can you separate the different methods XPOs in different folders? Where will the class declaration reside? Everywhere? Nowhere? On top of that, you cannot take an export of just one method, the only “filter” available is to only export methods customized in your layer. No option to only export for a certain model (although I’m guessing Microsoft could easily add this). To “solve” the problem, AX will store the XPO in the folder of the model it was FIRST used in, and keep it there forever. So if you add a method to a never-before customized standard AX class and add it to model A, AX will place the XPO in the ModelA folder. If we now want to add another method to this class, in model B, AX considers the fact the XPO already exists, and ends up putting your model B customization in the XPO in the ModelA folder!! This effectively renders the model support in version control useless. Especially if you are wanting to automate builds, there is no more correlation between the model folders in TFS versus the actual models the code should belong to. I understand this as a fundamental problem that is not easily solved without changing the format and functionality of XPOs, so my only conclusion is that the model - TFS integration should not be used (or you put everything in one model). I gave this example with a class but it goes for any objects or changes, including forms, tables, event handlers, etc.

The Good

The TFS integration in AX 2012 now supports sub-folders. In previous releases, AX insisted on putting all the code starting at the root level in your source control tree. So if you want to do branching, this is a big issue. This was fairly easily remedied by changing every developer’s workspace settings in TFS to point to a sub-folder in the source control tree. At Streamline we have actually automated (customized) this process in AX on a developer’s first login, so it’s transparent and the developer doesn’t need to do anything. AX 2012 now supports entering a folder path in the TFS settings! The check-in dialog in AX 2012 has been extended to allow you to associate your check-in with a TFS work item. This is a great feature (one which I understand came from a Microsoft developer coding this in his spare time), although I would have liked to see support for TFS queries. Currently the query for the work items is hardcoded in a Macro in the AOT. At Streamline Systems we are extending this to have a dropdown available with your TFS queries. More on this later. The creation of the developer workspace and some other lower level TFS stuff has always been handled in assemblies. There was no way to look into or customize the behavior of how AX creates the workspaces or talks to TFS. After some discussions, Microsoft ended up putting that .NET code in the AOT as a Visual Studio project. This means if there is a need to debug or to customize the TFS proxy used by AX, you can do so in the SysVersionControlTfsFacade Visual Studio/C sharp project in the AOT.

Seems like I spent more time on the bad than the good. The main reason is I feel developers should understand the limitations of the TFS integration, and understand WHY these are big topics, and why some of those are not an easy task for Microsoft to solve. I expect we will be living with some of these issues for a while. That does not mean you cannot use the TFS integration. In fact, we use it heavily here. In the coming blog posts, I will dive into specifics of how and why these issues exist, and offer some solutions.

In other news, we are also working on new build scripts to put on CodePlex, which will be compatible with AX 2012 and its models. Keep an eye out. For general TFS and ALM information and our solutions for AX 2009, check out the TFS page.

 

There is no comment section here, but I would love to hear your thoughts! Get in touch!