Вот мы и нашли этих 43 AX7 клиентов? Или это не AX7/D365?

[skuull]

Цитата:

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

самый простой пример - поля на таблице. т.е. у вас есть новое поле "A" на CustTable лежащее в кастомизации этой таблицы, вы решаете сделать по модному..

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

Цитата:

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

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

Если вы уже стоите на шатком пути оверлеинга App Suite, такие мелочи вас не должны останавливать. Создается третья модель, котороя ссылаеться на экстеншен и предастваляет доступ к полям, а App Suite ссылаеться на нее. Все легко и немного извращенно

[trud]

Цитата:

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

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

в терминах 2012 - все ваши объекты содержатся только в вашем слое(не являются перекрытиями в sys). например новые поля в sys таблицах или методы классов. в рамках 2012 это позволяло обновляться на новые версии(CU) без мержинга кода

Цитата:

Создается третья модель, котороя ссылаеться на экстеншен и предастваляет доступ к полям, а App Suite ссылаеться на нее.

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

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

идеальным вариантом конечно было бы сделать возможности изменения теми которые сейчас есть в экстеншенах(т.е. возможность менять меню, форм, каких-то св-в без перекрытия базового кода) + предложить разработчику решать - хочет ли он помещать код в отдельную DLL(в этом случае компилятор уже должен следить чтобы не было обращений к приватным переменным и прочему) или вместе с основной. зачем они сделали 2 разных по сути формата файлов изменений (кастомизацию и экстеншн) это не очень понятно
несомненный негатив от экстеншенов в том виде как они сейчас есть - это то что это другой объект в AOT с произвольным названием и визуально их наличие реализовано слабо - т.е. раньше хотя бы все эвенты было видно в AOT, теперь можно подписаться на метод, это вообще никак визуально будет не видно
как разбираться в таком коде - особенно если он изначально разрабатывался не вами - не очень понятно, на мой взгляд время проведенное за анализом будет поболее чем время за обновлением на очередной CU

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