.Net

Уважаемые, с чего начать изучение функционала .Net в аксапте?

Я так понимаю, язык , начиная с 4-ки , уже интегрирован в морфикс. Но, предполагаю, что базовая для аксапты сборка серьезно ограничена.

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

[Logger]

Зачем вам это если скоро будет крах MS ?

[jonny]

В Аксапту встроена возможность использования классов из .Net (CLR) сборок.
Возможности этой связки довольно ограниченны и описаны тут
http://msdn.microsoft.com/en-us/library/cc598160.aspx

Ну, соответственно, нужно так же разбираться в библиотеке классов .NET, которая растет от версии к версии.

[Poleax]

Цитата:

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

Уважаемые, с чего начать изучение функционала .Net в аксапте?

Может достаточно начать изучать C# 2010 и платформа .NET 4 с учетом, что Dynamics Ax 2012 совместим с Visual Studio 2010 и .NET 4.

P.S. Есть интересная стать Developing Applications for Microsoft Dynamics AX with X++ and the .NET Framework

2 Logger
Вы невнимательно читали мой док по трендам развития ИТ или вообще не читали.
Кратко: MS и софт, который она разработала на текущий момент - не одно и то же.

Ребятам спасибо, акцентироваться буду на 4-ке и 2009-ой. Не верю что-то в 2012...

[greench]

Цитата:

