Microsoft Roslyn contra CodeDom


110

De un comunicado de prensa de ayer en InfoWorld sobre el nuevo Microsoft Roslyn :

La ventaja más obvia de este tipo de compilador "deconstruido" es que permite invocar todo el proceso de compilación y ejecución desde las aplicaciones .Net. Hejlsberg demostró un programa de C # que pasaba algunos fragmentos de código al compilador de C # como cadenas; el compilador devolvió el código ensamblador de IL resultante como un objeto, que luego se pasó a Common Language Runtime (CLR) para su ejecución. ¡Voilà! Con Roslyn, C # obtiene la capacidad de un lenguaje dinámico para generar e invocar código en tiempo de ejecución.

He podido hacer esto desde el lanzamiento de .NET 4 con el CSharpCodeProvider.CompileAssemblyFromSourceque de hecho uso en un proyecto ASP.Net escrito hace un tiempo que hace exactamente eso: permite a un usuario escribir código en un cuadro de texto, elegir ensamblados / espacios de nombres para hacer referencia y luego ejecutar y mostrar la salida de ese código sobre la marcha para la prueba del código del entorno en vivo en Windows Azure.

¿Es CodeDomparte de / un precursor de Roslyn? ¿Cuál es el beneficio especial de Roslyn CodeDom?

Respuestas:


240

Descargo de responsabilidad : trabajo para Microsoft en el equipo de Roslyn.

CodeDom es un precursor de Roslyn, pero solo está relacionado marginalmente. Esencialmente, CodeDom es una forma simple y (algo) independiente del idioma de generar código que se agregó en .NET 1.0 para apoyar a los diseñadores (a la WinForms). Debido a que CodeDom fue un intento de proporcionar un modelo unificado que puede generar código en C #, VB y otros lenguajes, carece de alta fidelidad con cualquiera de los lenguajes que admite (es por eso que no puede crear una declaración de cambio con CodeDom). CSharpCodeProvider.CompileAssemblyFromSource es simplemente un envoltorio alrededor de la ejecución de csc.exe.

Roslyn es un animal completamente diferente. Es una reescritura de los compiladores de C # y VB desde cero utilizando código administrado: C # en C # y VB en VB (las versiones de csc.exe y vbc.exe que se envían hoy están escritas en código nativo). La ventaja de compilarlos en código administrado es que los usuarios pueden hacer referencia a los compiladores reales como bibliotecas de aplicaciones .NET (no se necesitan envoltorios).

Mientras compilamos cada componente de la canalización del compilador, hemos expuesto las API públicas en la parte superior:

  • Analizador -> API de árbol de sintaxis
  • Tabla de símbolos / Importación de metadatos -> API de símbolos
  • Binder -> API de análisis de flujo y enlace
  • Emisor de IL -> API de emisión

Roslyn se puede usar como un sofisticado generador de código fuente de C # y VB, pero ahí es donde termina la similitud con CodeDom. Las API del compilador de Roslyn se pueden utilizar para analizar código, realizar análisis semántico, compilar y evaluar código de forma dinámica, etc.

Además de los compiladores, el equipo de Roslyn también está reconstruyendo las características de Visual Studio C # y VB IDE además de las API públicas del compilador. Por lo tanto, las API del compilador son lo suficientemente ricas para crear las herramientas de tiempo de diseño de Visual Studio, como IntelliSense y la refactorización del método de extracción. Además, en capas por encima del compilador, Roslyn ofrece servicios para análisis de nivel superior o transformación de datos. Por ejemplo, existen servicios para formatear código usando las reglas de formato C # y VB, o encontrar todas las referencias a un símbolo en particular dentro de una solución.

Realmente, no hay solo un beneficio especial de Roslyn sobre CodeDom. Donde CodeDom cubrió una necesidad de generación de código muy específica, Roslyn está abordando todo el espacio de herramientas de lenguaje al proporcionar un marco que le permite construir casi cualquier tipo de herramienta de lenguaje C # o VB que pueda imaginar.


2
@Dustin: ¿Roslyn apoyará otros idiomas? JavaScript (.NET), por ejemplo?
Diego Barros

@Dustin: Esto es perfecto para crear una experiencia IDE completa que pueda hacer cumplir la calidad del código en mi organización, aunque no veo un reemplazo completo de la revisión manual del código, pero veo un aumento considerable en la calidad. ¡Pronto!
Jerric Lyns John

Sería genial si alguien ya hubiera creado una herramienta basada en Roslyn para convertir código que usa CodeDom en código que usa SyntaxFactory de Roslyn ... (En parte porque .Net Core tiene Roslyn pero no CodeDom y estoy usando una biblioteca construida alrededor de CodeDom )
Emyr

