View AOCP/RPC Interface Version used by an Arbitrary DAX Binary

First off a little bit of theory. Dynamics AX is a client-server application and utilizes a special protocol/interface for client-server communication. Namely versions prior to 4.0 used AOCP (Axapta Object Communication Protocol) implemented over TCP/IP and versions 4.0 and above have moved to an RPC interface. The client-server communication details inevitably change over time as kernel updates are released and obviously for robust Dynamics AX kernel operation it's vital to make sure that a client and a server understand each other precisely i.e. use the very same «dialect» of the communication protocol/interface. Hence an internal communication protocol/interface versioning is used in Dynamics AX kernel to find out if an arbitrary client can safely connect to and communicate with an arbitrary server. Those of you who has worked with Axapta 3 might remember that when you start a client with a kernel build number different from the AOS' kernel build number then the client most likely fails to connect to the AOS and complains about «Internal revision mismatch in Axapta Object Communication Protocol»; then it suggests to use the same kernel build for both client and Object Server. Why is it just a suggestion? First, the client has no idea if the server's kernel build matches it's own, and vice versa the AOS has no idea if a client attempting to connect has the same kernel build number as the AOS. Second, Dynamics AX clients and servers with non-matching kernel build numbers can connect and work with each other in case they use the same version of a communication protocol/interface. The first statement might look arguable. If you look in the User log (Administration/Inquiries/User log) you can find there some technical information about a user's session such as a client computer name, a client type and some kind of build number. Aha! So Object Server does know exactly the client's kernel build number, right? Wrong. A SysUserLog record which represents User log data is filled right in SysUserLog.insert() method. And while SysUserLog.Computername and SysUserLog.ClientType field values represent corresponding xSession object properties, SysUserLog.BuildNum field is initialized with a value returned by xInfo::buildNo() static method which has no explicit client or server modifiers. In 3-tier environment a table variable is generally located on the server side, hence SysUserLog.insert() and xInfo::buildNo() are executed on the server side and SysUserLog.BuildNum field receives server's kernel build number. So, once again, an AOS has no idea if a client attempting to connect to it has the same kernel build number or not. So when it comes to client/server interoperability, Dynamics AX kernel relies solely on the communication protocol/interface version, not kernel build numbers. And if that version is the same in client an server binaries then those binaries can be safely used together. But how can you know what communication protocol/interface version does an arbitrary Dynamics AX kernel binary use? Well, here is a utility for you: viewer for Dynamics AX AOCP/RPC interface version used by an given DAX kernel binary. Prior to a kernel binary file name you can pass these command line arguments:

• -nosigcheck - omit Authenticode verification (useful for some legacy kernel builds that miss the Authenticode digital signature)
• -debug - output additional technical information about the binary and print more detailed error messages if any

You now can easily find out (and check it out) that Dynamics AX 4.0 SP1 and SP2 binaries work together as they use the same RPC Interface version; and so do Dynamics AX 2009 TAP3 and RTM binaries...