PowerShell Runspace vs DLR

Question

Con el .NET 4.0 beta ahora disponible, y por lo tanto la disponibilidad más amplia de .NET Dynamic Language Runtime, creo que este tipo de temas se volverán "más candentes".

Estoy confundido acerca de las diferencias conceptuales entre el DLR y PowerShell. Me parece que si quiero proporcionar capacidades de scripting en mi aplicación .NET, puedo usar el DLR (y así habilitar el scripting en IronPython o IronRuby, o cualquier otro idioma de Iron * disponible para el DLR), o alojar un PowerShell Runspace.

¿Cuáles son los pros y los contras de cada método? ¿Por qué podría elegir uno sobre el otro? Como un lenguaje dinámico en sí mismo, y un lenguaje .NET de primera clase, ¿por qué PowerShell tampoco se dirige al DLR?

Answer 1

En .NET 4.0, el DLR consiste en lo que puede considerar "DLR v1.0". Esto incluye el mecanismo de almacenamiento en caché del sitio de llamada, las características de interoperación de lenguaje cruzado y las mejoras en los árboles de expresión LINQ existentes. Estas son todas las características que son muy útiles para implementar un lenguaje pero no para alojar un idioma.

Y esa es la pieza que falta en DLR 1.0: una historia de alojamiento compartido para todos los idiomas. Pero tenemos un comienzo en la forma de las API de alojamiento que enviamos en proyectos CodePlex w/DLR e IronPython y también w/IronRuby en github. Lamentablemente, no creímos que pudiéramos impulsar estas API a la calidad del envío en el marco de tiempo de .NET 4.0, por lo que no las incluimos. En particular, queremos obtener más comentarios de otros idiomas como Powershell e incluso VB y C# para asegurarnos de tener las API adecuadas.

Por lo tanto, cada idioma más o menos tiene su propia historia de hosting a excepción de IronPython y IronRuby en este momento. Pero nos encantaría ver que todo esto se unifique en el futuro para que los usuarios puedan elegir qué idioma usar. Pero en este momento simplemente no hay algo en la caja para que Powershell apunte.

Answer 2

Estoy de acuerdo, el DLR ha generado y seguirá generando mucha discusión. PowerShell no está dirigido para el DLR. No obstante, no sé por qué.

Alojamiento PowerShell en una aplicación .NET habilita la canalización de objetos de PowerShell en la solución de scripting, que creo que es una ventaja clave.

Hay ejemplos de calling PowerShell from IronPython.

También puede embed IronPython in PowerShell.

IronPython y IronRuby no tienen la misma integración en Windows que PowerShell. Sería genial si PowerShell fuera DLR habilitado de fábrica.

Answer 3

Doug's answer coincide con algunos puntos clave, pero creo que la razón principal para utilizar PowerShell como motor de scripts en una aplicación .NET es el hecho de que PowerShell se está convirtiendo en la superficie de administración principal de las aplicaciones de Microsoft y disfrutará de una mayor familiaridad administradores de sistemas que mantienen su aplicación.

IronPython y IronRuby (así como cualquier otro lenguaje destinado al DLR) probablemente seguirán siendo más familiares para la audiencia de desarrolladores.

Answer 4

Mi opinión sobre esto es que Microsoft debería haber desarrollado sus interfaces de gestión de Backoffice basadas en DLR, de modo que los lenguajes de primera calidad y ya probados como Python y Ruby en .NET (o cualquier otro lenguaje construido en DLR) pudieran ser apalancado, a diferencia de lo que creo que hicieron al reinventar la rueda con Powershell. Además de su uso para administrar aplicaciones de infraestructura, p.Intercambio, no tengo un incentivo para aprender Powershell cuando ya hay excelentes idiomas disponibles. Mi .02 centavos.