Сообщение от Poleax;241681 [URL="http://www.ozon.ru/context/detail/id/5602592/"

C# 2010 и платформа .NET 4[/URL]

Да, Троелсен любитель писать талмуды на 1000+ страниц

я правильно понимаю, что подсказок-описаний нэймспейсов-класcов-сборок в морфиксе нет и нужно все держать в памяти?

[belugin]

В 2009, насколько я помню, внутри неймспейсов подсказываются. То есть после набирания System. будет выведено меню поднеймспейсов и классов.

Только не забудьте добавить нужную вам сборку в references, если она еще не там (или не общедоступна).

не имею 2009 сейчас: что такое 'references' ?

Я так понял, что .Net частью операционки сделали как раз для прозрачности использования... Отсюда вроде как установленное в операционке должно 'увидеться' во всех MS-ых IDEs.

[belugin]

References, это узел в AOT

Есть разные способы использованиия сборок, прочитайте про GAC прочее

[gl00mie]

Цитата:

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

Может достаточно начать изучать C# 2010 и платформа .NET 4 с учетом, что Dynamics Ax 2012 совместим с Visual Studio 2010 и .NET 4.

Что в данном случае означает "совместима с .NET4"? То, что в ядре, наконец, начали использовать именно 4-ю, а не 2-ю версию CLR и, соотв., .NET Framework? И что все свои сборки, собранные для использования с той же 2009-й под .NET Framework 2.0, надо будет пересобирать под 4.0?

Цитата:

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

Ребятам спасибо, акцентироваться буду на 4-ке и 2009-ой. Не верю что-то в 2012...

Нужно лишь учесть, что в этих версиях ядро работает с CLR и .NET Framework версии 2.0, поэтому на все вкусности более новых версий остается лишь пускать слюни. Насколько я знаю, CLR более старой версии не может загружать сборки, предназначенные для более новой CLR и .NET Framework (3.5, 4.0); все сборки, идущие в поставке той же 2009-й, собранны именно под .NET Framework 2.0.

Цитата:

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

я правильно понимаю, что подсказок-описаний нэймспейсов-класcов-сборок в морфиксе нет и нужно все держать в памяти?

Подсказки есть, когда идет выбор вложенного namespace'а/класса/метода/etc (условно говоря, после набора точки или ::). Для уже набранного кода Ctrl-Space на идентификаторе, в отличие от кода Х++, уже ничего не показывает.

PS. В качестве отправной точки для понимания того, что такое GAC, чем CLR отличается от .NET Framework и прочее, могу посоветовать замечательную книгу Джеффри Рихтера CLR via C# (ISBN 9785750203482 для русского издания).

[jonny]

Ничто не мешает держать одновременно несколько версий Framework, не нужно ничего переписывать под 4.0

AX 2009 прекрасно использует сборки из 3.5-й версии, достаточно того, чтобы она была установлена и нужные сборки были добавлена в references, тут
XML
есть пример использования XLINQ из версии 3.5

[greench]

Цитата:

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

не имею 2009 сейчас: что такое 'references' ?

В четверке тоже есть такое узел. Как подключать .Net сборки описано в одном из тренингов для девелоперов.

В качестве пособия для изучения C# +1 к Рихтеру.

не дочитал еще, но уже начали глодать смутные сомнения:

1. Совместное использование нескольких языков программирования (те, что managed) насколько реально востребовано и используется?

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

В связи с этим вопрос: насколько удобство использования нескольких языков перевешивает тормознутость разработки и исполнения?

Вопрос не в плане аксапты, а в плане чистого .Net.

Хотя и в плане аксапты можно прокомментить.

[_scorp_]

Цитата:

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

1. Совместное использование нескольких языков программирования (те, что managed) насколько реально востребовано и используется?

Если Вы будете вести расчет какого-нибудь атомного реактора, и найдется "managed" язык более выразительный или удобный для ведения таких расчетов, чем C#, то почему бы этим языком не пользоваться. Тогда как GUI писать на C#.

Цитата:

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

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

В связи с этим вопрос: насколько удобство использования нескольких языков перевешивает тормознутость разработки и исполнения?

Про тормознутость разработки не понял, что имеется ввиду. А про исполнение...Что-то Вы не то читаете, начните с Рихтера которого Вам тут уже неоднократно советовали. Вот что он пишет про "тормознутость" :

Цитата:

Разработчики с опытом программирования на неуправляемых C/C++ наверняка
заинтересуются, как это сказывается на производительности. В конце концов,
неуправляемый код компилируется для конкретного процессора и при вызове
просто исполняется. В управляемой же среде компиляция производится в два этапа.
Сначала компилятор проходит исходный код и переводит его в IL. Но для испол
нения сам ILкод нужно перевести в машинные команды в период выполнения,
что требует дополнительной памяти и процессорного времени.
Поверьте: я сам из тех, кто программирует на C/C++, и, переходя на CLR, я до
статочно скептически рассматривал все эти дополнительные издержки. Вторая
стадия компиляции, имеющая место в период выполнения, снижает скорость и
требует дополнительной динамической памяти — с этим не поспоришь. Однако
Microsoft проделала большую работу, чтобы свести эти издержки к минимуму
Трудно поверить, но многие (включая меня) считают, что управляемые при
ложения могут работать производительнее неуправляемых, и тому есть масса
причин. Взять хотя бы тот факт, что превращая ILкод в команды процессора в
период выполнения, JITкомпилятор располагает более полными сведениями о
среде выполнения, чем компилятор неуправляемого кода. Вот особенности, ко
торые позволяют управляемому коду «опередить» неуправляемый.
 JITкомпилятор может обнаружить факт выполнения приложения на Pentium 4
и сгенерировать машинный код, полностью использующий все преимущества
особых команд этого процессора. Неуправляемые приложения обычно ком
пилируют в расчете на среднестатистический процессор, избегая специ
фических команд, которые заметно повышают производительность приложе
ния на новейших процессорах.
 JITкомпилятор может обнаружить, что определенное выражение на конкрет
ной машине всегда равно false. Например, посмотрим на метод с таким кодом:
if (numberOfCPUs > 1) {
...
}
Здесь numberOfCPUs — число процессоров. Код указывает JITкомпилято
ру, что для машины с одним процессором не нужно генерировать никаких
машинных команд. В этом случае машинный код оптимизирован для конкрет
ной машины: он короче и выполняется быстрее.
 CLR может проанализировать выполнение кода и перекомпилировать ILкод в
команды процессора во время выполнения приложения. Перекомпилирован
ный код может реорганизовываться с учетом обнаруженных некорректных
прогнозов ветвления.
Это лишь малая часть аргументов в пользу того, что управляемый код будуще
го будет исполняться лучше сегодняшнего неуправляемого. Как я сказал, произ
водительность и сейчас очень неплохая для большинства приложений, а со вре
менем ситуация только улучшится.
Если ваши эксперименты покажут, что JITкомпилятор CLR не обеспечивает
нужную производительность, рекомендую воспользоваться утилитой NGen.exe,
поставляемой с .NET Framework SDK. NGen.exe компилирует весь ILкод выбран
ной сборки в машинный и сохраняет его в дисковом файле. При загрузке сборки
в период выполнения среда CLR автоматически проверяет наличие предварительно
скомпилированной версии сборки и, если она есть, загружает скомпилированный
код, так что компиляция в период выполнения не производится. Заметьте, что
NGen.exe не ориентируется на конкретную среду выполнения и генерирует код
для среднестатистической машины; по этой причине созданный утилитой код не
столь оптимизирован, как произведенный JITкомпилятором.

[belugin]

Цитата:

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

1. Совместное использование нескольких языков программирования (те, что managed) насколько реально востребовано и используется?

Я встречал жизнеспособные варианты:

1.С++/Cli - есть специальный диалект С++, который является одновременно Managed языком - можно использовать наработанные библиотеки X++, а в результате получаются .NET классы. Я когда-то писал плагин для фара по такой схеме (сейчас другие люди рзрабатывают).

2. PowerShell - на шелле удобно работать с файлами, блгодаря шелльному синтаксису. При этом можно использовать весь .NET фреймворк.Иногда даже в шелльные скрипты вставляют кусочки на C# при помощи Add-Type

3. Вообще когда удобно работать на другом языке билиотеки в-основном есть на C#. Многие предпочитают VB.NET из-за опыта в бейские, есть F#, который содержит паттерн матчинг и контроль едини измерения

Цитата:

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

В связи с этим вопрос: насколько удобство использования нескольких языков перевешивает тормознутость разработки и исполнения?

Вопрос не в плане аксапты, а в плане чистого .Net.

Смотря для чего.

Цитата:

Хотя и в плане аксапты можно прокомментить.

.NET с нормальным GC и JIT гораздо быстрее чем X++. Еще есть богатый фреймфорк, который удобно использовать, если надо чего-то особенного.

2 _scorp_

Как раз Рихтера и читаю.

Цитата:

"managed" язык более выразительный или удобный для ведения таких расчетов, чем C#, то почему бы этим языком не пользоваться. Тогда как GUI писать на C#.

Так С# - это самый что ни на есть "managed" язык. А ГУИ Рихтер советует писать на VB.

Про "тормознутость" разработки: нужно все контролировать без помощи компилятора, переписывать базовые классы/методы, прописывать "линейки" конструкторов и др методов, предназначенных для одного и того же и проч, проч, проч. Это все из Рихтера, кстати.

Вы сами его внимательно читали?

Прошу подключаться к дискуссии практиков.

2 belugin

Цитата:

.NET с нормальным GC и JIT

что такое "нормальный"?

[belugin]

Цитата:

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

что такое "нормальный"?

Как у всех - недетерменированный, в отличии от X++ где для того, чтобы освобождать память сразу после потери ссылки, приходится постоянно бегать по связям.

[belugin]

Вот это я не понял, это про что:

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

можете разжевать?