Слияние кода на примере CU8

[Maxim Gorbunov]

Речь идёт о новой установке AX или о новой установке ваших модификаций?

Такие ошибки бывают, когда из Base Enum удаляют элемент или удаляют поля из таблицы, которые были в AOT при предыдущей генерации CIL. Но если установка новая, то таких изменений быть не должно.

Я всё же склоняюсь к тому, что проблема в вашем приложении и в том, как вы его разворачиваете, а не в AxBuild.

[Link]

Цитата:

Сообщение от Maxim Gorbunov

Речь идёт о новой установке AX или о новой установке ваших модификаций?

Эта тема про установку CU8. Но предположу, что новая установка с модификациями тоже может иметь эту проблему, если разворачивать не из modelstore.

Цитата:

Сообщение от Maxim Gorbunov

Такие ошибки бывают, когда из Base Enum удаляют элемент или удаляют поля из таблицы, которые были в AOT при предыдущей генерации CIL. Но если установка новая, то таких изменений быть не должно.

Да, и видимо это и произошло при установке CU8.

[trud]

Кстати хороший вопрос - а как вообще устанавливать хотфиксы(даже пусть они будут маленькие, а не CU) при наличии ISV слоев и отсутствии ISV лицензии. т.е. по хорошему все равно надо запускать Утилиту Выявление конфликтов. кто нибудь ее допиливал до работы в слое отличном от текущего?

[Link]

Цитата:

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

Кстати хороший вопрос - а как вообще устанавливать хотфиксы(даже пусть они будут маленькие, а не CU) при наличии ISV слоев и отсутствии ISV лицензии. т.е. по хорошему все равно надо запускать Утилиту Выявление конфликтов. кто нибудь ее допиливал до работы в слое отличном от текущего?

Внутренняя утилита ищет конфликты только в активном слое. Можно фильтром по проекту найти все перекрытые объекты выше syp и сравнивать изменения вручную. Ну а по хорошему конечно нужно ждать партнеров, если они поддерживают решение.

[Vadik]

Цитата:

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

Кстати хороший вопрос - а как вообще устанавливать хотфиксы(даже пусть они будут маленькие, а не CU) при наличии ISV слоев и отсутствии ISV лицензии

Я для мелких хотфиксов держу отдельное "чистое" приложение (SYS \ SYP) и оттуда вручную дельту переношу на текущий слой

[Maxim Gorbunov]

Цитата:

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

Да, и видимо это и произошло при установке CU8.

Насколько мне известно, в CU8 нет удалённых элементов Base Enum по сравнению с CU7. Поэтому проблема, скорее всего, в модификациях, которые выше слоя SYP.

В общем, AxBuild не является полной заменой для компиляции из клиента, но запускать глобальную компиляцию приложения из клиента больше не нужно. Достаточно докомпилировать через клиент те объекты, с которыми не справился AxBuild.

[Maxim Gorbunov]

Цитата:

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

Если забыть запустить админом, то лог может не записаться и "потеряться".

Странно. У меня в таких случаях AxBuild останавливается с ошибкой ещё перед первым проходом.

[Link]

Цитата:

Сообщение от Maxim Gorbunov

Насколько мне известно, в CU8 нет удалённых элементов Base Enum по сравнению с CU7. Поэтому проблема, скорее всего, в модификациях, которые выше слоя SYP.

Похоже на то, у клиента порядочно модификаций. Один Base Enum был, а всего больше сотни объектов поднял.

Цитата:

Сообщение от Maxim Gorbunov

В общем, AxBuild не является полной заменой для компиляции из клиента, но запускать глобальную компиляцию приложения из клиента больше не нужно. Достаточно докомпилировать через клиент те объекты, с которыми не справился AxBuild.

По ссылкам выше писали, что компиляция таблиц и классов из АОТ тоже помогла.

[Link]

Цитата:

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

Я для мелких хотфиксов держу отдельное "чистое" приложение (SYS \ SYP) и оттуда вручную дельту переношу на текущий слой

Допустим, есть таблица А с методом В в слоях sys и syp. Хотфикс измененяет метод В. Как вы узнаёте, что именно эта таблица была обновлена и необходимо ли подымать код метода В на верхний слой на основании только системных слоёв?

[Maxim Gorbunov]

Цитата:

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

