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".