PowerShell Runspace vs DLR

Question

Mit der jetzt verfügbaren .NET 4.0-Beta und damit der weiteren Verfügbarkeit der .NET Dynamic Language Runtime, werden diese Themen wohl "heißer" werden.

Ich bin verwirrt über die konzeptionellen Unterschiede zwischen DLR und PowerShell. Es scheint mir, dass ich, wenn ich Scripting-Fähigkeiten in meiner .NET-App bereitstellen möchte, den DLR verwenden kann (und damit die Skripterstellung in IronPython oder IronRuby oder andere für den DLR verfügbare Iron * -Sprachen aktiviert) oder eine PowerShell hosten kann Runspace.

Was sind die Vor- und Nachteile der einzelnen Methoden? Warum könnte ich eins über das andere wählen? Als dynamische Sprache selbst und eine erstklassige .NET-Sprache, warum zielt PowerShell nicht auch auf den DLR ab?

Answer 1

In .NET 4.0 besteht das DLR aus dem, was man als "DLR v1.0" bezeichnen kann. Dazu gehören der Call-Site-Caching-Mechanismus, die sprachübergreifenden Interop-Funktionen und die Verbesserungen der vorhandenen LINQ-Ausdrucksbäume. Dies sind alles Eigenschaften, die sehr nützlich sind, um eine Sprache zu implementieren, aber keine Sprache zu hosten.

Und das ist das fehlende Teil in DLR 1.0 - eine gemeinsame Hosting-Geschichte für alle Sprachen. Aber wir haben einen Anfang in Form der Hosting-APIs, die wir auf CodePlex w/DLR- und IronPython-Projekten und auch mit IronRuby auf Github bereitstellen. Leider dachten wir nicht, dass wir diese APIs im .NET 4.0-Zeitrahmen zur Schiffsqualität bringen könnten, also haben wir sie nicht aufgenommen. Insbesondere möchten wir mehr Feedback aus anderen Sprachen wie Powershell und sogar VB und C# erhalten, um sicherzustellen, dass wir die richtigen APIs haben.

Daher hat jede Sprache mehr oder weniger eine eigene Hosting-Geschichte mit Ausnahme von IronPython und IronRuby. Aber wir würden uns freuen, wenn all dies in Zukunft einheitlich wird, damit Ihre Benutzer auswählen können, welche Sprache sie verwenden möchten. Aber im Moment gibt es einfach nichts in der Box für Powershell zum Ziel.

Answer 2

Ich stimme zu, das DLR hat und wird weiterhin viele gute Diskussionen generieren. PowerShell ist nicht für das DLR ausgerichtet. Ich weiß nicht warum.

Das Hosting von PowerShell in einer .NET-App ermöglicht die PowerShell-Objektpipeline in der Scripting-Lösung, die meiner Meinung nach einen entscheidenden Vorteil darstellt.

Es gibt Beispiele für calling PowerShell from IronPython.

Sie können auch embed IronPython in PowerShell.

IronPython und IronRuby haben nicht die gleiche Integration in Windows wie PowerShell. Es wäre großartig, wenn PowerShell DLR-fähig wäre.

Answer 3

Doug's answer trifft ein paar wichtigen Punkte, aber ich denke, der Hauptgrund, Powershell als Scripting-Engine in einer .NET-Anwendung zu verwenden, ist die Tatsache, dass Powershell die Primär-Management-Oberfläche für Microsoft-Anwendungen immer und eine größere Vertrautheit unter genießen Systemadministratoren, die Ihre Anwendung pflegen.

IronPython und IronRuby (wie auch jede andere für das DLR bestimmte Sprache) werden dem Entwicklerpublikum wahrscheinlich bekannter sein.

Answer 4

Meine Annahme ist, Microsoft sollte ihre Backoffice-Managementschnittstellen basierend auf dem DLR entwickelt haben, damit erstklassige und bereits bewährte Sprachen wie Python und Ruby in .NET (oder jeder anderen auf dem DLR aufbauenden Sprache) könnten werden, im Gegensatz zu dem, was ich denke, haben sie das Rad mit Powershell neu erfunden. Außer seiner Verwendung zum Verwalten von Infrastrukturanwendungen, z.B.Austausch, ich habe keinen Anreiz, PowerShell zu lernen, wenn es bereits hervorragende Sprachen gibt. Meine 0,02 Cent.