У меня и коллеги была одна и та же ситуация, после безошибочной компиляции в AxBuild CIL выдавал ошибки вроде этой . Перезапуск АОС, удаление папки CIL и т.д. ничего не изменило.
Компиляция из клиента помогла в обоих случаях. Теоретически AXBuild должен работать, по крайней мере я не встречал в документации обратного.

Совершенно случайно вчера наткнулся на точно такую же ошибку при компилировании приложения через AxBuild. Проблема была в том, что при запуске AxBuild я в параметре /altbin указал не папку Bin клиента, а папку Bin сервера.

Будьте внимательны. В altbin надо указывать путь к DLL, которые устанавливаются вместе с клиентом. На TechNet даже написано, что AxBuild перед запуском проверяет, что в этой папке действительно есть ax32.exe. На самом деле ничего он не проверяет, а просто компилирует приложение и записывает кучу ошибок в лог, и компиляция в CIL потом не проходит.

[Maxim Gorbunov]

Цитата:

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

Допустим, есть таблица А с методом В в слоях sys и syp. Хотфикс измененяет метод В. Как вы узнаёте, что именно эта таблица была обновлена и необходимо ли подымать код метода В на верхний слой на основании только системных слоёв?

Именно для этой цели и существует baseline приложение.

[Link]

Цитата:

Сообщение от Maxim Gorbunov

Совершенно случайно вчера наткнулся на точно такую же ошибку при компилировании приложения через AxBuild. Проблема была в том, что при запуске AxBuild я в параметре /altbin указал не папку Bin клиента, а папку Bin сервера.

Будьте внимательны. В altbin надо указывать путь к DLL, которые устанавливаются вместе с клиентом. На TechNet даже написано, что AxBuild перед запуском проверяет, что в этой папке действительно есть ax32.exe. На самом деле ничего он не проверяет, а просто компилирует приложение и записывает кучу ошибок в лог, и компиляция в CIL потом не проходит.

В нашем случае это не релевантно, у меня все установленно локально и указывать /altbin необходимости не было. У коллеги была своя независимая среда, и те же ошибки, пока не была выполнена компиляция из клиента.

[Link]

Цитата:

Сообщение от Maxim Gorbunov

Именно для этой цели и существует baseline приложение.

Мой вопрос был в контексте "чистого" приложения. Я не совсем понимаю, как такой подход работает. Т.е. если мне нужно поднять изменения патча на свой слой, как это происходит с отдельного "чистого" приложения, где свой слой отсутствует.

[Maxim Gorbunov]

Цитата:

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

Мой вопрос был в контексте "чистого" приложения. Я не совсем понимаю, как такой подход работает. Т.е. если мне нужно поднять изменения патча на свой слой, как это происходит с отдельного "чистого" приложения, где свой слой отсутствует.

Ну вы же с old-слоями работали в AX2009? Baseline - это тот же Old. Перед установкой хотфикса скопируйте приложение в Baseline (некоторые хотфиксы это сами делают), установите хотфикс, и сравнивайте. В вашем случае как раз и найдётся разница на слое SYP в методе B в основном приложении и в baseline. Если в методе также есть модификации на текущем слое, то Detect upgrade conflicts его найдёт и добавит в upgrade-проект.

[Maxim Gorbunov]

Цитата:

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

В нашем случае это не релевантно, у меня все установленно локально и указывать /altbin необходимости не было. У коллеги была своя независимая среда, и те же ошибки, пока не была выполнена компиляция из клиента.

Попробуйте указать. Эти ошибки могут быть связаны с тем, что во время компиляции AxBuild не нашёл DLL, на которые есть ссылки в X++. Или нашёл не те.

Ещё раз повторю свой основной тезис: разница между компиляцией через клиента и через AxBuild минимальна, и в большинстве случаев эти методы взаимозаменяемы.

[Link]

Цитата:

Сообщение от Maxim Gorbunov

Попробуйте указать. Эти ошибки могут быть связаны с тем, что во время компиляции AxBuild не нашёл DLL, на которые есть ссылки в X++. Или нашёл не те.

Ещё раз повторю свой основной тезис: разница между компиляцией через клиента и через AxBuild минимальна, и в большинстве случаев эти методы взаимозаменяемы.

Спасибо, Максим, в следующий раз попробую обойтись AXBuild.

[Maxim Gorbunov]

Цитата:

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

Спасибо, Максим, в следующий раз попробую обойтись AXBuild.

Спасибо. Если не трудно, расскажите потом, остаются ли ошибки. Интересно же