перенос откомпилированного приложения

[wojzeh]

в продолжение своей темы о разной скорости компиляции хочу спросить, возможно ли просто перенести откомпилированное (глобальная компиляция) приложение с одной машины на другую?

насколько я понял из документации, при глобальной компиляции изменяется содержимое aod-файлов для каждого слоя. то есть никакой привязки к машине, на которой происходит компиляция нет. соответственно после простого переноса файлов должно быть достаточно выполнить синхронизацию с базой данных.

это так? какие есть засады на этом пути?

спасибо

[mazzy]

Цитата:

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

насколько я понял из документации, при глобальной компиляции изменяется содержимое aod-файлов для каждого слоя.

aod-файлы не меняются.

меняется aoi-файл и другие другие *.??i-файлы
а также возможно, alt

индексы не привязаны к слоям.

вполне можно копировать откомпилированное приложение.

важно помнить одно - если копируется из каталога с работающей аксаптой, то индексы не скопируются или могут быть скопированы неправильно. нужно остановить все АОСы и только после этого копировать.

[wojzeh]

Цитата:

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

aod-файлы не меняются.

меняется aoi-файл и другие другие *.??i-файлы
а также возможно, alt

индексы не привязаны к слоям.

вполне можно копировать откомпилированное приложение.

важно помнить одно - если копируется из каталога с работающей аксаптой, то индексы не скопируются или могут быть скопированы неправильно. нужно остановить все АОСы и только после этого копировать.

хм... индексы, насколько я понимаю, можно прибить, а потом пересоздать перезапуском аос. именно так я и делал, базируясь на теме Как грамотно почистить кеш

а вот что пишут в документации на 4 странице Chapter 4: Installing a Base System Installation and Configuration in Microsoft Dynamics® AX 2009

Compile Application

The Compile Application function updates the references and makes sure that the
application is ready for use. This process can take an hour or more to run,
depending on the computer's hardware. This is step is required to initialize the
system. When the application is compiled, the application source code is
translated into binary code that can be interpreted by the kernel. The binary code
is stored in the .aod file.

или мы о разных вещах говорим?

собственно меня интересует оптимальный путь инсталляции ролапов, хотфиксов и прочих апгрейдов системы

[mazzy]

начал сомневаться.
послушаем что скажут другие.

[S.Kuskov]

На сколько я понимаю при компиляции происходит пересборка бинарного кода. Т.е. если например была изменена константа в каком-нибудь макросе, то при компиляции измениться и бинарный код и как следствие изменится aod файл.

В любом случае просто переноса файлов и их переиндексации вполне достаточно. Повторная компиляция, имхо, излишня.

[wojzeh]

Цитата:

Сообщение от S.Kuskov

На сколько я понимаю при компиляции происходит пересборка бинарного кода. Т.е. если например была изменена константа в каком-нибудь макросе, то при компиляции измениться и бинарный код и как следствие изменится aod файл.

В любом случае просто переноса файлов и их переиндексации вполне достаточно. Повторная компиляция, имхо, излишня.

а зачем нужна повторная переиндексация в таком случае?

[sukhanchik]

В 3.0 и 4.0 было четкое ощущение, что откомпилированный код сохраняется в *.aod-файлах. Собственно - сам откомпилированный код можно увидеть в таблице UtilElements в поле Code. Точнее можно увидеть, что это BLOB-поле .

Когда обновляли версию слоями - то было все ок.

В 2009 обратил внимание на то, что после обновления слоем - возникает потребность в перекомпиляции слоя. Не знаю почему - но факт. Отсюда вывод - все же что-то в индексах хранится в 2009

[wojzeh]

Цитата:

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

В 3.0 и 4.0 было четкое ощущение, что откомпилированный код сохраняется в *.aod-файлах. Собственно - сам откомпилированный код можно увидеть в таблице UtilElements в поле Code. Точнее можно увидеть, что это BLOB-поле .

опаньки! стало быть, при компиляции что-то складируется в базу данных, и соответственно простым переносом горю не помочь!

[AndyD]

UtilElements, UtilIdElements - это псевдотаблицы.
Их нет в базе данных, а сами данные онb как раз берут из aod-файлов (или из кэша, если он есть).
Собственно, эти файлы и являются базой данных в специальном формате.

Насчет aoi-файла. Ну, это аналог обычных индексов в базе данных. Можно без них, но с ними намного быстрее

[S.Kuskov]

Цитата:

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

а зачем нужна повторная переиндексация в таком случае?

Её же делает AOS в момент запуска. А AOS теперь другой. Теоритически какие-нибудь отличия в версиях серверов или их настроек могут сыграть. А там кто его знает может и не нужна.

[Pustik]

У нас не было проблем с этим никогда. Был такой случай, когда отчет строился за 2 мин, вдруг стал строиться за 10 мин. Почистили статистику на SQL, и все встало на свое место

[someOne]

Цитата:

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

важно помнить одно - если копируется из каталога с работающей аксаптой, то индексы не скопируются или могут быть скопированы неправильно. нужно остановить все АОСы и только после этого копировать.

Вот такой батник использую для копирования из рабочего приложения в приложение разработки. При этом остановка АОС (исходного) не требуется. Все файлы, в том числе индексы - копируются. После копирования никакой переиндексации или компиляции не требуется. Получается полностью работоспособная копия "рабочего" приложения.

