Ich habe mit einer c # -App gespielt, die IronPython, IronRuby und (hoffentlich) PowerShell hostet. Da IronPython und IronRuby vollständig auf dem DLR aufgebaut sind, ist die API für deren Verwendung nahezu identisch.
%Vor%und
%Vor%beide erstellen Instanzen einer Microsoft.Scripting.Hosting.ScriptEngine . Gibt es eine Hoffnung, PowerShell 3.0 zum Erstellen einer ScriptEngine zu zwingen? Ich konnte bisher nicht viel zu dem Thema finden, außer PowerShell 3.0 scheint auf der DLR mehr gebaut zu sein als die vorherige Version (siehe Ссылка .
Es sieht nicht so aus, als könnten Sie eine PowerShell-Engine, die mit folgendem erstellt wurde, in eine ScriptEngine umwandeln:
%Vor%Ich vermute, dass, wenn ich PowerShell über die gleiche API wirklich behandeln will, ich meine eigene ScriptEngine erstellen muss, die den PowerShell-Host umschließt.
PowerShell V3 verwendet tatsächlich einige der DLR, aber nur Teile, die in den .Net Frameworks V4 ausgeliefert wurden. Das DLR-Projekt hatte viele nützliche Apis, die nicht in .Net enthalten waren, z. Microsoft.Scripting.Hosting.ScriptEngine.
Wenn PowerShell die ScriptEngine-API implementieren wollte, musste PowerShell diese API als Teil von PowerShell bereitstellen. Das PowerShell-Team wollte diese Apis nicht übernehmen.
Sie haben also richtig angenommen, dass Sie PowerShell mit Ihrem eigenen Code umbrechen müssen, wenn Sie ScriptEngine implementieren möchten.
PowerShell funktioniert mit Dotnet-Assembly und ist sehr interessant, wenn Sie ein Administratorprofil haben und Sie möchten erweiterte Anweisungen erstellen. Aber Sie sind ein Entwickler, also, warum PowerShell umhüllen, können Sie auf alle dotnet Assembly von Ihrem Code zugreifen. Es ist besser zu Code, was Sie wollen, anstatt PowerShell zu umhüllen Beste Meinung
Tags und Links c# powershell dynamic-language-runtime powershell-v3.0