А давайте поговорим про CIL

[svd-alex]

Приветствую!

У нас стоит AX 2012 R2 и есть 3 рабочих АОСа. Разработку ведут программисты на тестовой БД, а раз в неделю переносят доработки на рабочую базу. Перенос происходит так:

1) Перенос доработок на рабочую базу
2) Остановка всех АОСов
3) Удаление всех файлов из "c:\Program Files\Microsoft Dynamics AX\60\Server\DAX\bin\XppIL" на всех АОСах
4) Запуск одного АОСа (АОС1) и запуск на нём глобальной компиляции
5) Запуск на этом же АОСе создания полного CIL
6) Перенос всех файлов из папки "c:\Program Files\Microsoft Dynamics AX\60\Server\DAX\bin\XppIL" с АОС1 на остальные АОСы

Такой не быстрый метод (мягко говоря) мы используем потому что постоянно раньше возникли какие то проблемы с CIL и теперь мы стараемся делать всё предельно аккуратно.

При этом в этой папке создаётся порядка 280 тыс. файлов!

И вот с недавнего времени в какой то момент времени с одного или 2-х АОСов стали "пропадать" файлы в этой папке. Т.е. в какой-то момент смотришь - а файлов там уже не 280 тыс, а чуть меньше 3 тыс!
Я включил аудит и понял что удаляет файлы сам сервис АОСа (ax32srv.exe), при чём может удалить их сразу после своего запуска, а может через какое то время (а может и вообще не удалить).

Вопроса два:
1) Все ли файлы нужны в этой папке?
2) Почему АОС может так себя вести (удалять файлы)?

И большая просьба поделиться тем, как вы переносите доработки и есть ли у вас проблемы с CIL!

[ice]

Всем аосам не нужны файлы в их папке XppIL\Source\, достаточно только для одного. Переносим модификации с помощью моделстор из специально подготовленного приложения

[gl00mie]

Цитата:

Сообщение от svd-alex

4) Запуск одного АОСа (АОС1) и запуск на нём глобальной компиляции
5) Запуск на этом же АОСе создания полного CIL
6) Перенос всех файлов из папки "c:\Program Files\Microsoft Dynamics AX\60\Server\DAX\bin\XppIL" с АОС1 на остальные АОСы

6-й пункт - это закат солнца вручную. Ваш "ответственный" AOS после полной пересборки CIL закачивает соотв. файлы сборки в базу модели, другие AOS'ы при запуске проверяют актуальность своих файлов и при необходимости сами выкачивают новые файлы сборки из базы модели. Именно для этого, согласно официальным документам по развертыванию модификаций, их надо перезапускать. И да, файлы из каталога Source нужны лишь для компиляции CIL и отладки кода из VS, но не для повседневной работы AOS'ов.

[Ivanhoe]

1. После остановки всех АОСов удаляем папку XPPIL (или переименовываем для скорости). Еще можно файлы с метками поудалять (но не папку).
2. Переносим доработки на один АОС, делаем инкрементный CIL. Если ошибки - делаем полный CIL.
3. Рестартуем перый АОС, убеждаемся, что все работает.
4. Стартуем все остальные АОСы - они сами выкачивают XPPIL из БД, метки если удаляли.

Итого за 15 минут можно все успеть. При полном CIL - 30 минут.

[lvan]

> давайте поговорим про CIL

напомнило сагу об X, Y и Z

[lvan]

есть же White Paper: Deploying Customizations Across Microsoft Dynamics AX 2012 Environments
http://www.microsoft.com/en-us/downl....aspx?id=26571

казалось бы, при чем тут CIL?

[Alex_KD]

Цитата:

Сообщение от svd-alex

файлов там уже не 280 тыс, а чуть меньше 3 тыс!
Вопроса два:
1) Все ли файлы нужны в этой папке?
2) Почему АОС может так себя вести (удалять файлы)?

И большая просьба поделиться тем, как вы переносите доработки и есть ли у вас проблемы с CIL!

Видать у вас галка "Enable breakpoints to debug X++ code running on this server" включена, поэтому 280 тыс файлов (по файлу на каждый метод).
Debugging in Microsoft Dynamics AX 2012

[svd-alex]

Спасибо всем большое за ответы, всё предельно понятно теперь

[RVS]

Цитата:

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

есть же White Paper: Deploying Customizations Across Microsoft Dynamics AX 2012 Environments
http://www.microsoft.com/en-us/downl....aspx?id=26571

