Jun 16, 2011
Filed under: #daxmusings #bizapps

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:

Class.QueryRun.axproxy

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.

 

There is no comment section here, but I would love to hear your thoughts! Get in touch!