Flushing the permanent Class Hierarchy Cache

• It has been mentioned before that the class hierarchy information in AX has to be refreshed manually, if it changes:
  • http://alexvoy.blogspot.de/2015/08/extension-framework-and-sysglobalcache.html
  • https://community.dynamics.com/ax/b/ievgensaxblog/archive/2016/11/08/ax-7-clear-extension-framework-cache-from-ui
  • http://kashperuk.blogspot.de/2017/03/development-tutorial-sysextension.html
  • and probably more
• It’s important to note that the class hierary and probably other static cache information are intentionally not refreshed when an AOS is restarted, but are instead stored in the AX business database. This includes the case where code was changed, be it directly or by the import of a model file.
• A hint on how to refresh this can even be found in a comment in standard AX code
  

• The solutions mentioned in code and in the blogs might be OK for development Environments (*), but I was looking for a something to use with powershell or similar deployment automation scripts so that the cache is cleared everytime the code is modified in a deployment.
• I looked a bit closer to find where the cache is stored and got to the SysExtensionCache class. In method insertValueOnServer you can see that the classHierarchy information is stored in SysLastValue
• After seeing this simple and straightforward implementation, I decided to go for deleting the specific records from the database via a script in the database – its X++ counterpart is

  delete_from lastValue  
  where lastValue.userId == '' && 
  lastValue.company == '' && 
  lastValue.elementName == classStr(SysExtensionCache) && 
  lastValue.recordType == 45; // UtilElementType::Class;

• This issue can be found with AX2012 and AX365fFO.
• The solution has been tested in AX2012.
• I haven’t checked whether the solution can be applied to AX365fFO – I hope the issue is covered by Microsoft when they deploy to production; the solution might be of interest to the sandbox environments.

(*) I personally don’t think that this can be called better than a workaround for development Environments: Synchronizing code from version control should invalidate the cache. If “get latest” doesn’t invalidate the cache, then a compile should. If a compile doesn’t invalidate the cache, then a full compile should.