[gl00mie]

Ой, подумать только - прошло уже больше года с тех пор, как всплыла эта тема, уже вышла DAX 2009... Хотелось, конечно, предложить данное решение раньше, но, как говорится, «у меня изменились личные обстоятельства» © х/ф. Впрочем, лучше поздно, чем никогда
Во вложении находится утилита, с помощью которой можно-таки без анализа трафика и ковыряния в бинарниках (это утилита сделает сама ) узнать, какую внутреннюю версию AOCP, если речь идет об Axapta 3, либо версию RPC-интерфейса, если речь идет о DAX4/2009, использует та или иная сборка ядра Аксапты. Для этого достаточно скормить утилите исполняемый файл ядра - AOS, клиент либо один из варинтов Business Connector'а (COM/.Net).

Зачем это нужно
Казалось бы, неписанное правило гласит, что связка клиент-сервер Аксапты всегда должна иметь одинаковый номер сборки, так зачем же ковыряться в каких-то там деталях их взаимодействия?.. Но практика показала, что разные сборки клиента и сервера могут при определенных обстоятельствах прекрасно работать друг с другом, однако, не совсем было ясно, как в общем случае можно подобрать такие пары с разными номерами сборки, чтобы они гарантированно заработали вместе. Совместное использование различных версий ядра системы может иметь смысл при обновлении ядра в условиях, когда новое ядро нужно развернуть на большом числе клиентских машин. В этом случае можно обновить ядро AOS, а затем постепенно обновлять ядро клиентов - при условии, конечно, что клиент старой версии сможет "ужиться" с сервером новой версии. В ходе экспериментов было выяснено, что это зависит от "внутренней ревизии" протокола AOCP (в случае Axapta 3), либо от версии RPC-интерфейса (в случае DAX4 и выше), используемого для взаимодействия клиента и сервера.
Ранее я писал, что, мол, «если верить журналу работы пользователей, AOS получает информацию о точной версии клиента», так вот, это оказалось заблуждением. В журнале работы пользователей, в поле SysUserLog.BuildNum действительно пишется номер сборки ядра, а размещение на соотв. форме этого поля рядом с полем "Тип клиента" может натолкнуть на мысль, что это номер сборки ядра клиента, однако в общем случае это не так. Если посмотреть по перекрестным ссылкам, то можно увидеть, что поля создаваемой записи SysUserLog заполняются не где-нибудь, а непосредственно в табличном методе insert(), при этом значения таких полей, как имя клиентского компьютера и тип клиента, берутся из свойств экземпляра класса xSession, а вот номер сборки ядра - из статического метода класса xInfo::buildNo(), не имеющего явно заданных модификаторов client или server. Дело, напомню, происходит в табличном методе, а табличные переменные в 3-хуровневой конфигурации живут в общем случае на сервере, следовательно, там же будет вызываться и метод xInfo::buildNo(). Стало быть, он в данном случае будет возращать номер сборки ядра сервера, а не клиента, как можно было бы предположить. Собственно, все эти рассуждения легко проверить самостоятельно, запустив в 3-хуровневой конфигурации клиента, чей номер сборки отличается от сервера, - и затем посмотреть, какой именно номер сборки будет записан в журнале работы пользователей для данного подключения.
Итак, с одной стороны, разработчики ядра Аксапты должны были обеспечить надежное взаимодействие клиентской и серверной частей системы, что подразумевает использование ими согласованного протокола взаимодействия, детали которого неизбежно могут изменяться со временем. С другой стороны, на момент подключения сервер не получает от клиента информации о его (клиента) точной версии, включая номер сборки, что было достоверно установлено в ходе анализа сетевого трафика и изучения сервера и клиента методами, о которых отдельно упоминается в лицензионном соглашении. Вместо этого для определения возможности подключения и дальнейшего взаимодействия с тем или иным клиентом сервер полагается на передаваемый им т.н. "внутренний номер ревизии AOCP" (применительно к Axapta3) либо на номер версии RPC-интерфейса (для DAX4 и выше). В последнем случае при запуске сервер указывает подсистеме RPC UUID и версию поддерживаемого им интерфейса; клиент при попытке подключения также указывает UUID RPC-интерфейса сервера приложений и поддерживаемую клиентом версию этого интерфейса. Подсистема RPC сверяет эти данные, и в случае рассогласования версий RPC-интерфейса клиента и сервера попытка клиентского подключения завершается с ошибкой "указанный интерфейс не поддерживается".
Таким образом, чтобы узнать, смогут ли работать вместе произвольные клиент и сервер, достаточно сравнить используемые ими версии AOCP или версии RPC-интерфейсов, в зависимости от того, к какой версии системы относятся эти клиент и сервер.

Вернемся к нашим баранам...
Несколько замечаний по использованию утилиты и ее работе.

• Утилите кроме названия файла ядра, подлежащего обследованию, можно указать параметр -nosigcheck, отключающий проверку цифровой подписи файла. Проверка цифровой подписи изначально задумывалась для уменьшения возможностей "надурить" утилиту, подсунув ей вместо ядра Аксапты какой-нить левый исполняемый файл, а также для освоения P/Invoke в C# Но потом выяснилось, что некоторые вполне даже "честные" сборки ядра Аксапты почему-то не имеют цифровой подписи - в частности, ядро версии 3.0.1951.17 в полном составе, а также сервер версии 3.0.1951.6710 (KR1).
• Указав параметр командной строки -debug, можно включить вывод некоторой дополнительной технической информации, в т.ч. в ситуациях, когда определить версию AOCP/RPC не удается.
• У меня есть почти все сборки ядра Аксапты с 3.0.1951.8 по 5.0.593.0, и можно было бы предположить, что утилита просто смотрит на номер сборки и выдает соответствующую заранее подготовленную информацию, но это не так. В ней реализован "честный" поиск соотв. версии AOCP/RPC, и с выходом новых версий ядра в этом можно будет убедиться.