C# scripts using DynamicMethod
Плюсы вижу — первый вызов метода будет происходить значительно быстрее, чем при использовании CSharpCodeProvider.

А какие у этого метода недостатки?

Здравствуйте, alvas, Вы писали:

A>C# scripts using DynamicMethod
A>Плюсы вижу — первый вызов метода будет происходить значительно быстрее, чем при использовании CSharpCodeProvider.

A>А какие у этого метода недостатки?

Я бы проверил что класс Script не будет производить компиляцию при каждом вызове метода Run и что класс кэширует скомпилированную сборку внутри себя. Комплияция в данном случае будет занимать разы больше веремени чем исполнение скрипта.

Мы в своём проекте активно используем CS Script ( http://www.csscript.net/ ) и очень довольны. Явно компилируем assembly из скрипта. Затем вызываем нужный статический метод из этой скомпилированной сборки.

Здравствуйте, 4izh, Вы писали:

4>Здравствуйте, alvas, Вы писали:

A>>C# scripts using DynamicMethod
A>>Плюсы вижу — первый вызов метода будет происходить значительно быстрее, чем при использовании CSharpCodeProvider.

A>>А какие у этого метода недостатки?

4>Я бы проверил что класс Script не будет производить компиляцию при каждом вызове метода Run и что класс кэширует скомпилированную сборку внутри себя. Комплияция в данном случае будет занимать разы больше веремени чем исполнение скрипта.

4>Мы в своём проекте активно используем CS Script ( http://www.csscript.net/ ) и очень довольны. Явно компилируем assembly из скрипта. Затем вызываем нужный статический метод из этой скомпилированной сборки.

Расскажите про недостатки/ограничения. Может ли скрипт работать изолированно в отдельном домене и т.д. и т.п.
В общем какие подводные камни?

Здравствуйте, alvas, Вы писали:

A>В общем какие подводные камни?

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

Здравствуйте, hardcase, Вы писали:

H>Здравствуйте, alvas, Вы писали:

A>>В общем какие подводные камни?

H>Если запускается много одноразовых скриптов, то врукопашную скомпилированные сборки так и остаются в памяти (фактически мусором). Выгрузить их можно лишь выгрузив домен. Часто создавать домены также не здорово — это сравнительно медленная операция.

Это ты про DynamicMethod? В msdn черным по белому написано что код сгенерированный DynamicMethod доступен сборщику мусора. Могу ссылку дать. Врут?

Здравствуйте, alvas, Вы писали:

H>>Если запускается много одноразовых скриптов, то врукопашную скомпилированные сборки так и остаются в памяти (фактически мусором). Выгрузить их можно лишь выгрузив домен. Часто создавать домены также не здорово — это сравнительно медленная операция.

A>Это ты про DynamicMethod? В msdn черным по белому написано что код сгенерированный DynamicMethod доступен сборщику мусора. Могу ссылку дать. Врут?

Я имел в виду вызов компилятора C#. С DynamicMethod как раз все гораздо лучше — начиная с .NET 4.0 анонимные сборки где он объявлен могут быть выгружены за ненадобностью.

Здравствуйте, hardcase, Вы писали:

H>Я имел в виду вызов компилятора C#. С DynamicMethod как раз все гораздо лучше — начиная с .NET 4.0 анонимные сборки где он объявлен могут быть выгружены за ненадобностью.

Может запутанно выразился

Вижу плюсы DynamicMethod — первый вызов метода будет происходить значительно быстрее, чем при использовании CSharpCodeProvider.
Может еще есть?

Какие подводные камни при использовании DynamicMethod?

Если ты не против можем продолжить в скайпе.