PowerShell Runspace vs DLR

Question

Con la versione beta .NET 4.0 ora disponibile, e quindi la più ampia disponibilità del. NET Dynamic Language Runtime, credo che questi tipi di argomenti diventeranno "più caldi".

Sono confuso circa le differenze concettuali tra DLR e PowerShell. Mi sembra che se voglio fornire funzionalità di scripting nella mia app .NET, posso usare il DLR (e quindi abilitare lo scripting in IronPython o IronRuby, o qualsiasi altra lingua Iron * disponibile per il DLR), o ospitare un PowerShell spazio di esecuzione.

Quali sono i pro e i contro di ciascun metodo? Perché potrei sceglierne uno rispetto all'altro? Essendo un linguaggio dinamico e un linguaggio .NET di prima classe, perché PowerShell non si rivolge anche al DLR?

Answer 1

In .NET 4.0 il DLR è costituito da ciò che è possibile considerare "DLR v1.0". Ciò include il meccanismo di memorizzazione nella cache del sito di chiamata, i parametri di interoperabilità tra più lingue e i miglioramenti agli alberi di espressione LINQ esistenti. Queste sono tutte caratteristiche che sono molto utili per implementare una lingua ma non per ospitare una lingua.

E questo è il pezzo mancante in DLR 1.0 - una storia di hosting condiviso per tutte le lingue. Ma abbiamo un inizio su questo nella forma delle API di hosting che distribuiamo su CodePlex con i progetti DLR e IronPython e anche con IronRuby su github. Sfortunatamente non pensavamo di poter guidare queste API per la qualità della spedizione nel timeframe di .NET 4.0, quindi non le abbiamo incluse. In particolare vogliamo ottenere più feedback da altre lingue come Powershell e persino VB e C# per assicurarci di avere le API giuste.

Pertanto, ogni lingua ha più o meno la sua storia di hosting ad eccezione di IronPython e IronRuby in questo momento. Ma ci piacerebbe vedere tutto questo unificato in futuro in modo che i tuoi utenti possano scegliere quale lingua usare. Ma al momento non c'è solo qualcosa nella scatola che Powershell abbia come target.

Answer 2

Sono d'accordo, il DLR ha e continuerà a generare molte buone discussioni. PowerShell non è destinato al DLR. Non so perché però.

Hosting PowerShell in un'app .NET consente la pipeline di oggetti PowerShell nella soluzione di scripting che credo sia uno dei principali vantaggi.

Esistono esempi di calling PowerShell from IronPython.

È inoltre possibile embed IronPython in PowerShell.

IronPython e IronRuby non hanno la stessa integrazione con Windows di PowerShell. Sarebbe bello se PowerShell fosse DLR abilitato fuori dalla scatola.

Answer 3

Doug's answer colpisce alcuni punti chiave, ma penso che il motivo principale per utilizzare PowerShell come motore di scripting in un'applicazione .NET sia il fatto che PowerShell sta diventando la superficie di gestione principale tra le applicazioni Microsoft e godrà di una maggiore familiarità tra amministratori di sistema che gestiscono la tua applicazione.

IronPython e IronRuby (così come qualsiasi altra lingua destinata al DLR) rimarranno probabilmente più familiari al pubblico degli sviluppatori.

Answer 4

La mia opinione su questo è, Microsoft avrebbe dovuto sviluppare le loro interfacce di gestione Backoffice basate sul DLR, in modo che linguaggi di prima qualità e già collaudati come Python e Ruby in .NET (o qualsiasi altro linguaggio costruito sul DLR) potrebbero essere sfruttato, al contrario di quello che penso abbiano fatto nel reinventare la ruota con Powershell. Oltre al suo utilizzo per gestire le applicazioni di infrastruttura, ad es.Scambio, non ho un incentivo per imparare Powershell quando ci sono già lingue eccellenti là fuori. I miei .02 centesimi.