Cuando requieres de entender las dependencias que tienen los proyectos de tu solución, ya sea entre ellos o con archivos externos, hacerlo por cada uno puede ser bastante engorroso. Afortunadamente Visual Studio cuenta con una herramienta bastante interesante: Code Maps.
La primera opción que tenemos es ver el panorama general de la solución. Para ello hay que ir al Menú Architecture > Generate Code Map for Solution
Dependiendo del tamaño de la solución tardará más o menos, pero al finalizar deberás ver algo como esto
Y listo, tenemos una representación visual de los proyectos y sus dependencias. Una de las cosas que más me gustaron es que el mapa incluye hasta los Solution Folders, que muchos usamos para organizar los proyectos, comúnmente en “capas”. Pero en este caso, no nos es de mucha utilidad tenerlo. Lo que vamos a hacer ahora es …. quitarlo. Para ello vamos a la parte derecha en la seccion Filters, y desactivamos la casilla de Solution Folder en la seccion de Code Elements. El resultado debe ser algo parecido a esto
Este ejemplo es de un proyecto demo de la implementación de IdentityServer4. Como se puede apreciar, los proyectos no tienen dependencia entre sí, solamente externas. Dependiendo de tu situación actual podrías tener algo como spaghetti (honestamente espero que no sea tu caso)
Otro de los atractivos (a mi parecer) de la heramienta es que te muestra el tipo de relación que hay entre los elementos. Para este otro proyecto podemos ver múltiples ejemplos
El código de colores y tipos de línea se encuentra al lado derecho, en el panel “Legend”. Si no esta visible puede mostrarse presionando el botón del mismo nombre en la parte superior del diagrama.
Relaciones
El diagrama actual muestra dos escenarios de relaciones, uno es entre mis “capas” (los Solution Folders) y el otro entre los elementos dentro de ellos. Curiosamente en este ejemplo, si observamos en la esquina inferior izquerda de Auth, encontramos un elemento tan antisocial como el autor, que parece no relacionarse con nadie. ¿Es realmente el caso? Si le damos clic a uno de los elementos del diagrama (en este caso, Hermes.Auth.B2C.dll), podemos notar que nos da la información de sus relaciones con el resto del mundo binario.
Dependencias externas
Adicional a las relaciones, tenemos la opción de ver las dependencias externas. Siguiendo el ejemplo anterior, al dar click en el elemento Externals, se muestran las lineas de las relaciones específicas que cada proyecto tiene. Pero ¿y si quiero saber cuáles son? En este caso, al acercar el cursor a Externals, aparece una pequeña flecha del lado superior izquierdo. Si la presionas, podrás ver la lista completa de referencias de la solución
Ahora bien, el punto de más utilidad es el siguiente: aquí podemos darnos cuenta, entre otras cosas si en la solución estamos utilizando dos versiones diferentes de un mismo ensamblado, como en este caso:
Esto es obviamente posible gracias a la magia negra del GAC, pero no necesariamente quiere decir que sea lo que yo quiero ni la mejor opción. Al poner el cursor sobre el nombre del ensamblado, puedo darme cuenta que estoy usando Microsoft.Owin version 3.1.0 y versión 3.0.1. Puede parecer algo sin importancia, pero cuando salen los errores es uno de los detalles que nos pueden causar más dolores de cabeza.
Y como ya vimos anteriormente, dar clic al elemento nos muestra que proyecto está usando cada dll.
Moraleja
Esta herramienta está disponible desde Visual Studio 2015 (los ejemplos aquí son con 2017), en las versiones Pro y Enterprise. Y como moraleja de esta historia tenemos “No confíes en las versiones que los paquetes de nuget descargan”.
? no hay info en este artículo