.net - PowerShell Runspace vs DLR
scripting dynamic-language-runtime (4)
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?
En .NET 4.0, el DLR consiste en lo que puede considerar como "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 alojamiento, excepto IronPython e 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.
Estoy de acuerdo, el DLR ha generado y continuará generando muchas discusiones buenas. PowerShell no está dirigido para el DLR. No obstante, no sé por qué.
El alojamiento de PowerShell en una aplicación .NET habilita la canalización de objetos de PowerShell en la solución de scripting, que creo que es un beneficio clave.
Hay ejemplos de llamadas a PowerShell desde IronPython .
También puede incrustar IronPython en PowerShell .
IronPython e IronRuby no tienen la misma integración en Windows que PowerShell. Sería genial si PowerShell fuera DLR habilitado de fábrica.
Mi opinión sobre esto es que Microsoft debería haber desarrollado sus interfaces de administración de Backoffice basadas en DLR, de modo que los lenguajes de primera categoría y ya probados como Python y Ruby en .NET (o cualquier otro lenguaje incorporado en DLR) puedan aprovecharse, como opuesto a lo que creo que hicieron al reinventar la rueda con Powershell. Además de su uso para gestionar aplicaciones de infraestructura, por ejemplo, Exchange, no tengo un incentivo para aprender Powershell cuando ya hay excelentes idiomas disponibles. Mi .02 centavos.
La respuesta de Doug llega a algunos puntos clave, pero creo que la razón principal para usar PowerShell como motor de scripts en una aplicación .NET es el hecho de que PowerShell se está convirtiendo en la principal superficie de administración en las aplicaciones de Microsoft y disfrutará de una mayor familiaridad entre los administradores de sistemas que están manteniendo su aplicación.
IronPython e IronRuby (así como cualquier otro lenguaje específico para el DLR) probablemente serán más familiares para la audiencia de desarrolladores.