43

CodeDom le permite compilar, pero no le da la capacidad de obtener realmente información sobre el código en sí (aparte de los errores del compilador). Básicamente, es una caja negra donde dices "compila esto" y dice "Lo logré" o "Fallé, aquí hay algunos errores".

Roslyn le permite inspeccionar completamente y construir el código sobre la marcha. Esto incluye cosas como poder ver / inspeccionar los comentarios dentro de un fragmento de código fuente, información detallada sobre la estructura completa, etc. Puede revisar y obtener el árbol de sintaxis completo de la fuente que pasa a Roslyn y hacer un análisis detallado o transformaciones en él.

Dada la información de sintaxis completa y rica, tiene una gran cantidad de control y flexibilidad adicionales. Así es como, por ejemplo, funciona el ejemplo que copia un bloque de código C # y lo pega como código VB.NET. Con Roslyn, puede hacer más que simplemente compilar, también puede manipular el código en sí de forma limpia. Esto debería hacer que muchas herramientas sean mucho más simples de generar, ya que cosas como la refactorización se pueden hacer de manera muy simple ya que las herramientas comprenden la sintaxis completa, incluida la metainformación (como comentarios), y pueden trabajar con ella directamente.


12

Veo una gran diferencia: con CodeDom, cada vez que compila algo de C # o VB.NET, se sale del proceso. CSC.exe o VBC.exe son los verdaderos trabajadores detrás de escena.

Si quieres construir un servicio, en términos de arquitectura, escalabilidad, aislamiento, etc. (mencionas Azure), esto no es muy bueno.

Con Roslyn está en proceso.

Supongo que esta es una de las razones por las que lo llaman "Compilador como servicio".

Además, CodeDom es una API relativamente pobre, carece de muchas características y no está realmente actualizada, ya que fue diseñada principalmente para admitir la generación automática de código de los diseñadores de UI de Visual Studio. Creo que a Roslyn le irá mucho mejor ya que está escrito por los chicos que escriben los compiladores. Espero que eso marque la diferencia.

PD: Una diferencia notable de CSC.exe y VBC.exe: Roslyn parece ser .NET puro (y usa CCI ).


8

Roslyn permite un control mucho más preciso de todo el proceso; por ejemplo, puede analizar la cadena e incluso generar código adicional (sobre la marcha dentro del proceso de compilación basado en el análisis), etc.

CodeDom "solo usa el compilador" mientras que Roslyn es "compilador como servicio con acceso completo a (sub) partes" ... con Roslyn está "dentro del compilador" y puede ver cómo se ve el código desde la perspectiva del compilador permitiéndole cambiar las cosas de formas que actualmente no son posibles.

Por ejemplo, puede usar Roslyn para extender C #, algo muy útil y mucho mejor que el estado actual de la implementación de AOP.

Para obtener una descripción general del estado actual de Roslyn y los diferentes niveles de acceso y control que proporciona, consulte http://msdn.microsoft.com/en-us/hh500769

ACTUALIZAR

Microsoft acaba de poner a disposición un nuevo CTP con características adicionales y muchos cambios / adiciones de API. Para obtener más detalles, consulte aquí .


1
En realidad, no es cierto que pueda usar Roslyn para extender C # con palabras clave adicionales.
Dustin Campbell

gracias ... corregido ... aunque no en el primer lanzamiento soy lindo que esto será posible ...
Yahia

2
@DustinCampbell, ¿Qué pasa si maneja cualquier error del compilador que la pseudo palabra clave causó al generar código?
Rodrick Chapman

3
Necesitaría hacer una reescritura antes de pasarlo al compilador. Primero, analice el código con sus palabras clave especiales. El código se analizará y, a menos que el analizador no pueda encontrar cabezas o colas, las palabras clave no válidas aparecerán como SkippedTokenTrivia en el árbol resultante. Luego, detecte las palabras clave omitidas y vuelva a escribir el árbol con un código válido (por ejemplo, tejido AOP). Finalmente, pase el nuevo árbol al compilador. Sin embargo, este es definitivamente un truco y no está garantizado que funcione con versiones futuras de Roslyn. Por ejemplo, es posible que el analizador no produzca el mismo árbol para el código roto en versiones futuras.
Dustin Campbell

@DustinCampbell: pero ¿habrá ALGO que permita a AOP tejer en la final de Roslyn? Mi tejido Mono.Cecil INPC funciona bien tal como está, pero si pudiera escribir public notifying string Name {get;set;}eso sería aún más impresionante
TDaver
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.