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:

image

Por otro, el proyecto en el que estoy trabajando y que hace uso de algunas de las librerías

image

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.

image

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.

image

Comentarios

Entradas populares de este blog

Install NET Core 2.1 SDK on Rasapbian

Actualizar automáticamente la versión del ejecutable con el nº de build de Jenkins

Pasar parámetros dinámicos a Attributes