Thursday, June 16, 2011

AX2012 .NET Proxies for Kernel Objects

For those who've played around with Visual Studio and AX2012, the proxies are a great way to most of your logic on the .NET side, without too much hassle. One thing is apparent after a while though: how do we create proxies for kernel classes and tables? For some classes, there is a Sys* version (eg SysQueryRun, SysDictTable, etc), but first of all, you don't get the static methods of the original kernel class, and as for queries, there is no Sys* equivalent of QueryBuildRange and so on.

So how do we get the proxy? Turns out, this is all handled by the .axproxy file extension. Just create a new file (mind the case! remember .NET is case-sensitive!) in the format ObjectType.ObjectName.axproxy. For example, to get QueryRun, create a file:


The standard Visual Studio AX tools just put a plain text message in this file:

This is a Microsoft Dynamics AX proxy file that generates classes for the element that it represents in the project to which it is added.

With the file created, you can drag and drop the .axproxy file onto your Visual Studio project, and the build will generate the proxy for you. (again, watch the case... for example the class QueryBuildDataSource has a capital S in datasource!)

Obviously this is not the recommended way to create proxies, but I have yet to hear a more official way to do this from Microsoft. As for built-in X++ functions in AX, the official word is there is no way to get those, except creating a wrapper class in X++ and generating a proxy for that.


  1. For 2009 users, there is a free tool at that will generate compiled .NET proxies automatically from a project or set of AOT objects. It also includes kernel objects (tables, classes, enums etc), and there is no need to maintain a list of specific methods etc.

  2. Another way to do this is to create a class that extends the kernel class. Once this new class is added to the proxy project you'll automatically get a proxy of the extended kernel class. Ofcourse this won't work for kernel classes that are marked final.

  3. Is there a way to wrap the QueryRun with a TTSCOMMIT\TTSBEGIN so that we can update records in from the interop code?