[Edit, October 31, 2014] 2012 R2 and 2012 R3 use the same DevExpress components:
- AX for Retail 2012 R3 Post CU9: 220.127.116.11 (DevExpressSignedNoAPTCA-14.2.107.exe)
- AX for Retail 2012 R3: 18.104.22.168
- AX for Retail 2012 R2: 22.214.171.124 (DXperienceSignedNoAPTCA-11.2.111.exe)
- AX for Retail 2012 (Feature Pack): 126.96.36.199
- AX for Retail 2009: 188.8.131.52
[Edit, July 2, 2015] – A hotfix was released shortly after R3 CU9 which updated to a newer version of the DevExpress components. This hotfix was released under KB 3059368.
[Edit, January 14, 2012] This article was originally written for AX for Retail 2009. I’ve since done a little research on this subject with respect to the upcoming AX for Retail 2012 version. Our development team has recieved a newer build of the tools for our new version of the POS: WinForms v2009.2.110. Both of these versions are available by contacting DevExpress. Note that this new version incorporates a new installer and I’m happy to report that it no longer has the issue mentioned in this post. Gacthem and Ungacthem should not be needed moving forward!
We get quite a few questions about customizing visual elements of the POS in Dynamics AX for Retail. Most developers are aware that the POS application was built using third-party components from the DevExpress libraries, but there are a few details that you should know with respect to setting up a development environment with the DevExpress libraries.
All of the Windows forms in POS were developed using the product “DXExperience Winforms” created by DevExpress. If you plan on making any design-time visual changes to existing forms, you will need to purchase a license for this product for your developers. This can be done by visiting the DevExpress web site (www.devexpress.com). Although you do not need the DevExpress tools to create new POS forms from scratch, we strongly advise that you use them to keep a consistent look and feel with the rest of the product.
Once you have purchased the licenses, you will need to request a special build that was provided to the Dynamics AX for Retail product team: “DXperience WinForms Installer (without APTCA, Digitally Signed assemblies) v2009.2.109 / 13-Nov-2009”. If you open a support case with the DevExpress folks (https://www.devexpress.com/Support/Center/Issues/CreateIssue.aspx?issuetype=question) and tell them what product you are developing against, they will know what you need.
Unfortunately, there is a bug in the installer for this build of DXExperience Winforms: it will fail to install on any machine that has the .Net 4.0 Framework installed. For Windows 7, this pretty much means anything but the most vanilla box with no updates whatsoever. Because of this, these are the steps you need to perform to get everything installed correctly:
- Once you have received v2009.2.109 from DevExpress, install it on a vanilla Win7 machine (Virtual PC helps here).
- Make a backup copy of all files in the Components\Sources\DevExpress.DLL directory.
- On your development box, download and install the Unified Installer v2009 vol 2.13 (or later) from the DevExpress site.
- Manually remove all Devexpress components from the Global Assembly Cache by calling gac.exe from a command prompt. I have attached a batch file to this post to help with this step.
- Delete all DLL files in the Components\Sources\DevExpress.DLL directory on the development box.
- Manually copy the v2009.2.109 files into this directory.
- Re-register the DLLs into the Global Assembly Cache (again, using gac.exe). You can use the second batch file to help with this step.
Once you have everything installed properly, you should see this when you open an existing form:
Which looks a lot nicer than this series of stack trace errors:
One additional note with respect to DevExpress components. If you are modifying a POS Plug-in that contains a Windows form (e.g.,the Customer plug-in), but are not making any visual changes to any forms in the plug-in, you do NOT need to purchase or install the DevExpress design-time library. You can just compile your customized version of the plug-in using the run-time DLLs that get installed with the POS and the form will look and function just fine. For instance, you could make changes to the AuthorizeCustomerAccountPayment() method in the Customer.cs file, and not worry about anything in frmCustomerSearch.cs.