Прощай, X++

[ax_mct]

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

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

Подешевле и без жучков - вот и все критерии. А те же функциональные жучки они в любом зерне независимо от качества зерен. Потому как со стороны приползают. Функциональной.

[ax_mct]

Насколько я знаком с идеологией .Net, а я с ней хорошо знаком хотя мог что-то уже и подзабыть,
самым логичным вариантом является X++.Net вначале и постепенное изменение Х++ для почти полной идентичности с C# и совместимости с IL типами.
"Разные синтаксисы-один язык". MSIL, CLR и Visual Studio - это их столпы, но не C#.

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

Достаточно ведь просто сказать что X++ мало чем отличается от C# и Java, добившись того же эффекта, чем действительно переписывать систему.

А в случае смены исходников и полного перехода на C# - AX скорее всего умрет слившись в одну систему с другими купленными ERP. Хорошо это или плохо - я не знаю. Просто на мой взгляд подобный ход в любом случае не будет косметическим и безобидным для той АХ которую мы знаем. Хотя тот же HTML5 интерфейс уже нечто с косой и злобными глазками

[belugin]

Цитата:

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

А в случае смены исходников и полного перехода на C# - AX скорее всего умрет слившись в одну систему с другими купленными ERP.

Какая-то непоследовательность у вас - то ли замена языка есть поворотный момент с точки зрения ERP, то ли это незначительная подробность реализации.

[ax_mct]

Цитата:

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

Какая-то непоследовательность у вас - то ли замена языка есть поворотный момент с точки зрения ERP, то ли это незначительная подробность реализации.

В рамках метода стиль и синтаксис - незначительная подробность реализации.
В рамках системы - серьезная трансплантация.

А непоследовательность конечно же есть у меня есть, у нас быдлокодеров иначе быть и не может. http://lurkmore.to/Быдлокодер
Нам не логика нужна а наша правда!

[gl00mie]

Вспоминается презентация 5-летней давности Channel9: Peter Villadsen and Gustavo Plancarte: X++ to MSIL

Цитата:

Peter Villadsen: Да, мы уже думали об этом. В частности, мы думали о том, чтобы генерировать из p-кода исходный код на C#, и нам это вполне под силу. И это дает нам возможность полностью отказаться от X++: давайте просто нажмем на кнопку и транслируем 98% имеющейся бизнес-логики в корректно работающий код на C#; затем мы можем посадить за работу армию программистов, и через месяц они доведут этот показатель до 100%, и тогда X++ уйдет в историю.

[Logger]

Цитата:

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

Вспоминается презентация 5-летней давности Channel9: Peter Villadsen and Gustavo Plancarte: X++ to MSIL

Правда при таком подходе придется оставить движок форм, отчетов, query* классы и.т.п. Ну и пусть. Будет как библиотека.
Сразу от этого отказаться пожалуй действительно будет затратно.

Если честно то я пока не понимаю, почему в 2012-й оставили компиляцию в p-код. Почему бы всегда не компилить в IL, а не только для нужд пакетов и.т.п.

Это было для чего-то необходимо ?

[belugin]

Цитата:

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

Если честно то я пока не понимаю, почему в 2012-й оставили компиляцию в p-код. Почему бы всегда не компилить в IL, а не только для нужд пакетов и.т.п.

Дело в том, что есть выполнение кода на клиенте, то есть надо таскать код приложения на клиент. С учетом того, что в коде приложения есть циклические зависимости и приложение является одним большим assembly это было бы накладно.

[Logger]

Цитата:

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

Дело в том, что есть выполнение кода на клиенте, то есть надо таскать код приложения на клиент. С учетом того, что в коде приложения есть циклические зависимости и приложение является одним большим assembly это было бы накладно.

Можете подробнее раскрыть вопрос ?
Сейчас в общем то так и происходит. Байт код тащится на клиент. Отсюда появляются *.auc файлы на клиенте (в 3-ке были *.aoc файлы) в которых кешируется исполнимый p-код и, кстати, бывают проблемы с его обновлением.

Почему для .Net было не сделать также ? Были проблемы с "выдиранием" нужных кусков сборки и передачей их на клиент ?

[belugin]

Цитата:

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

Почему для .Net было не сделать также ? Были проблемы с "выдиранием" нужных кусков сборки и передачей их на клиент ?

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

[fed]

Кстати, еще году в 2007, во время очередной дискуссии по поводу перевода на C#, я спрашивал - а как в .net поддержать технологию слоев ? Пока никто не ответил... (Теоретически можно как-то статически собирать набор сборок из разных версий одного и того же объекта при компиляции, но как-то уж больно геморно это, да и может обычным C#овцам поломать совместимость).

[belugin]

Цитата:

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

Кстати, еще году в 2007, во время очередной дискуссии по поводу перевода на C#, я спрашивал - а как в .net поддержать технологию слоев ?

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

[Logger]

Цитата:

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

Кстати, еще году в 2007, во время очередной дискуссии по поводу перевода на C#, я спрашивал - а как в .net поддержать технологию слоев ? Пока никто не ответил... (Теоретически можно как-то статически собирать набор сборок из разных версий одного и того же объекта при компиляции, но как-то уж больно геморно это, да и может обычным C#овцам поломать совместимость).

