c# - studio - Descubriendo las dependencias de interfaz
visual studio installer (6)
No sé cómo se configura su proyecto, pero aquí cada módulo que tenemos tiene un número de versión. Cuando necesitamos hacer un cambio a un módulo, creamos una nueva versión. Código de cliente que quiere usar los enlaces de la nueva interfaz al módulo actualizado y elimina la referencia al proyecto anterior. Con diferentes versiones, no hay efectos secundarios involuntarios al cambiar una API; el código del cliente debe hacer algo explícitamente.
Además, tenemos una utilidad que (de alguna manera) rastrea todos los proyectos e informes si alguno de ellos está utilizando un módulo que no es la última versión. Es bastante fácil de verificar (¡incluso con Microsoft VSS!) Qué proyectos tienen referencias a módulos desactualizados.
He asumido el mantenimiento de un proyecto de software muy grande (> 2M SLOC), todo escrito en C #. Hay muy poca documentación. Ahora quiero hacer un cambio en un módulo que tiene interfaces públicas (alrededor de 400), pero no sé qué otros módulos (hay unos 50 en total) en la solución pueden estar usando esta interfaz pública.
¿Cómo crearías un árbol de uso de dependencia de interfaz para una situación como esta? La base de código es demasiado grande para simplemente navegar por el Explorador de proyectos y leer el código fuente. ¿Qué herramientas o métodos usó para crear este tipo de árbol de análisis de dependencia?
No quiero comprar ninguna herramienta. Las herramientas de Visual Studio como Class View no parecen manejar un proyecto de este tamaño muy bien. He pensado en escribir mi propio script sed / awk / perl-ish que simplemente recorre el código fuente y utiliza la coincidencia de patrones para construir mi propia base de datos de uso de interfaz / dependencia, pero no quiero hacer algo de la manera difícil si hay una manera fácil.
¡Gracias!
Sé que dijiste que no querías comprar una herramienta, pero CodeRush está disponible con todas las funciones y gratis por un mes (¡y solo $ 250 después de eso y obtienes refactor pro !, que es increíble). Sustituye Shift + F12 por una ventana de búsqueda de todas las referencias realmente ingeniosa.
Solo como un consejo: cuando vayas a construir tu propia versión de una herramienta de este tipo, también puedes hacer esto en los ensamblajes compilados usando reflexión.
.NET le ofrece todo lo que necesita para cargar un conjunto y consultar todas las interfaces, tipos, métodos y propiedades en el espacio de nombres System.Reflection. De esta forma, no tiene que preocuparse por analizar el código fuente usted mismo usando sed / awk / perl (que no es trivial ya que necesita resolver espacios de nombres y herencia).
(Nota: Lo que no se obtendría directamente usando la reflexión son las dependencias de ensamblaje para ensamblajes cargados dinámicamente, cargados, por ejemplo, a través de Assembly.Load. Tendría que implementar un manejo especial si esto se usa en su proyecto)
Solución simple para las dependencias directas, haga clic con el botón derecho en la interfaz y seleccione "Buscar todas las referencias". También puedes hacer esto por método.
Para saber cuánto código se romperá como resultado de un cambio, puede agregar [Obsoleto (verdadero, "Probando el cambio")] a los métodos en la interfaz que planea cambiar y activar una reconstrucción. Esto llevará a que algunas partes no se construyan. Salta a esas partes y etiquétalas con [Obsoleto (falso, "Cambio limitado")] si sientes que esto es un pequeño cambio en esa clase y que puedes arreglarlo sin ningún efecto sobre los consumidores de esta clase, si crees que esto causará problemas importantes a los consumidores de la clase, puede etiquetarlo como [Obsoleto (verdadero, "Cascade")] y lidiar con sus consecuencias.
Finalmente, su solución se compilará por completo o tendrá tantos errores que será obvio que el cambio es tan invasivo que la única forma de controlar realmente el efecto es comenzar a intentarlo de verdad.
El beneficio de este enfoque es que puede hacer la cascada sin tener que lidiar con la forma en que se enfrenta a ella, solo que necesita una evaluación aproximada de si generará los cambios consiguientes. Una vez que estés contento de que hayas mapeado el cambio, tienes una lista de advertencias preparadas en tu IDE para ir y cambiar a medida que modifiques la interfaz propiamente dicha (y la compilación realmente falla).
Esto se basa en no tratar las advertencias como errores, es posible que deba aflojar temporalmente las configuraciones de compilación.
Haga todo esto en una nueva actualización de fuente para que pueda retirar las partes si quiere volver a intentarlo.
En serio, sugiero solo encontrar una herramienta existente para hacer esto. Nunca podrá resolver todo el asunto a mano, y el tiempo ahorrado con una herramienta definitivamente pagará el costo de la herramienta en sí.
Un tipo con el que trabajaba tenía este problema: su gerente no pagaba un generador de perfiles, por lo que dedicaron 5 días de desarrollador a optimizar las partes incorrectas del programa. Usando el generador de perfiles, encontró y resolvió el problema en medio día.