AX for Retail 2012 R2: Using the Extensions folder for POS Customizations
[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:
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:
