Какая версия клиента в Ax 3 KR2 ?

[egorych]

В FAQ смотрел, написано - 3.0.1951.7500.
У себя ставлю, получается АОС - 3.0.1951.7500, а клиент - 3.0.1951.7609.
Так и должно быть?

[mazzy]

Цитата:

Сообщение от egorych

В FAQ смотрел, написано - 3.0.1951.7500.
У себя ставлю, получается АОС - 3.0.1951.7500, а клиент - 3.0.1951.7609.
Так и должно быть?

Насколько я помню, номер билда у клиента и АОСа должен быть одинаковым.
Строка с билдом создается в классе ApplicationVersion::main.
У вас там никто не пошаманил?

[egorych]

НЕ, я смотрю свойства файла ax32.exe. Там есть закладочка "Версия". Так вот для АОС указано 7500 а для клиента 7609

[mazzy]

Цитата:

Сообщение от egorych

НЕ, я смотрю свойства файла ax32.exe. Там есть закладочка "Версия". Так вот для АОС указано 7500 а для клиента 7609

Вот оно как... Нет, туда я не смотрел.
Но информацию вы дали интересную. Надо подумать.

[gl00mie]

Цитата:

Сообщение от mazzy

Вот оно как... Нет, туда я не смотрел. Но информацию вы дали интересную. Надо подумать.

Ничего интересного, VersionInfo - штатный ресурс в любом нормальном виндовом исполняемом файле (в т.ч. dll, ocx, драйверах устройств, etc). Другое дело, что в поставке AX3 KR2 нет и не может быть клиента версии KR3 (а 3.0.1951.7609 относится именно к KR3), так что это какие-то глюки. Возможно, клиент KR3 стоял раньше, и установщик не стал его перезаписывать, поскольку номер версии (взятый из того же ресурса VersionInfo) у него больше. Пакет установки AX3 KR2, а именно ZIP-sfx архив размером 20282184 байт, имеет электронную подпись мелкософта от 30.05.2006 7:36:19. В то же время на клиенте версии 3.0.1951.7609 (размер 7609128) стоит электронная подпись мелкософта от 11.10.2006, так что, очевидно, он не мог быть среди файлов, устанавливаемых в рамках официального пакета AX3 KR2.

[mazzy]

Цитата:

Сообщение от gl00mie

Ничего интересного

Ну, что вы! Конечно же интересная.
Значит клиент и АОС разных билдов таки работают друг с другом.
Интересно, при каких условиях?

ЗЫ Впрочем, если вам интереснее versioninfo, не смею настаивать

[glibs]

Цитата:

Сообщение от mazzy

...
Значит клиент и АОС разных билдов таки работают друг с другом.
...

Конечно.

Цитата:

Сообщение от mazzy

...
Интересно, при каких условиях?
...

Должна быть одинаковой версия AOCP.

Например, клиент Кр3 работает с АОС Кр2. По-моему, клиент 3.0 сп3 работает с АОС 3.0 сп4 и наоборот.

Если в новом СП изменяется версия AOCP, то клиент и АОС разных версий перестают работать вместе.

Кстати, раньше ты знал ответ на этот вопрос .

[egorych]

перед установкой все удалялось. Папка клиента создалась установщиком и в нее записан был ax32.exe размером - 7 609 128 байт и версии 7609. Откуда он взялся в установке KR2 мне и самому интересно узнать было-бы.

[gl00mie]

Цитата:

Сообщение от egorych

перед установкой все удалялось. Папка клиента создалась установщиком

Что в данном случае называется установщиком? Из какого пакета ставился KR2? Воспроизводится ли это на других компьютерах? Чудес ведь не бывает - по крайней мере, в том, что касается компьютеров

[egorych]

Цитата:

Сообщение от gl00mie

Что в данном случае называется установщиком? Из какого пакета ставился KR2? Воспроизводится ли это на других компьютерах? Чудес ведь не бывает - по крайней мере, в том, что касается компьютеров

Ставилось из родного инсталяторя KR2, на других компах не пробовал еще. Вернее пробовал на 1, где был установлен клиент SP3 - результат тот-же. Если у кого-то есть установленный клиент от KR2, просьба прислать на почту.

[glibs]

7609 — это кр3, насколько я знаю. А чем вас не устраивает Кр3?

Да и адрес ваш почтовый непонятно где искать...

[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, и с выходом новых версий ядра в этом можно будет убедиться.