Microsoft Dynamics AX Support

This blog contains posts by the Microsoft Dynamics AX Support teams Worldwide

AX for Retail 2012 R2: Using the Extensions folder for POS Customizations

AX for Retail 2012 R2: Using the Extensions folder for POS Customizations

  • Comments 7

[Update:  2013-09-28]  For the Extensions folder to function properly the POS must be build 6.2.1000.1629 or higher.  Install KB 2857746 or Cumulative Update 6 to get this fix.

One great feature we added in AX for Retail 2012 R2 was a nice place for developers to drop in customizations without overwriting existing services and triggers.  If you have read my earlier AX for Retail: Managing and Maintaining POS Customizations article you know that a shortcoming of previous versions of the POS required you to replace a service or trigger that Microsoft shipped with one of your own.  For example, if you needed a customized Price Service you needed to create your own Price.dll and copy it over the version of the DLL that ships with the product.

This really becomes a problem as you deploy hotfixes.  If Microsoft creates a hotfix that updates our version of the Price.dll, the installer may delete your version of the file and you would have to copy yours over again.  Furthermore, rolling back a customization for testing purposes is difficult:  you need to keep a copy of the non-custom version of the DLL and copy it over your version of the DLL.  It can get pretty messy pretty quickly.

Introducing the Extensions Folder

When you install AX for Retail 2012 R2 POS you will notice that there is now an Extensions folder with a single ReadMe.txt file:

image

Here are the contents of that file:

Place all Retail POS customizations to services and triggers, as well as any added code in this folder. If you use this folder you don’t need to replace or remove existing services or triggers from their respective folders. Single instance interfaces (such as ICustomer) use this folder first for loading interface implementations.

Multi-instance interfaces (such as IBlankOperation or any of the trigger interfaces) load both the interfaces in this folder and the interfaces in the core implementation.

There are a couple of interesting things to note here.

First of all, you no longer have to worry about the files in the \Services or \Triggers folders.  You can let the Dynamics AX installer do what it needs to for any of those folders.  Just drop in your custom DLLs, restart the POS, and voila, your customization is enabled.  Want to test to see if your customization is causing a problem?  Just delete it from this directory and restart the POS.  You’re back to the standard version of the application.

Secondly, note that there is no mention of file names.  The POS now loads services and triggers based on whether they properly implement the interface, not based on file name.  This means you can rename your assembly to call out your company name or purpose of the customization to keep track of them more easily.

This is a great new feature for developers and system administrators.  You will still need to make sure that hotfixes don’t affect customizations (see the three-way code merge from the article above) but this will save some time.

Here are a few screenshots of the Extensions folder in action:

 

 

image

image

image

 

image

Leave a Comment
  • Please add 1 and 3 and type the answer here:
  • Post
  • Thanks for this information.

  • Hi Shane,

    Thanks for the information. We are trying to implement this feature but we did not get success. We are facing some issues with it.

    We have install AX 2012 r2 in test but we do not see the extension folder in “Retail POS\Extensions” and Extension folder is exists in Servers and Triggers folders. When we place out custom DLL’s in “Services\Extensions” folder and restart POS then we received error “Error Number: 13000 could not load all external service modules.”.  

    Do we need to apply any hotfixes to get this work? Why we do not see extension folder in Retail POS folder?

  • Hi Viplav,

    I snuck in an update at the top of the article you may not have seen.  You'll need POS version 6.2.1000.1629 or higher for this to work properly (hotfix was not in CU1 but made it into CU6).

  • Hi Shane,

    Thanks for the information. we will try with hotfix.

  • Hey Shane,

    So as of CU6, we don't put anything in "Retail POS\Services\Extensions" ... ?

    It all goes to "Retail POS\Extensions" ... ?

    How about InteractionDefaults?

    Currently we've got a custom InteractionDefault going to "Retail POS\Services\InteractionDefaults\Extension"

    Is this still correct? Or do they now also go to this new location?

    It's so hard to find any information out there, so we really appreciate your help, thanks in advance!

  • I have no idea how I did it, but I have used this methods for months. Then I wanted to restructure my solutions so it was clean, and now my POS won't use my extensions and my debugger id not activating anymore. Anybody know a reason for this?

  • Hi Shane,

    I have the same error 13000, but I am doing customization with BlankOpertations for Ax for Retail 2009. When I  restart POS I received this error; any Idea?, Rgds.

Page 1 of 1 (7 items)