казалось бы, при чем тут CIL?

Вопрос ко всем.. кто в теме )

- чем перенос проекта (а-ля "старая", до 2012, Акса) реально грозит.. переносящему?
- приколы типа ругани "объект уже существует" (это - про сам проект, да.. все прочее - нормально импортируется.. ) - не упоминать.
- чем реально лучше новый механизьм.. с "моделями".. реклама а-ля "Microsoft AX2012 начинает новую эру в управлении артефактами метаданных." (с) Inside Ax 2012 - неинтересна..

PS : И если можно - не надо ссылок на вайтпейперы и прочую шелуху.. форум - профессиональный, как бы.. только личное мнение, так, да? Своими словами, на своем опыте, кратко (талантливо, то есть )

[gl00mie]

Модели - механизм в определенном смысле более гранулярный, чем XPO-шники. В одной модели может быть один метод или табличное поле, в другой модели - другой метод или табличное поле. При выгрузке XPO весь объект попадает в выгрузку, максимум можно играться слоями. Это может сильно осложнить жизнь при слиянии изменений, если для одного и того же объекта часть изменений надо перенести, а часть - нет.
Кроме того, перенос проектами реально грозит разъехавшимися ID-шниками объектов, особенно тех, что в DataDictionary Одной из фишек 2012-й является вроде как преодоление проблемы ID-шников объектов - их пересечения и исчерпания. Частью решения стали ID-шники, специфичные для инсталляции, см. также The solution to the element ID problem, и при переносе модификаций проектами ID-шники не сохраняются - выделяются новые. Как минимум, это чревато невозможностью легко и просто перенести затем рабочую базу в тест, потому что в тесте будут совершенно другие ID-шники в SqlDictionary и в полях типа RefTableId. Сразу скажу, что модели тоже не решают эту проблему - надо переносить базу модели целиком.

[RVS]

Цитата:

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

Модели - механизм в определенном смысле более гранулярный, чем XPO-шники. В одной модели может быть один метод или табличное поле, в другой модели - другой метод или табличное поле. При выгрузке XPO весь объект попадает в выгрузку, максимум можно играться слоями. Это может сильно осложнить жизнь при слиянии изменений, если для одного и того же объекта часть изменений надо перенести, а часть - нет.
Кроме того, перенос проектами реально грозит разъехавшимися ID-шниками объектов, особенно тех, что в DataDictionary Одной из фишек 2012-й является вроде как преодоление проблемы ID-шников объектов - их пересечения и исчерпания. Частью решения стали ID-шники, специфичные для инсталляции, см. также The solution to the element ID problem, и при переносе модификаций проектами ID-шники не сохраняются - выделяются новые. Как минимум, это чревато невозможностью легко и просто перенести затем рабочую базу в тест, потому что в тесте будут совершенно другие ID-шники в SqlDictionary и в полях типа RefTableId. Сразу скажу, что модели тоже не решают эту проблему - надо переносить базу модели целиком.

Спасибо.. Дивно )) но..

- мне, как пользователю (а программист - это тоже.. гм.. пользователь).. нафиг не нужны все эти "красЯвости", с "бОльшими гранулярностями"..

Зачем это придумано - в общем, понятно.. да, и было - понятно.. ))

Остался вопрос : "- чем перенос проекта (а-ля "старая", до 2012, Акса) реально грозит.. переносящему?"

Собственно, все.. все прочее - маркетинг от Микрософта )

PS : "Одной из фишек 2012-й является вроде как преодоление проблемы ID-шников объектов - их пересечения и исчерпания. Частью решения стали ID-шники, специфичные для инсталляции, см. также The solution to the element ID problem, и при переносе модификаций проектами ID-шники не сохраняются - выделяются новые. Как минимум, это чревато невозможностью легко и просто перенести затем рабочую базу в тест, потому что в тесте будут совершенно другие ID-шники в SqlDictionary и в полях типа RefTableId."



Мне это напоминает.. Dimensions в 2012-й.. только ленивый, походу, на написал еще примочку, которая по имени и DefaultDimension вытаскивает значение + расшифровку )))

Уроды писали 2012. Чтоб им.. икалось ))

PS : вопрос - остался..

[RVS]

Цитата:

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

