Прощай, X++

[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

[belugin]

Цитата:

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

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

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

[Logger]

Цитата:

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

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

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

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

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

[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 и призвана решить эти вопросы.

[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]

Now serving at Microsoft's Redmond campus as the program manager for a team dedicated to the development of the X++ language and its tools, and to charting its future in a managed world.

[ax_mct]

Цитата:

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

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

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

Еще в 2003 году была ClickOnce и вроде бы есть и сейчас
"automatically updated as needed from a central location"
http://msdn.microsoft.com/en-us/library/ms996413.aspx

Судя по всему и осталась
http://msdn.microsoft.com/en-us/libr...v=vs.120).aspx

Вот пример интересный "Auto-Deploying Windows Forms .NET Applications"
http://www.codemag.com/Article/0307061

C уважением, ваш Early Archiver MCSD for .NET (C#) 2003 года

[Logger]

Интересная ссылка в тему
mfp: Garbage Collection and RPC calls in X++
http://blogs.msdn.com/b/mfp/archive/...alls-in-x.aspx

Видимо, это одна из причин, мешающих уйти от X++ на C#
По этой же причине, похоже, не поддерживается передача .Net объектов между клиентом и сервером по ссылке. - Нереализована сборка мусора для таких случаев.

P.S.
Радует что пофиксили SysOperationProgress.

[ax_mct]

Цитата:

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

Интересная ссылка в тему
mfp: Garbage Collection and RPC calls in X++
http://blogs.msdn.com/b/mfp/archive/...alls-in-x.aspx

Видимо, это одна из причин, мешающих уйти от X++ на C#
По этой же причине, похоже, не поддерживается передача .Net объектов между клиентом и сервером по ссылке. - Нереализована сборка мусора для таких случаев.

P.S.
Радует что пофиксили SysOperationProgress.

Причина того что X++ жив возможно в том что здравый смысл иногда побеждает как это было на днях в Шотландии. Красивые идеи и здравый смысл они редко рядом.

Пофиксили да судя по всему только в AX2012 R3.

Понятно что чем меньше RPC calls тем лучше и исполнение максимально на одной стороне держать надо. Но вот насколько это заметно для пользователя и загрузки AOS? Если незаметно и непоказательно то заставить кого-то программировать с минимизацией этих программных вызовов - невозможно в моей реальности, просто не поймут.

[perestoronin]

Цитата:

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

X++ жив

лишь по одной причине: в 1998 году не было в помине scala (появилась в:2003).
Если не расширять X++ или не заменить X++ на C#v6.0, то вполне ожидаемо появление новой разработки другого разработчика, и вполне возможно именно на scala.

После перехода на C# нет никаких преград для использования в DAX scala, т.к.:

Цитата:

На текущий момент Scala реализована на платформах Java и .NET.

[ax_mct]

Цитата:

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

лишь по одной причине: в 1998 году не было в помине scala (появилась в:2003).
Если не расширять X++ или не заменить X++ на C#v6.0, то вполне ожидаемо появление новой разработки другого разработчика, и вполне возможно именно на scala.

После перехода на C# нет никаких преград для использования в DAX scala, т.к.:

Для Visual Studio как среды программирования преград нет, а для DAX как среды исполнения и как приложения - очень даже есть.

"новой разработки другого разработчика" - ERP на Scala? Так не IT (программисты) выбирают а бизнес. И слава богу что их не волнует ни разу что какой-то язык программирования более "rock" как та жа Scalа. Иначе бы за еду программировали.

Почему PHP самый по сути популярный язык в web бизнес-приложениях и позиций не сдает (и не сдаст никогда) более "совершенным" Python или Perl ( об ASP.NET как полном совершенстве помолчу )? Вполне себе аналогия так как PHP - "гавно" тока никак почему то не тонет

PHP на рынке. X++ в AX. Причины одинаковы - капитализм

http://en.wikipedia.org/wiki/Compari...ion_frameworks

http://en.wikipedia.org/wiki/List_of...tware_packages

[ax_mct]

https://www.udemy.com/blog/modern-language-wars/

[Logger]

Я думаю вы обсуждаете маловажные вещи.
Гораздо важнее прикладной функционал которые создается на платформе DAX. Для удовлетворения нужд клиентов достаточно X++ в том виде как он есть на ax2009. Он не сдерживает развитие системы.
Вот если завтра MS подпрыгнет и выпустит мегаобновление, благодаря которому резко упадет необходимость в доработках - только настройки делай - вот это будет шаг вперед. Никто и не спросит - чего там у Аксапты под капотом, C#, X++ или Кобол.

[macklakov]

Цитата:

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

Вот если завтра MS подпрыгнет и выпустит мегаобновление, благодаря которому резко упадет необходимость в доработках - только настройки делай - вот это будет шаг вперед. Никто и не спросит - чего там у Аксапты под капотом, C#, X++ или Кобол.

Вот в том и проблема, что с использованием CIL, WCF, WF и прочих делегатов, в AX понаваяли какое-то зашкаливающее количество глюков.
На той неделе попытался использовать стандартный импорт Bank Statement, сделанный через AIF. Это шедеврально. Там есть почти все, и XSLT и исполнение в CIL и делегаты и дизайн-патерны. Только вот работать с ним невозможно. И починить получается на порядок сложнее, чем написать с нуля свой импорт. По какой-то парадоксальной причине изысканность и обилие использовуемых инструментов ухудшило читаемость кода и его надежность.
Т.е. качество на уровне АвтоВАЗ традиционно, конечно. Свежеинстоллированную систему всегда нужно было чинить. Но вот в последней версии это гораздо сложнее делать стало. Может это просто совпадение. Но .Net в AX теперь прочно ассоциируется с глюками, которые крайне сложно отлаживать.

[fed]

Цитата:

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

Вот если завтра MS подпрыгнет и выпустит мегаобновление, благодаря которому резко упадет необходимость в доработках - только настройки делай - вот это будет шаг вперед.

Боюсь что время сэкономленное на доработках будет с лихвой перкрыто временем потраченым на возню в добавленных настройках и попытках протрассировать - как же получившееся глюкало работает...
Ну то есть - сложность системы неустранима, есть некий баланс между сложностями доработки и сложностями настройки. Уменьшение затрат на доработку автоматически приводит к увеличению затрат на настройку. Есть точка оптимума, после достижения которой снижение затрат на доработку начинает перекрываться увеличением затрат на настройку.

И есть сильнейшее подозрение что MS этого не понимает... Хотя в маркетинге они много говорят о более низкой TCO чем у SAP, на практике - большая часть нового функционала в очередной версии не снижает, а увеличивает TCO. В результате мы рискуем получить через 3-4 версий Dynamics AXAP - в прикладном смысле тяжелый в настроке как SAP, но при этом со всеми глюками и рисками порожденными микрософтовской гонкой технологий.