Нужна лишь синхронизация, если были изменения в словаре БД

set service="Dynamics AX Object Server 5.0$01-DynamicsAxDev"

set TODIR=C:\Program Files\Microsoft Dynamics AX\50\Application\Appl\proto\

set FRDIR=\\axserver\c$\Program Files\Microsoft Dynamics AX\50\Application\Appl\axapta\

net stop %service%

del "%TODIR%*.*" /Y

xcopy "%FRDIR%*.*" "%TODIR%"  /f /Y

net start %service%

pause 0

[Sergikrus]

Ребята, вопрос по существу .
AX 2009. Опустил разработку с usr слоя на слой ниже, предваритель удалив эту разработу с usr, откомпилировал, обновил перекрёстные ссылки, перезапустил AOS, но размер usr слоя осталcя прежним. По идеи слой должен уменьшиться, если удалить с него изменения. Я что то не то сделал, что то пропустил?

[oip]

Удаленные объекты из aod-файлов не удаляются. Размер aod-файла никогда не уменьшается.

[Sergikrus]

Есть ещё один небольшой вопрос.

Получили разработку выгруженнцю в *.xpo, накатил на слой usr, протестировал. Настало время опустить разработку на слой ниже, а конкретно на BUS. В приложении для разработок после наката на слой и после рестарта AOS получил несколько ошибок от класса Info и Application, но всё поченилось глобальной компиляцией.

Следующим этапом необходимо перенести на тестовое приложение слой с этой разработкой (это давняя практика и ничего не хорошего не случалось).

После подставки слоя, AOS стартанул после 3 попытки, а при запуске приложения получаю теже ошибки что и на приложении для разработок, но в этом случае вприложение завершается и откомпилировать ничего не выходит. Как быть?

Вот ошибки что возникают при старте приложения:

[Mykola Galak]

Цитата:

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

Удаленные объекты из aod-файлов не удаляются. Размер aod-файла никогда не уменьшается.

На чем базируется утверждение?

[Товарищ ♂uatr]

Здравствуйте.
В рамках поставок решений осуществляем перенос aod файлов.
При этом aoi удаляем. Запуск АОСов, создание нового aoi файла, занимает время = простой.
Возникает вопрос: практикует ли кто-либо перенос aoi?

[sukhanchik]

Цитата:

Сообщение от Товарищ ♂uatr

Здравствуйте.
В рамках поставок решений осуществляем перенос aod файлов.
При этом aoi удаляем. Запуск АОСов, создание нового aoi файла, занимает время = простой.
Возникает вопрос: практикует ли кто-либо перенос aoi?

В 3.0 / 4.0 пробовали - высокий риск нарваться на кэш в пересеченных объектах (т.е. в тех объектах, которые находятся в новом .aod и в текущем.aod разных слоев).
Но.. собственно - почему простой? Не на рабочую же сразу надо накатывать. Надо ж подготовить приложение, сделать глобальную компиляцию и только после этого уже выкладывать.
Как бы такой подход и в D365FO практикуется - даже если ты сваял свою dll "сбоку" на C# - она сразу на PROD никогда не выкладывается - только через процедуру сборки

[Товарищ ♂uatr]

Это 5-ка.
Подготовка (ГК и тп) к релизу осуществляется на соответствующей среде. Далее aod-файлы "мигрируют" на рабочее приложение.
Понятное дело, что на время проведения релиза запущен только 1-н АОС и доступ у пользователей к системе ограничен. Отсюда и простой.
Сам релиз занимает в районе получаса, где ~20 минут уходит на создание aoi файла.
Исходя из этого, выглядит логичным помимо aod-файлов с подготовительной среды, так же копировать и aoi. На рабочей среде не очень хочется проводить эксперименты по бразильской схеме, поэтому интересует практический опыт, вряд ли только мне такая мысль пришла в голову.
365 давайте вынесем за скобки, это совершенно иной продукт.

[Logger]

Несколько раз за всю практику копировал aoi - вроде работало. Но перед копированием лучше застопить все аосы.
Но обычно их не копировали. На всякий случай давали возможность вторичным данным (индексам) перестроиться заново.
Если мне не изменяет память то aoi строился не дольше 10 минут и это было в 17-м году. С учетом того что мощности железа только выросли, должно стать еще быстрее, так что надо искать где идет потеря скорости.

Цитата:

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

В 3.0 / 4.0 пробовали - высокий риск нарваться на кэш в пересеченных объектах (т.е. в тех объектах, которые находятся в новом .aod и в текущем.aod разных слоев).

Мне кажется не должно быть проблемы если копировать все aod файлы. Так нужно делать, так как в них хранится скомпилированный байт код приложения. Поэтому изменения на USR слое хоть и не влияют на исходные тексты sys слоя, но могут влиять на его байт код. (Пример: добавили переменные в ClassDeclaration класса RunBase или SalesTableType - это приведет также к изменения байткода классов наследников на sys слое, поэтому если не скопировать все aod файлы то могут быть ошибки времени выполнения. Либо надо делать полную компиляцию. Но зачем, когда можно скопировать....)