Probablemente alguna vez habréis trabajado en Visual Studio con una solución .NET enorme, con decenas o centenares de proyectos. Es algo habitual en sistemas que tienen ya muchos años de vida, con una arquitectura muy compleja o que han ido creciendo con el tiempo sin un control adecuado.

En estos casos, el entorno de desarrollo tarda una eternidad en cargar la solución y quedar listo para su uso, el rendimiento de Visual Studio se resiente enormemente, con lo que cada acción que realicemos (compilar, ejecutar, depurar, etc.) se vuelve lenta y frustrante, y encima, al navegar por el código, todo se complicará bastante por la cantidad de proyectos y archivos que tendremos que manejar.

Y lo peor de todo es que es para nada. En la mayoría de los casos no es necesario tener todos los proyectos de la solución cargados para poder realizar nuestras tareas, porque lo habitual es que solo trabajemos con un subconjunto de ellos, normalmente bastante pequeño.

Afortunadamente, .NET permite crear filtros de solución (archivos .slnf), algo así como mini-soluciones que incluyen solo los proyectos que nos interesan en cada ocasión, mejorando el rendimiento de los entornos de desarrollo y facilitando la navegación por el código.

En este artículo vamos a ver qué son los filtros de solución, cómo crearlos y cómo usarlos.

¿Qué son los filtros de solución?

Los filtros de solución fueron introducidos hace ya unos años, con Visual Studio 2019 y .NET Core 3.1. Se trata de una forma de crear vistas personalizadas de una solución donde solo se incluyen los proyectos con los que queremos trabajar en cada momento.

En la práctica, son simples archivos de JSON con extensión .slnf que contienen una referencia a una solución normal (archivo .sln o .slnx) y la lista de proyectos que queremos incluir en el filtro. Una vez creados, podemos abrir estos archivos directamente desde Visual Studio o nuestro editor favorito, y solo cargarán los proyectos que hayamos incluido en el filtro.

Como ejemplo, a continuación se muestra el contenido de un filtro de solución, llamado OneToFour.slnf, que incluye solo los proyectos 1, 2, 3 y 4 de una solución con 300 proyectos llamada VeryBigSolution.slnx (vale, quizás es un escenario algo exagerado, pero sirve para ilustrar la idea):

{
  "solution": {
    "path": "VeryBigSolution.slnx",
    "projects": [
      "Project01/Project01.csproj",
      "Project02/Project02.csproj",
      "Project03/Project03.csproj",
      "Project04/Project04.csproj"
    ]
  }
}

Imaginaos el cambio que supone manejar solo 4 proyectos en lugar de los 300 que tiene la solución original. La carga de la solución en Visual Studio será mucho más rápida, así como el rendimiento general del entorno de desarrollo y las acciones habituales que realizamos en él, como compilar, ejecutar, depurar, navegar por el código, etc.

Los archivos .slnf son soportados también a nivel de framework desde .NET Core 3.1, lo que quiere decir que podemos lanzar comandos de CLI como dotnet build, dotnet test, o incluso msbuild apuntando a un archivo de filtro de solución, y se ejecutarán solo con los proyectos que estén incluidos en dicho filtro.

D:\Projects\VeryBigSolution>dotnet build OneToFour.slnf
Restore complete (0,6s)
  Project03 net10.0 succeeded (0,1s) → Project03\bin\Debug\net10.0\Project03.dll
  Project02 net10.0 succeeded (0,1s) → Project02\bin\Debug\net10.0\Project02.dll
  Project04 net10.0 succeeded (0,2s) → Project04\bin\Debug\net10.0\Project04.dll
  Project01 net10.0 succeeded (0,2s) → Project01\bin\Debug\net10.0\Project01.dll

Build succeeded in 1,1s

En realidad, es parecido a lo que conseguiríamos creando soluciones normales (.sln/.slnx) con distintos subconjuntos de proyectos. Sin embargo, si lo hiciéramos de esta forma, tendríamos que encargarnos de gestionar varias soluciones, con sus configuraciones, perfiles y otras cosas; en cambio, con los filtros de solución, solo tenemos que mantener una solución normal y varios archivos de filtro que la referencien, por lo que todo será más sencillo y fácil de mantener.

Por ultimo, es conveniente aclarar que por cada solución podemos tener tantos archivos .slnf como queramos, cada uno con un subconjunto diferente de proyectos. De esta forma, podríamos tener un filtro para cada área funcional del sistema, para cada equipo de desarrollo, para cada tarea concreta que tengamos que realizar, etc.

¿Cómo crear un filtro de solución?

Al tratarse de archivos .json, bastaría con crearlos manualmente con un editor de texto cualquiera, siempre que sigamos la estructura que hemos visto antes.

Sin embargo, Visual Studio también nos ofrece una forma muy sencilla de crearlos a través del entorno gráfico. Para ello, lo único que tenemos que hacer es abrir la solución normal (archivo .sln o .slnx), usar el menú contextual del Explorador de Soluciones para descargar los proyectos que no nos interesen, y finalmente ir a Archivo > Guardar como solución filtrada... y elegir un nombre para el nuevo filtro de solución.

A partir de aquí, ya la cosa pasa a ser completamente artesana. Si queremos añadir nuevos proyectos al filtro o eliminar algunos existentes, tendremos que retocar el archivo .slnf manualmente, o bien volver a generarlo desde Visual Studio siguiendo el procedimiento descrito antes.

¡Espero que os resulte útil!

Publicado en Variable not found.