Visual Studio y enlaces simbólicos
Problema
Tengo una solución en la que quiero aprovechar para crear/ampliar librerías genéricas que puedo usar en otros proyectos. Pero estas librerías están todavía en fase beta.
No me apetece tener que trabajar con 2 soluciones de Visual Studio, compilar la librería y luego usarla/copiarla en la solución que las necesita. Quiero todo en una sola solución, pero mantener las librerías aparte para poder compilarlas de forma independiente si hace falta.
Solución: Enlaces simbólicos
Un enlace simbólico permite crear un “acceso directo” a otra carpeta que está en otra estructura. Esto no es nuevo para Linux, pero bastante reciente en Windows.
Por un lado tengo mi solución de librerías genéricas. Es una solución como cualquier otra, aquí la estructura de carpetas, que cuelga de dotNETCommon:
Por otro, el proyecto en el que estoy trabajando y que hace uso de algunas de las librerías
Los 2 proyectos del recuadro son las librerías que pertenecen a la solución anterior.
Crear el enlace
Normalmente se necesitan permisos elevados, así que abrimos una consola con la opción de ejecutar como administrador
Si tenemos Vista o Windows 7, podemos usar directamente mklink. Si aún trabajamos con XP, los chicos de sysinternals publicaron junction que hace la misma labor.
Nos situamos en la carpeta de la solución, digamos MiSolucion, en este caso, en la carpeta donde está el archivo CPE.sln
Ejecutamos
mklink /d NombreCarpetaDestiono RutaCarpetaOrigen
Con esto, casi todos los programas entienden que NombreCarpeta está situada por debajo de MiSolucion, pero… Visual Studio no.
Visual Studio desreferencia los enlaces simbólicos
Vamos a matizar. Lo que hacemos es, en nuestra solución, agregar un proyecto existente.
Y es en esta operación cuando VS busca el origen de la carpeta y monta una ruta relativa a la carpeta física de origen.
Lo que hay que hacer es abrir el .sln con un block de notas y cambiar esas rutas raras que nos ha puesto por una ruta tal como si el proyecto estuviese realmente dentro de nuestra solución. Vamos, lo que el Explorador de Windows nos está mostrando ya.
Una vez modificado el archivo .sln compilará sin problemas y, si además usamos control de versiones y compilaciones automáticas:
Podemos ignorar las carpetas provenientes de la librería de controles: ya las tenemos bajo control de versiones en su propio proyecto y luego, en el servidor de compilación (nosotros tenemos Jenkins) podemos configurar varios orígenes de svn para que los descargue a un mismo workspace.
Comentarios