Мне кажется что не должно быть проблем.
Это в Аксапте слой хранит и исходные тексты и байт код.

Но если задуматься - это лишнее. Достаточно по слоям держать исходный код, а работать будет сборка собранная компилятором. Она не обязана делиться по слоям.

Даже в X++ вы штатно не можете запустить код со слоя sys когда есть одноименный метод на usr. Есть обходной способ через получение доступа к исходному тексту и запуск runBuf. Но он будет работать и в случае .net

[ax_mct]

Peter Villadsen

7 Dec 2011
When to use Managed Code in Dynamics AX
http://blogs.msdn.com/b/x/archive/20...namics-ax.aspx

Цитата:

In general we do not try to compete with .NET functionality: Rather we leverage .NET and implement complimentary features for X++.

Blog posts activity
https://social.msdn.microsoft.com/Pr...adsen/activity

[ax_mct]

Сказанное в 2011 году Peter Villadsen

Цитата:

In general we do not try to compete with .NET functionality: Rather we leverage .NET and implement complimentary features for X++.

в статье When to use Managed Code in Dynamics AX
http://blogs.msdn.com/b/x/archive/20...namics-ax.aspx
вполне себе воплощается на практике. Нет никаких оснований прощаться с X++.
Вполне себе устойчивый и очевидный тренд. Особенно с учетом того что Peter Villadsen остается у руля как Program Manager at Microsoft in charge of X++ и его решение очевидно.

What's new for developers (Updated: December 13, 2013)
http://technet.microsoft.com/EN-US/l.../dn527218.aspx

What's New: X++ for Developers in Microsoft Dynamics AX 2012
http://technet.microsoft.com/en-us/l.../gg843765.aspx

What's new: MorphX features for developers
Updated: September 12, 2013
Applies To: Microsoft Dynamics AX 2012 R3
http://technet.microsoft.com/EN-US/l.../dn527172.aspx

Inside Microsoft Dynamics AX 2012 R3 (Published 8/14/2014)
https://www.microsoftpressstore.com/...-9780735685109
- Work with MorphX and avoid common pitfalls with X++ code

[ax_mct]

Для тех кто ищет куда свое образование засунуть

Peter Villadsen
November 2013

Mathematical modeling for AX (Microsoft.Solver.Foundation)
http://blogs.msdn.com/b/x/archive/20...erful-erp.aspx
Parent page - http://blogs.msdn.com/b/x/

[EVGL]

Цитата:

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

Для тех кто ищет куда свое образование засунуть

Peter Villadsen
November 2013

Mathematical modeling for AX (Microsoft.Solver.Foundation)
http://blogs.msdn.com/b/x/archive/20...erful-erp.aspx
Parent page - http://blogs.msdn.com/b/x/

Неплохо. Один из потенциальных клиентов хотел именно такого с расчетом минимального пути перевозки по карте.

[ax_mct]

Слои, AOT, MorthX это то что делает Аксапту Аксаптой (AX).
Убрать это значит зачистить AX. А несмертельно заменить X++ - невозможно.

Лично я ее люблю, мне ее жалко. А кому то там хочется чистоты расы и порядка.

[gl00mie]

Цитата:

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

Точно не знаю, вряд ли можно таскать netmodule отдельно от остальных частей сборки

Джеффри Рихтер в CLR via C# как раз пишет об этом, обсуждая многофайловые сборки (в вольном переводе):

Цитата:

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

Собственно, если посмотреть тем же Process Explorer'ом, какие сборки загружены AOS'ом вскоре после старта, то можно увидеть, что загружены лишь единицы или десятки из тысячи .netmodule'ей, составляющих сборку скомпилированного в CIL приложения Аксапты.
Что действительно нужно таскать всегда, так это файл с таблицами метаданных (manifest metadata tables), в данном случае - это файл Dynamics.Ax.Application.dll размером примерно в 1.5Mb.

[belugin]

Цитата:

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

Что действительно нужно таскать всегда, так это файл с таблицами метаданных (manifest metadata tables), в данном случае - это файл Dynamics.Ax.Application.dll размером примерно в 1.5Mb.

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

[Logger]

Цитата:

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

Джеффри Рихтер в CLR via C# как раз пишет об этом, обсуждая многофайловые сборки (в вольном переводе):Собственно, если посмотреть тем же Process Explorer'ом, какие сборки загружены AOS'ом вскоре после старта, то можно увидеть, что загружены лишь единицы или десятки из тысячи .netmodule'ей, составляющих сборку скомпилированного в CIL приложения Аксапты.

Денис, т.е. получается что ничего не мешает организовать такую подкачку на клиента а-ля auc файл ?

P.S.
Мне кажется должно быть штатное для .Net решение проблемы. Технология живет уже больше 10 лет. Пишутся сложные распределенные приложения. Так что аналогичные проблемы (с подтаскиванием кусков кода на клиент) должны были уже встречаться в куче проектов. Судя по всему процитированная особенность .Net и призвана решить эти вопросы.