2010-03-15 15 views
9

Estoy buscando un conjunto de clases (preferiblemente en el marco .net) que analizará el código C# y devolverá una lista de funciones con parámetros, clases con sus métodos, propiedades, etc. Idealmente proporcionaría todo lo que se necesita para construir mi propio intellisense.Buscando un analizador de código C#

Tengo la sensación de que algo así debería estar en el .NET Framework, dado todo el material de reflexión que ofrecen, pero si no es así, una alternativa de código abierto es suficiente.

Lo que estoy tratando de compilar es básicamente algo así como el Compilador de fragmentos, pero con un giro. Intento descubrir cómo obtener el código dom primero.

Intenté buscar en Google esto, pero no estoy seguro de cuál es el término correcto para esto, así que se me ocurrió que estaba vacío.

Editar: Como estoy buscando utilizar esto para el procesamiento intellisense, en realidad compilar el código no funcionará, ya que lo más probable es que esté incompleto. Perdón, debería haber mencionado eso primero.

+0

¿Tiene que funcionar con código no completo o código con errores (es decir, código que no se compilaría con el compilador normal?) Normalmente es un requisito para los analizadores de estilo IntelliSense. –

+0

Sí, debería funcionar en código incompleto. Estoy buscando cosas sobre la marcha. – Blindy

Respuesta

5

Si bien el espacio de nombres CodeDom de .NET proporciona el basic API for code language parsers, no están implementados. Visual Studio lo hace a través de sus propios servicios de idiomas. Estos no están disponibles en el marco redistribuible.

Usted podría ...

  1. compilar el código a continuación, utilizar la reflexión sobre el conjunto resultante
  2. mirada en algo así como el Mono compilador de C# que crea estos árboles de sintaxis. No será una API de alto nivel como CodeDom, pero tal vez puedas trabajar con ella.

Puede haber something on CodePlex o un sitio similar.

ACTUALIZACIÓN
Ver esta publicación relacionada. Parser for C#

+0

+1 para actualización también - contiene soluciones viables –

1

Eche un vistazo a CSharpCodeCompiler en Microsoft.CSharp namespace. Puede compilar utilizando CSharpCodeCompiler y acceder al conjunto de resultados utilizando CompilerResults.CompiledAssembly. De ese ensamblaje podrá obtener los tipos y fuera del tipo que puede obtener toda la propiedad y la información del método utilizando la reflexión.

El rendimiento será bastante promedio, ya que tendrá que compilar todo el código fuente cada vez que algo cambie. No conozco ningún método que le permita compilar fragmentos de código de forma incremental.

1

¿Ha intentado utilizar la clase Microsoft.CSharp.CSharpCodeProvider? Este es un proveedor de código C# completo que admite CodeDom. Simplemente necesitarás llamar a .Parse() en una secuencia de texto y recuperarás CodeCompileUnit.

var codeStream = new StringReader(code); 
var codeProvider = new CSharpCodeProvider(); 

var compileUnit = codeProvider.Parse(codeStream); 

// compileUnit contains your code dom 

Bueno, ya que lo anterior no funciona (yo sólo probé), el siguiente artículo puede ser de su interés. Lo marqué hace mucho tiempo, así que creo que solo es compatible con C# 2.0, pero todavía podría valer la pena:

Generate Code-DOMs directly from C# or VB.NET

+0

Esto no está implementado por ninguno de los proveedores de dom de código y arroja una NotImplementedException. – Josh

+0

@Josh: Parece que tienes razón. Lo intenté, y de hecho falla. Un desastre. – jrista

2

Si necesita que funcione en incompleta código o código con errores en ella, entonces yo creo que está bastante por su cuenta (es decir, no podrá usar la clase CSharpCodeCompiler ni nada de eso).

Hay herramientas como ReSharper que hace su propio análisis sintáctico, pero eso es prorietary. Es posible que pueda comenzar con el compilador Mono, pero en mi experiencia, escribir un analizador sintáctico que funcione con código incompleto es un juego completamente diferente al de escribir uno que se supone que debe arrojar errores en el código incompleto.

Si solo necesitas los nombres de las clases y los métodos (metadatos, básicamente), entonces podrías hacer el análisis "a mano", pero supongo que depende de qué tan preciso sea el resultado.

+0

Sí, estoy empezando a considerar analizarlo a mano. Sin embargo, no estoy seguro de lo difícil que será esto con los genéricos. – Blindy

2

Mono project El compilador GMCS contiene un analizador bastante reutilizable para C# 4.0. Y, es relativamente fácil escribir su propio analizador que se ajustará a sus necesidades específicas. Por ejemplo, puede reutilizar esto: http://antlrcsharp.codeplex.com/

+0

El problema con estos analizadores ya hechos es que no funcionarán para el código incompleto (y por lo tanto inválido). Su propósito es crear un árbol de sintaxis lo suficientemente detallado como para generar código, no para proporcionar datos para intellisense. – Blindy

+0

Sí. Pero, como son reutilizables, uno puede ajustarlos fácilmente. ANTLR se puede usar para un análisis parcial. Pero, por supuesto, la opción más genérica es PEG, por lo que si puede hacerse con una implementación de PEG decente para .NET y puede portar un analizador ANTLR existente, obtendrá una solución genérica fácil y rápida. Por ejemplo, un analizador de Packrat de http://www.meta-alternative.net/mbase.html es capaz de generar modos de resaltado de sintaxis para un editor de texto, sin ninguna sintaxis genérica, y funciona bien con incompleto o no válido entrada. –

1

Podría ser un poco tarde para Blindy, pero recientemente lancé un analizador C# que sería perfecto para este tipo de cosas, ya que está diseñado para manejar fragmentos de código y retiene comentarios: C# Parser and CodeDOM

Maneja C# 4.0 y también la nueva función 'async'. Es comercial, pero es una pequeña fracción del costo de otros compiladores comerciales.

Realmente creo que pocas personas se dan cuenta de cuán difícil se ha vuelto el análisis C#, especialmente si necesita resolver referencias simbólicas correctamente (lo cual generalmente es necesario, a menos que tal vez solo esté formateando). Solo intente para leer y comprender completamente la sección de Inferencia de tipo de la especificación de lenguaje de más de 500 páginas. Luego, medite sobre el hecho de que la especificación no es del todo correcta (como lo menciona el propio Eric Lippert).