Как минимум, это чревато невозможностью легко и просто перенести затем рабочую базу в тест, потому что в тесте будут совершенно другие ID-шники в SqlDictionary и в полях типа RefTableId. Сразу скажу, что модели тоже не решают эту проблему - надо переносить базу модели целиком.

Как максимум - это решается ежедневным обновление Test <<-- Prod, со спасением проектов.. "кто не спрятался - никто не виноват".

У меня так вот сейчас пока.. Вооот.. ))

ЗЫ : "Мелочь" а-ля что-то там поправить или отчет нарисовать - "разрабатывается" на Test. Отсюда и приколы типа "не уходи с работы, пока не спас проект.. в папку, блин.."

Повторяю : архитектура сделана.. уродами, и плохо документирована. Почему плохо - а потому, что они сами не знают, ЧТО из этого.. вырастет ))

[belugin]

Цитата:

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

- мне, как пользователю (а программист - это тоже.. гм.. пользователь).. нафиг не нужны все эти "красЯвости", с "бОльшими гранулярностями"..

1. Больше "гранулярность" означает что больше ситуаций, когда вместо анализа исправлений можно просто перенести новый код. "Нафиг не нужны все эти "красЯвости", с "бОльшими гранулярностями"" означает "Я, как программист, люблю сидеть в утилите сравнения, анализировать, что изменилось и вручную сливать свои изменения с изменениями в новой версии" - но это свойство скорее новой версии AX, а не моделей, как таковых. Например, если вы сделали добавление кнопки на форме, безо всяких новых моделей, при накатывании изменений она также появится на измененной форме сама.
   
2. Модели так же получили неофициальное название "параллельные слои". Так как можно сделать несколько независимых моделей на одном слое. Теоретически можно совместить на одном слое два партнерских решения - правда это требует отказа от изменения кода - использования только точек расширения (события и т.д.).
   
3. Проекты Visual Studio, которые в AOT нельзя надежно перенести в каком-то виде, кроме как в модели. При экспорте в XPO может получится файл, который нельзя загрузить.

Моделям также присущи определенные недостатки:

• при импорте модели возникает проект обновления, предлагающий перекомпилировать все приложение (чего можно избежать, но все-таки)
  
• модели чрезвычайно чувствительны к номеру версии, на которых их делают. Часто, на более старую версию нельзя установить модель, сделанную на более новой версии.

Если работать с кодом только при помощи контроля версий, то можно совместить достоинства моделей с достоинствами XPO.

Добавил статью на erpkb - дополняйте

[Vadik]

Цитата:

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

Проекты Visual Studio, которые в AOT нельзя надежно перенести в каком-то виде, кроме как в модели. При экспорте в XPO может получится файл, который нельзя загрузить

C чего бы это вдруг ?

[belugin]

Цитата:

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

C чего бы это вдруг ?

Мне непонятен смысл вашего вопроса - вы говорите, что такого не бывает, или вам непонятны причины этого?

• Если первое, то попробуйте перенести через XPO проект отсюда http://axcoder.blogspot.ie/2014/11/s...sing-xlnt.html
  
• Если второе, то мне багу закрыли с формулировкой "юзайте модели"

[Vadik]

Первое. До сих пор не сталкивался. Попробую

[lvan]

Цитата:

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

Остался вопрос : "- чем перенос проекта (а-ля "старая", до 2012, Акса) реально грозит.. переносящему?"

смотря в каком ключе на вопрос посмотреть
если про "реальную" угрозу, то зависит от босса, IT админа (который бакапит базу), но в общем случае, думаю, вплоть до летального исхода.

[RVS]

Цитата:

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

смотря в каком ключе на вопрос посмотреть
если про "реальную" угрозу, то зависит от босса, IT админа (который бакапит базу), но в общем случае, думаю, вплоть до летального исхода.

Боюсь-боюсь-боюсь..

А на серьезе если - представьте, чисто умозрительно, что есть 2012-я, в которую новые доработки пытаются (и небезуспешно.. может быть - пока небезуспешно) переносить именно проектами.

Вопрос : чем это потенциально грозит. Ну, не переносящему, конечно, а самой Аксапте..

[lvan]

потерей данных

[RVS]

Цитата:

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

потерей данных

Иван, краткость - она сестра, конечно. А подробнее - никак? Или в документ послать, правильный, где это обосновано?

Вот как-то представить, что от заливки проекта в Аксу в ней, Аксе, пропадают данные - вот не получается.. хоть убейте )