Additional code upgrade information

This section provides additional information about helping make the code upgrade process successful. Read through each section below before you begin any of the procedures.

It might be beneficial to complete the code upgrade process on a blank database so that you don't have to worry about any data during the code upgrade.

  1. Install Microsoft Dynamics AX 2009 and create a new Microsoft SQL Server database using the Setup wizard. For more information, refer to the "Create a Microsoft SQL Server database using the Setup wizard" topic in the Installation Guide.

  2. After installation is complete, open Windows Explorer and browse to your application files installation folder. The default location is C:\Program Files\Microsoft Dynamics AX\50\Application\Appl\DynamicsAx1.

  3. Inside the application files installation folder, create a folder called Old.

  4. Copy your prior version AOD files (*.AOD) and the label files (*.ALD, *.ALI), if needed, into the Old folder.

  5. Copy your prior version AOD files that are outside of the DIS layer (axbux.aod, axvar.aod, axcus.aod, axusr.aod, and the patch layers if they exist: axbup.aod, axvap.aod, axcup.aod, axusp.aod) and any relevant label files (*.ald, *.ali) into the application files installation folder.

    NoteNote

    Since the BUS/BUP layer is generally reserved for 3rd party additional products, you may not want to copy the axbus.aod and axbup.aod files. You may want to install new versions of the same applications that are certified for Microsoft Dynamics AX 2009.


  6. Start the AOS service. This may take a few moments. The AOS service will create the axapd.aoi file for the current application files installation folder, and in the Old folder that you created in step 3.

It is a good idea to compare only one code layer at a time. For example, if you have three additional layers, you should work from the innermost layer to the outermost layer and create upgrade projects for each layer.

NoteNote

The SYS layer is considered the innermost layer. The layer structure [inner to outermost] is SYS, GLS, LOS, DIS, BUS, VAR, CUS, USR, and then the associated patch layers for each layer.


As you work through each layer, you will need to either promote new code from the inner layers to the outer layer, or remove it if it is no longer valid.

Complete the following procedure for each layer. Once you have processed all of the upgrade projects, you should be ready to upgrade your data.

  1. Complete steps 1-5 from the previous procedure.

  2. Start the AOS service. This may take a few moments. The AOS service will create the AXAPD.AOI file for the current application folder, and in the Old folder that you created.

  3. Open the Client Configuration Tool and be sure to log into the layer that corresponds to the layer file that you just copied into the application folder in step 5.

  4. Start the Installation checklist. (First time only)

  5. Start the Detect code upgrade conflicts tool (MSDAX menu > Tools > Development tools > Code upgrade > Detect code upgrade conflicts).

  6. Run the upgrade projects for this layer.

  7. Stop the AOS and back up the current layer file (ax*.aod).

  8. Repeat steps 5-12 with the next innermost layer that exists.

If your previous version of Microsoft Dynamics AX has multiple layer files contained within the application, you may want to consolidate the functionality from the multiple layers into a single layer. Consolidating your previous version's layers will help make upgrading to Microsoft Dynamics AX 2009 easier.

Also, by consolidating the layers before upgrade, you can test the functionality of the merged layer against known data and processes in your modified, pre-upgrade installation of Microsoft Dynamics AX, and validate that the code is functioning as expected. It will also help make maintenance easier in the future when service packs are released, as there will be fewer layers to compare against to propagate the service pack modifications to the outer layers.

NoteNote

Moving objects between layers may cause object ID issues. Upgrade scripts or jobs may need to be created to adjust the Microsoft Dynamics AX 2009 data model. For more information, refer to the white paper "How to Write Data Upgrade Scripts" (http://go.microsoft.com/fwlink/?LinkId=115169&clcid=0x409).


Evaluate your code modifications. If Microsoft Dynamics AX 2009 does not have the functionality that existed based on your changes, then you should probably re-implement your changes in Microsoft Dynamics AX 2009.

If Microsoft Dynamics AX 2009 now contains functionality that is similar to your customizations, it would be to your advantage to remove your customization and modify the existing functionality to meet your specifications.

Also, this may be a good time to remove functionality that is not used anymore.

Use the Show all layers setting (Microsoft Dynamics AX menu > Tools > Options > Development tab > Application object layer) to allow developers to see all of the layers an object exists in.

If you plan on using Product Builder, consider devoting a layer to just the classes that Product Builder will create in the AOT. In Microsoft Dynamics AX 3.0, Product Builder could optionally write code into the AOT to help increase performance. In Microsoft Dynamics AX 4.0 or later, this is now a requirement.

If an issue arises in which Product Builder corrupts a layer file, it would be advantageous to have a layer devoted exclusively to Product Builder code. Any customizations to the system should NOT reside in the layer that Product Builder is using, so that if the layer does become corrupted, the fix can then be as simple as restoring a backup for that specific layer, recreating the AXAPD.AOI file, and restarting the AOS. Also, if there is not a backup of the Product Builder specific layer, the AOS can be stopped, the layer file removed, the AXAPD.AOI file removed, the AOS restarted, and Microsoft Dynamics AX can be functioning again.

When creating a modification, try to avoid modifying the base classes. Instead, extend them either by creating new methods, or by creating new classes which inherit a base class. This way, when service pack or major version upgrades are done, the stand-alone code should not be adversely affected by the changes. This way, the only needed modification to the base class might be a simple call to the new functionality that has been created. This is much easier to implement and upgrade than propagating lines of code from inside many different methods to re-implement the desired functionality.

Community Additions

ADD
Show: