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

[Link]

1. Есть ли быстрый и уверенный способ найти все объекты на слое syp которые так же присутствуют на одном из более верхних слоёв? Объектов на слое syp очень много, что бы перебирать все вручную. Фильтр по проекту работает, но все равно находит не все объекты. Пропускает те, которые почему то не отображают правильно слой в АОТ (скрин с объяснением прикрепил).
   
2. Сравнение кода встроенной утилитой на больших методах с большим количеством модификаций занимает очень много времени, не говоря уже о кнопочках вставить код на таких методах. Есть ли более быстрые варианты или идеи?
   
3. Утилита Выявление конфликтов при обновлении кода - находит только некоторые объекты, в которых нужно поднять код. Интересно, об это где то упоминается или это всем очевидно?

На первом скриншоте два проекта, один собран джобом, а второй фильтром по проекту. Видно что фильтр пропускает некоторые объекты. На втором скрине на примере таблицы AssetTable видно, что в АОТ верхний слой таблицы syp, но на самом деле есть еще на слое isv, что находится утилитой сравнения.
Джобами (у меня их два - один ищет по UtilElements а второй по SysModelElement) тоже не все объекты находятся, например Maps пропускает и далеко не все классы находит.

AX2012 R2 CU8 модификации на слоях isv, isp, var, cus

[lvan]

detect conflicts всегда работал хорошо, в чем проблема то?

[Link]

Цитата:

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

detect conflicts всегда работал хорошо, в чем проблема то?

Увы, но не работает, в моем случае только небольшая часть объектов была найдена. Да, ошибок компиляции после него не осталось, но CU8 ставили не для галочки, да и чревато оставлять наполовину слитый код. Возможно некорректно отрабатываются определенные слои. Как я показал в скриншоте так же не работает отображение слоев в АОТ. Может еще кто сталкивался с подобным, у кого есть слои isv, isp, var, cus.

[Vadik]

Цитата:

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

Увы, но не работает, в моем случае только небольшая часть объектов была найдена

Всю жизнь работал, и вот на тебе..

Цитата:

Да, ошибок компиляции после него не осталось

Вообще этот мастер ничего не исправляет как бы..

Цитата:

Может еще кто сталкивался с подобным, у кого есть слои isv, isp, var, cus

Хм.. Т.е. у Вас куча партнерских решений "между" Вашим слоем USR и стандартом (SYS \ SYP) и эти промежуточные слои на CU8 никто не апгрейдил, так ? И что Ви таки хотите от системы в таком случае ? Естественно, "потроганное" на промежуточных слоях будет перекрывать изменения на SYP из CU8 и для мастера между "текущим самым верхним под USR" слоем и baseline изменений как бы нет. Нельзя вот так вот взять и проапгрейдить несколько слоев \ решений за один присест. Есть два варианта:

• ждать пока все партнеры предоставят свои слои \ решения "слитые" с CU8 и сливать USR уже с ними. Это долгий, но гарантированный рабочий вариант
• сливать все слои \ решения самостоятельно по одному, снизу вверх. Это долго, муторно и слабо понятно как быть с правками кода которые неизбежно потребуются при слиянии (сомневаюсь что у Вас есть коды разработки на эти промежуточные слои). Скорее всего, будете складывать их в свой текущий (USR). Скорее всего, к моменту когда выполните эту работу за партнеров и закатите этот Сизифов камень, с большущей долей вероятностей кто-то из них разродится новой версией "официально совместимой" с CU8, и "совместит" ее не совсем тем же образом или вообще отрефакторит все к такой-то матери, и приехали - на колу мочало, начинай сначала

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

[Link]

Цитата:

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

Всю жизнь работал, и вот на тебе..

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

Цитата:

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

Вообще этот мастер ничего не исправляет как бы..

Это понятно.

Цитата:

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

Хм.. Т.е. у Вас куча партнерских решений "между" Вашим слоем USR и стандартом (SYS \ SYP) и эти промежуточные слои на CU8 никто не апгрейдил, так ? И что Ви таки хотите от системы в таком случае ? Естественно, "потроганное" на промежуточных слоях будет перекрывать изменения на SYP из CU8 и для мастера между "текущим самым верхним под USR" слоем и baseline изменений как бы нет. Нельзя вот так вот взять и проапгрейдить несколько слоев \ решений за один присест. Есть два варианта:

• ждать пока все партнеры предоставят свои слои \ решения "слитые" с CU8 и сливать USR. Это долгий, но гарантированный рабочий вариант
• сливать все слои \ решения самостоятельно по одному, снизу вверх. Это долго, муторно и слабо понятно как быть с правками кода которые неизбежно потребуются при слиянии (сомневаюсь что у Вас есть коды разработки на эти промежуточные слои). Скорее всего, будете складывать их в свой текущий (USR). Скорее всего, к моменту когда выполните эту работу за партнеров и закатите этот Сизифов камень, с большушей долей вероятностей кто-то из них разродится новой версией "официально совместимой" с CU8, и "совместит" ее не совсем тем же образом или вообще отрефакторит все к такой-то матери, и приехали - на колу мочало, начинай сначала

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

Стоит модуль на isv\isp слое и его модификации уже от партнеров на var, все свои модификации на cus. Да промежуточные никто не апгрейдил, и не ясно когда будут, если будут.
Хочу иметь возможность быстро и уверенно найти все объекты в системе которые были измененны выше syp слоя, что бы можно было их анализировать и изменять при необходимости. Так же было бе не плохо, если бы правильно отображались слои объектов в АОТ.
Я все понимаю, но имхо апгрейдить каждый слой в нашем случае это оверкил, проблема не в том что бы поднять изменения с syp, а быстро и правильно найти объекты где это нужно сделать.
Первый вариант правильный, но задача стоит не так. Кастомер уже накатил CU8, партнеры обычно оперативностью не отличаются, а мне нужно иметь рабочую среду для разработки и тестирования уже сейчас. Код поднял на слой разработки, но поиск нужных объектов занял много времени.

[lvan]

Цитата:

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

Работает, но только с объектами измененными на текущем слое.

ну это известно было, вы бы почитали для начала, как им пользоваться
вроде даже в checklist написано, что надо отдельно каждый слой апгрейдить

[lvan]

Цитата:

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

Я все понимаю, но имхо апгрейдить каждый слой в нашем случае это оверкил,

на этом тему можно закрывать.

[imir]

Ну не так хорошо, например изменения в датасорсах форм не сечет, но в целом-то да, объекты,которые нужно поднять это то, что надо. Есть еще тулза сравнения слоев, если хочется получить все пересечения.

[lvan]

Цитата:

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

например изменения в датасорсах форм не сечет

неправда

[Dreadlock]

Цитата:

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

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

У нас на проекте один разработчик встроил в Ах2012 тулзу Araxis. Сравнение кода просто летает. Можно проделать тоже самое у себя.

[Wamr]

Еще вариант - пропустить modelstore через LCS Upgrade analysis, который выдаст подробный отчет, где чего нашлось, что удалось решить и сколько осталось.

[lvan]

не нужно изобретать велосипед
вот как нужно делать upgrade
https://technet.microsoft.com/EN-US/.../dn133163.aspx
рядом ссылки тоже почитайте

[Link]

Подведу итоги.

• Самый быстрый и уверенный способ найти объекты для апгрейда по нескольким слоям это фильтр по проекту, как на первом скриншоте.
  
  
• Сравнение кода встроенной утилитой на больших методах с большим количеством модификаций можно заменить внешней утилитой. Озвученный Araxis платный, можно попробовать WinMerge. По идее можно сделать надстройку в стандартной утилите и по ней выгружать с выбранного слоя\версии и сравнивать. К слову WinMerge легко интегрируется с TFS.
  
  
• Утилита Выявление конфликтов при обновлении кода работает только с текущим слоем. Правильно обновлять каждый слой поэтапно начиная с нижнего, но с большим количеством слоев такой подход займет очень много времени в основном на подготовку среды с нужным слоем. Да и не всегда это возможно.

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

[Maxim Gorbunov]

Цитата:

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

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

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

[Link]

Цитата:

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

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

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

[Maxim Gorbunov]

Какое-то недопонимание у нас с вами. AXBuild не компилирует в CIL, это да. Он для этого и не предназначен. Но точно так же не компилирует в CIL и компиляция приложения, запущенная из клиента. При этом, компиляцию приложения нужно делать перед компиляцией в CIL. Можно её после установки, конечно, сделать из чеклиста из клиента, но преимуществ это никаких не даёт.

Я при установке новой среды всегда первую компиляцию делаю в AxBuild. После этого иду обратно в клиента, докомпилирую то, что не смог скомпилировать AxBuild (если установка стандартная, то речь обычно идёт о примерно десяти Warning), и запускаю компиляцию в CIL. Проблем пока не замечал.

[Link]

Цитата:

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

Можно её после установки, конечно, сделать из чеклиста из клиента, но преимуществ это никаких не даёт.

Я при установке новой среды всегда первую компиляцию делаю в AxBuild. После этого иду обратно в клиента, докомпилирую то, что не смог скомпилировать AxBuild (если установка стандартная, то речь обычно идёт о примерно десяти Warning), и запускаю компиляцию в CIL. Проблем пока не замечал.

Вот я как раз о том, что первую лучше делать из клиента, иначе CIL может не компилироваться.
Как показывает поиск, мой опыт не единственный.

Цитата:

I have seen where the first compile (done through the checklist) needs to be done in the client and not through AXBuild. Try to do the compile in the client and see if you're able to proceed.

Цитата:

As stated in my previous reply some people (I'm aware of partners and ISV's) do a AX client based compilation because they rely that this always works.

[Maxim Gorbunov]

Цитата:

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

Как показывает поиск, мой опыт не единственный.

На мой взгляд, в этом треде единственный разумный ответ, вот этот:

Цитата:

There are two options to compile. It should both work as stated in this post: https://technet.microsoft.com/en-us/.../dd309589.aspx

If you encounter problems, please check if all prerequisites are met. If you still encounter problems, it is possible to create a support incident.

Остальные ответы на грани примет и предрассудков. Все пишут о каких-то "numerous problems", но никто при этом не пишет, в чём именно эти проблемы заключались.

Ещё раз повторю: я несколько раз делал первую компиляцию через AxBuild, и проблем не было ни разу. Компилировал так и AX2012 R2 CU7, и AX2012 R3 CU8. При этом я всегда строго следовал инструкции:

1. Останавливал AOS перед запуском AxBuild.
2. Компилировал приложение с помощью AxBuild.
3. Запускал AOS. Загружал в компилятор лог, который оставался от запуска AxBuild, и заново компилировал объекты, которые в этом логе упоминались.

[Link]

Цитата:

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

Ещё раз повторю: я несколько раз делал первую компиляцию через AxBuild, и проблем не было ни разу. Компилировал так и AX2012 R2 CU7, и AX2012 R3 CU8. При этом я всегда строго следовал инструкции:

1. Останавливал AOS перед запуском AxBuild.
2. Компилировал приложение с помощью AxBuild.
3. Запускал AOS. Загружал в компилятор лог, который оставался от запуска AxBuild, и заново компилировал объекты, которые в этом логе упоминались.

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

[Maxim Gorbunov]

Цитата:

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

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

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

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