Axapta programming blog: practical HOWTOs

Wednesday, November 22, 2006

How to build Axapta application from XPO files stored in Visual Source Safe.

I have noticed that topic about version control in Axapta has become very popular, especially after DAX 4.0 has been released, so I decided to write a couple of more blog posts about it. In this post I am going to discuss how to build up Axapta application from those hundreds of XPO files you have in your Visual Source Safe database and moreover do it automatically without any human interaction, so you can put it on the schedule and execute every night or so.

Basically, the main idea of building Axapta application from XPOs is just to import them into your working layer over the core Axapta application (system layers which stands below your code) in order to create an AOD file, which after that can be put on the test environment or delivered to the customers, partners and so on. And so the first question that will come up is how should we do this – should we just import them one by one or is there any way to combine them all together or may be we can do a bulk import? Michael Fruergaard Pontoppidan, on his blog (mfp's two cents), has recently published this great tool called “CombineXPOs” which is IMHO a brilliant way of solving this problem. Click here to download. This tool will automatically traverse all your folders and subfolders hierarchy and compile together all XPO files it can find in there. So using this tool I have created a couple of scripts which can automate the whole process and probably put your development life cycle on a bit higher excellence level.

The first thing that we need to do is to synchronize all XPOs from VSS and compile them all into one big XPO file. To do so, I have created a small script “sync.cmd” which will: switch to my VSS working folder and use simple VSS “get” commend like this:


ss Get $/%project_name% -GTM –R


where the %project_name% is the name of the project as it appears in VSS. After it’s done, I call “CombineXPOs” tool like this:


CombineXPOs.exe %layer% %layer%.xpo


Where the %layer% is the name of the layer you are trying to assemble. I also assume that folder which containing XPO files is also called the same as layer and it stands under the project name in your VSS working folder.

When the first script is executed I am calling another script “updatenv.cmd”, which is doing the actual import into my Axapta “build” environment. I call it “build” environment because I use a little temporary application patch during this process in order to automate it, but I will get back to it later. So, the second script takes combined XPO file moves it to the root folder like “C” drive and then pass it to Axapta like this:


ax32.exe "%conf_dir%\%conf_file%" -internal=noModalBoxes
-startupcmd=AOTImport_%combined_xpo%


where %combined_xpo% is the path to the xpo file (something like this “C:\usr.xpo”) and %conf_dir% and %conf_file% are configuration file path and file name appropriately. -internal=noModalBoxes switch prevents Axapta from different pop-ups during the process.

After import is completed we only need to compile and synchronize our new application. In order to compile I call the similar command line:


ax32.exe "%conf_dir%\%conf_file%" -internal=noModalBoxes -startupcmd=compileall


and to synchronize our application with database, I used string like this:


ax32.exe "%conf_dir%\%conf_file%" -internal=noModalBoxes -startupcmd=synchronize


After these two processes completed we can grab our new AOD file from the application folder and put it into the drop share with date or build number stamp on it.

The only thing left to discuss is that little application patch that I promised to get back to. The thing is, that in Axapta 3.0 there are a couple of obstacles preventing importing process to be 100% automatic. First thing is that during import process Axapta kernel asks user if it’s ok to overwrite existing (on the lower layers) objects. And the second problem is that Axapta never shut down itself after import completed but we actually need it to close, because of other procedures – like, for example, compilation and synchronization of the application which should follow after it. So, how I solved that, is simply by creating some X++ code in USP layer and putting it in my “build” environment before importing XPO and removing it after build process completed. What exactly I have created in X++ is two things. First, in the class “SysStartupCmdAOTImport” added this line of code at the end of the method “infoRun”:


infolog.shutDown(true); //Jobs done


and also, in the class “Box”, commented out content of method “yesAllNoAllCancel” and have put


return DialogButton::YesToAll;


at the end of the method. This string will make sure we have always YesToAll button pressed during the import process.

And the last thing to remember is that you need to set your Windows network account as a "network account name" for your Axapta admin user to be able to logon automatically in Axapta. This should be done here: "Main menu/ Administration/Users/General/Network account name".

9 Comments:

  • I have developed also an XpoUtils suit for Ax 3.0, but there are some problems when import large XPOs

    By Blogger Max Belugin, at 10:28 PM  

  • I recommend to use KR2, there are some fixes with regards to export import functionality:

    1732
    A critical error requiring restart occurred on an attempt to export a project using the treeNodeExport method of the ProjectNode class,

    3755
    A critical error requiring restart occurred on an attempt to export a project by layer with objects that have been deleted before.

    15315
    If Axapta was started with a key option to import an XPO, which contained a form and one of the form's controls was renamed, then Axapta critically stopped during the import.

    15515
    Extended Data Type and EnumType not importing

    14767
    If elements from AOT were exported with labels from a system with KR1 and then the XPO file was then imported in an environment without KR1, an error message was displayed.

    15222
    Import replaces display method in field group

    2:08 AM

    By Blogger AxaptaBuilder, at 6:20 AM  

  • Yurii Great post! I love the work you have posted about, for VSS and DAX.

    It time everyone start really making use of this on their projects. I am even trying to get our sales team to sale it as well, as part of the overall project.

    Anyway just wanted to give you some encouragement. I did a post back link to this article on http://dynamics-ax.blogpsot.com

    Keep up the good work, and now I can't wait to see some articles, possibly on integrating with Team System! ;-)

    By Blogger brandon, at 7:01 AM  

  • The combinexpos.exe tool is a brilliant concept!!! But, i'm not getting it to work with version 4.0 SP1 (kernel version 4.0.2163.0)

    Any ideas?

    By Anonymous satish, at 8:19 AM  

  • I would love to know more about it.
    Thanks

    Sullivan

    By Anonymous Anonymous, at 4:58 AM  

  • combinexpos.exe is crashing when you have "***Element: End" in a method.

    You need to split the string :
    "*"+"*"+"*"+"Element:"+" End" to fix the bug.

    By Anonymous vincentn, at 9:22 AM  

  • Great job..

    By Anonymous Anonymous, at 1:34 AM  

  • Can you explain this step a bit -> Main menu/ Administration/Users/General/Network account name

    I don't see which field you mean. I see a user name field, but not a Network Account Name

    By Anonymous Blitz, at 7:51 PM  

  • In response to Blitz, the field I refer to is called now "Alias" on the User form and "Network Account Name" on the User Relation form. Hope it helps.

    By Blogger AxaptaBuilder, at 4:51 AM  

Post a Comment

Links to this post:

Create a Link

<< Home