PowerShell Runspace против DLR

Теперь, когда бета-версия .NET 4.0 доступна и, следовательно, более широкая доступность .NET Dynamic Language Runtime, я думаю, что такие темы станут "более горячими".

Я смущен концептуальными различиями между DLR и PowerShell. Мне кажется, что если я хочу предоставить возможности сценариев в своем приложении .NET, я могу использовать DLR (и, таким образом, включить скрипты в IronPython или IronRuby или любые другие языки Iron * для DLR) или разместить PowerShell пространство выполнения.

Каковы плюсы и минусы каждого метода? Почему я могу выбрать один за другим? Как сам динамический язык и первоклассный .NET-язык, почему PowerShell не нацелен на DLR?

Ответ 1

В .NET 4.0 DLR состоит из того, что вы можете рассматривать "DLR v1.0". Это включает в себя механизм кэширования сайта вызова, межъязыковые посредники и улучшения существующих деревьев выражений LINQ. Это все функции, которые очень полезны для реализации langauge, но не для размещения языка.

И что недостающая часть в DLR 1.0 - общая история размещения для всех языков. Но мы начинаем с того, что в форме API-интерфейсов хостинга мы отправляем проекты CodePlex с DLR и IronPython, а также с IronRuby на github. К сожалению, мы не думали, что мы можем использовать эти API для обеспечения качества корабля в таймфрейме .NET 4.0, поэтому мы не включили их. В частности, мы хотим получить больше отзывов от других языков, таких как Powershell и даже VB и С#, чтобы убедиться, что у нас есть правильные API.

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

Ответ 2

Я согласен, DLR имеет и будет продолжать генерировать массу хороших обсуждений. PowerShell не предназначен для DLR. Однако я не знаю, почему.

Хостинг PowerShell в приложении .NET позволяет конвейер объектов PowerShell в решении сценариев, которое, по моему мнению, является одним из ключевых преимуществ.

Есть примеры вызова PowerShell из IronPython.

Вы также можете встроить IronPython в PowerShell.

IronPython и IronRuby не имеют такой же интеграции с Windows, как и PowerShell. Было бы здорово, если бы PowerShell был включен DLR из коробки.

Ответ 3

Ответ Doug показывает несколько ключевых моментов, но я думаю, что основной причиной использования PowerShell в качестве механизма сценариев в приложении .NET является тот факт, что PowerShell становится основной поверхности управления в приложениях Microsoft и будет пользоваться большей известностью среди системных администраторов, которые поддерживают ваше приложение.

IronPython и IronRuby (а также любые другие языки, предназначенные для DLR), скорее всего, будут более известны аудитории разработчиков.

Ответ 4

Я считаю, что Microsoft должна была разработать свои интерфейсы управления Backoffice на основе DLR, поэтому первоклассные и уже проверенные языки, такие как Python и Ruby в .NET(или любой другой язык, построенный на DLR), могут быть в отличие от того, что я думаю, что они сделали, изобретая колесо с Powershell. Помимо его использования для управления приложениями инфраструктуры, например, Exchange, у меня нет стимула изучать Powershell, когда есть отличные языки уже там. Мои 0,02 цента.