Ограничения CLR Interop в DAX (4.0, 2009)

[alex55]

Смотрю сейчас тему интеграции DAX (4.0, 2009) с .NET, есть несколько вопросов:

1. Почему нельзя сделать так:

static void CLRInteropTest1(Args _args)
{
    System.DateTime clrDateTime;
    ;
    
    clrDateTime = new System.DateTime(); //Возникает исключение: "The class System.DateTime does not contain this function".
}

Это ограничение чего именно и чем вызвано?

System.DateTime clrDateTime; //C#

clrDateTime = new System.DateTime();

2. Сталкивался с тем, что при вызове .NET сборки (вероятно после возникновения исключения при ее выполнении) в DAX управление вообще не возвращалось даже в виде исключения, которое можно было бы обработать.. Что это могло быть и как с этим можно бороться?

3. Бонус. Этот пример только мне кажется странным?

    System.Int32 netInt = 2;
    int xppInt = 9;
    ;

// Marshal X++ to .NET.
    xppInt = 444;
    netInt = xppInt; // Marshals.
    if (444 == xppInt)
    {
        info("B1. Good, X++ was marshaled to .NET.");
    }
    else
    {
        info("B2. Bad, X++ was not marshaled to .NET.");
    }

http://msdn.microsoft.com/en-us/library/cc584291.aspx

[_scorp_]

1. Потому, что такого конструктора у структуры DateTime действительно нет.
2. Работа исключений в Dynamics AX для меня вообще загадка.
3. А что Вам тут кажется странным?

[alex55]

Цитата:

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

1. Потому, что такого конструктора у структуры DateTime действительно нет.
3. А что Вам тут кажется странным?

1.Спасибо за наводку. Порылся в доках, приведенный пример конструктора называется "конструктором по умолчанию" (http://msdn.microsoft.com/ru-ru/library/ms173115.aspx), видимо по этому он не включен в указанный список конструкторов .

Перефразирую вопрос №1 - "Есть ли в DAX эквивалент вызова конструктора по умолчанию для классов из .NET-сборок"?

3. Странно, что именно таким образом в примере проверяется корректность (или факт выполнения) маршалинга в .NET. То есть в netInt мы передали значение (допустим), а далее в условии проверяется исходное значение из X++. И, собственно, что можно таким образом проверить?)

[_scorp_]

Цитата:

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

1.Порылся в доках, приведенный пример конструктора называется "конструктором по умолчанию" (http://msdn.microsoft.com/ru-ru/library/ms173115.aspx)

Не совсем так. Это конструктор по умолчанию для ссылочных типов. DateTime является значимым типом. Для них другие правила. А конкретно для DateTime написано следующее:

Цитата:

Можно создать новое значение DateTime, используя один из следующих способов:
,,,
Путем вызова неявного конструктора по умолчанию структуры DateTime. (Дополнительные сведения о неявном конструкторе по умолчанию типа значения см. в разделе Типы значений (Справочник по C#).) Приблизительный аналог, который поддерживается компиляторами, — объявить значение DateTime без явного присвоения даты и времени.

Т.е. вызов конструктора по умолчанию структуры DateTime это возможность компилятора, а так как в Dynamics AX нет компилятора .NET, а есть только возможность использовать уже скомпилированные сборки, то отсюда и возникает ошибка.

Цитата:

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

3. Странно, что именно таким образом в примере проверяется корректность (или факт выполнения) маршалинга в .NET. То есть в netInt мы передали значение (допустим), а далее в условии проверяется исходное значение из X++. И, собственно, что можно таким образом проверить?)

Да, действительно. Первый раз невнимательно просмотрел пример . Тоже непонимаю смысл...

[alex55]

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

То есть использовать конструкции вроде такой не получится:

textBox1.Text = System.DateTime.Now.Ticks.ToString();

Может есть альтернативный синтаксис, позволяющий достучаться до свойств?

[_scorp_]

Цитата:

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

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

То есть использовать конструкции вроде такой не получится:

textBox1.Text = System.DateTime.Now.Ticks.ToString();

Может есть альтернативный синтаксис, позволяющий достучаться до свойств?

Альтернативный синтаксис есть. Свойства .NET объекта в Dynamics AX представляются парой методов get_PropertyName и set_PropertyName. Причем, можно обратить внимание на то, что этих методов нет в описании объекта в MSDN и даже в Object Brouser Visual Studio. Эти методы, как я понимаю, генерирует сама DAX в качестве обертки над .NET объектом. И начинаются эти методы с маленькой буквы, хотя в .NET принято чтобы методы начинались с заглавных букв.



Вот пример. AX 4.0.

Условие: Убедитесь в том, что сборка с которой Вы собираетесь работать загружена в References Dynamics AX.

static void useNetProperties(Args _args)
{
    System.Data.DataSet netDataSet;
    str                 xppStr;
    ;
    netDataSet = new System.Data.DataSet();
    netDataSet.set_DataSetName("this DataSet name");
    xppStr = netDataSet.get_DataSetName();
    info(xppStr);
}

[alex55]

Цитата:

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

Альтернативный синтаксис есть. Свойства .NET объекта в Dynamics AX представляются парой методов get_PropertyName и set_PropertyName. Причем, можно обратить внимание на то, что этих методов нет в описании объекта в MSDN и даже в Object Brouser Visual Studio. Эти методы, как я понимаю, генерирует сама DAX в качестве обертки над .NET объектом.

Спасибо, полезная инфа. А данная фича где-то описана?

[jonny]

Цитата:

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

Причем, можно обратить внимание на то, что этих методов нет в описании объекта в MSDN и даже в Object Brouser Visual Studio. Эти методы, как я понимаю, генерирует сама DAX в качестве обертки над .NET объектом. И начинаются эти методы с маленькой буквы, хотя в .NET принято чтобы методы начинались с заглавных букв.

Аксапта не генерит обертки, а честно берет названия методов из CIL кода .net объектов.