BÚSQUEDA DE ENSAMBLADOS EN TIEMPO DE EJECUCIÓN EN .

NET
Nivel: Intermedio
por José Manuel Alarcón Aguín, www.jasoft.org

A raíz de la duda de uno de mis alumnos de campusMVP (www.campusmvp.com), he decidido

escribir este documento que explica los mecanismos de .NET Para localizar y cargar
ensamblados en las aplicaciones.

Las preguntas habituales dentro de esta temática suelen ser: ¿dónde debo colocar los
ensamblados que uso en mis aplicaciones? ¿Y cómo hago si quiero compartirlos entre varias
aplicaciones?

Trataré de contestarlas a continuación.

En este documento explicaré los tipos de ensamblados que tenemos en .NET, cómo el motor
de tiempo de ejecución de la plataforma busca los diferentes ensamblados que usan nuestras
aplicaciones, y cómo podemos incluir referencias a ensamblados de la GAC desde Visual
Studio. Finalmente, como apéndice, explicaré un truco para poder ver ensamblados propios en
el diálogo de agregar referencia de Visual Studio.

1.- Tipos de ensamblados

Existen dos tipos de ensamblados en función del uso que se quiera hacer de ellos:

· Ensamblados privados: se identifican por su nombre (el nombre físico del

ensamblado sin la extensión) y se incluyen con la propia aplicación para su uso desde
la misma. Son los más comunes y los que utilizamos habitualmente.
· Ensamblados compartidos: se identifican por un su nombre completo (”strong
name” en inglés. Se suele usar más este término anglosajón que mi traducción). Se
trata de ensamblados firmados digitalmente para certificar su identidad. En la firma se
incluye el nombre del ensamblado pero también otros datos, como su número de
versión o la cultura utilizada. Lo más importante es que incluye un testigo de clave
pública (public key token) que sirve para comprobar la firma y verificar su autenticidad.

Los ensamblados compartidos se generan con la utilidad de línea de comandos sn.exe, o bien
desde el propio IDE de Visual Studio especificando los valores en la pestaña “Firma”, en las
propiedades de un proyecto de biblioteca de clases:
 Figura 1.- Pestaña de propiedades de firma en un proyecto .NET

Para la firma se utiliza un algoritmo de clave pública, por lo que necesitamos disponer de una
pareja de claves pública-privada para el proceso. Podemos reutilizar una pareja de claves que
ya tengamos para todos los proyectos (recomendable) o bien generar una nueva usando la
lista desplegable que se ve en la figura anterior.

Figura 2.- Diálogo de generación de nueva pareja de claves de firma

Estos ensamblados compartidos los podemos agregar a la GAC (Global Assembly Cache) del
sistema si queremos que puedan ser localizados y utilizados por todas las aplicaciones que
tengamos instaladas, si bien sólo se recomienda con bibliotecas de funciones que realmente se
reutilicen mucho.

2.- Búsqueda de ensamblados

Cuando se compila una aplicación, la información sobre los otros ensamblados que ésta utiliza
(las referencias) se guardan dentro del manifiesto del ensamblado final que se genera tras la
compilación. Es decir, el .exe o .dll que generemos contiene información acerca de los otros
ensamblados que se utilizan. Como es lógico, en esta información no se almacenan las rutas de
los ensamblados, ya que cualquier cambio de ubicación de la aplicación o de las DLL auxiliares
haría que no funcionase. Por ello, lo que se almacena es el nombre o nombre completo (ver
apartado anterior) de los ensamblados, y el motor de tiempo de ejecución de .NET los localiza
cuando los necesita.

Figura 3.- Manifiesto de un ensamblado con diversas referencias a ensamblados compartidos del sistema

El mecanismo de búsqueda de ensamblados que se utiliza es ligeramente diferente si éstos son

privados o compartidos. A continuación vamos a ver el proceso de búsqueda y carga que hace
el runtime de .NET.

3.- Buscar ensamblados privados

Cuando se llama por primera vez a código que está ubicado en un ensamblado privado el
motor de tiempo de ejecución de .NET debe cargar en memoria dicho ensamblado, y para ello
debe ubicarlo primero en disco. Existe un orden en las diferentes rutas que el runtime va a
seguir para ubicar ensamblados.
Lo primero que debemos saber es que cuando se ejecuta una aplicación, el runtime mira el
archivo de configuración (.config) de ésta para ver si existe un nodo especial que le indique
carpetas adicionales en dónde buscar. Este tipo de nodo es de la siguiente forma:
<?xml version="1.0"?>
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="bin\ruta1;bin\ruta2; " />
</assemblyBinding>
</runtime>
</configuration>

En el nodo <probing> se especifican rutas relativas a la carpeta en la que está la aplicación, y

que puede que contengan (o no) ensamblados para cargar en tiempo de ejecución. Esto es
muy útil si nuestro programa usa algún tipo de plug-in que podemos cargar posteriormente de
forma dinámica al trabajar con él.

Estas rutas se anotan para utilizarlas luego en la búsqueda de ensamblados.

Conociendo este detalle la búsqueda de ensamblados, entonces, se realiza en las siguientes

carpetas y en el siguiente orden pre-establecido:
CarpetaBase\NombreEnsamblado.dll
CarpetaBase\NombreEnsamblado\NombreEnsamblado.dll
CarpetaBase\Ruta1\NombreEnsamblado.dll
CarpetaBase\Ruta1\NombreEnsamblado\NombreEnsamblado.dll
CarpetaBase\Ruta2\NombreEnsamblado.dll
CarpetaBase\Ruta2\NombreEnsamblado\NombreEnsamblado.dll
CarpetaBase\NombreEnsamblado.exe
CarpetaBase\NombreEnsamblado\NombreEnsamblado.exe
CarpetaBase\Ruta1\NombreEnsamblado.exe
CarpetaBase\Ruta1\NombreEnsamblado\NombreEnsamblado.exe
CarpetaBase\Ruta2\NombreEnsamblado.exe
CarpetaBase\Ruta2\NombreEnsamblado\NombreEnsamblado.exe

Es decir, se buscan primero las DLL y luego los EXE, y primero se intentan localizar dentro de la
carpeta actual, y sino dentro de carpetas con el nombre del ensamblado, para finalmente
probar dentro de las carpetas sugeridas en el .config (en caso de haberlas).

Si el ensamblado referenciado está atado a una cultura específica, las rutas cambian
ligeramente para reflejar este hecho y poder localizar el correcto según la cultura empleada:
CarpetaBase\Cultura\NombreEnsamblado.dll
CarpetaBase\Cultura\NombreEnsamblado\NombreEnsamblado.dll
CarpetaBase\Ruta1\Cultura\NombreEnsamblado.dll
CarpetaBase\Ruta1\Cultura\NombreEnsamblado\NombreEnsamblado.dll
CarpetaBase\Ruta2\Cultura\NombreEnsamblado.dll
CarpetaBase\Ruta2\Cultura\NombreEnsamblado\NombreEnsamblado.dll]
CarpetaBase\Cultura\NombreEnsamblado.exe
CarpetaBase\Cultura\NombreEnsamblado\NombreEnsamblado.exe
CarpetaBase\Ruta1\Cultura\NombreEnsamblado.exe
 CarpetaBase\Ruta1\Cultura\NombreEnsamblado\NombreEnsamblado.exe
CarpetaBase\Ruta2\Cultura\NombreEnsamblado.exe
CarpetaBase\Ruta2\Cultura\NombreEnsamblado\NombreEnsamblado.exe

Es decir, es casi idéntico pero siempre incluyendo el nombre de la cultura delante (por
ejemplo, “es-ES”, “en-UK” o simplemente “es” o “en”.

Con esto resulta fácil saber en qué rutas debemos colocar nuestros ensamblados para que el
runtime de .NET los pueda localizar.

4.- Buscar ensamblados compartidos

En el caso de los ensamblados firmados digitalmente o ensamblados compartidos, el proceso
es algo diferente y los pasos son los siguientes:

1.- Antes de nada se busca el ensamblado en la GAC del sistema. Si el ensamblado está
registrado ahí entonces ya se carga desde la ruta definida en éste y se termina la
búsqueda.

2.- Si no está en el GAC se mira el archivo .config de la aplicación para comprobar si

existe un elemento <codebase>. Éste se usa para especificar manualmente la
ubicación de ciertos ensamblados en una aplicación. Por ejemplo:
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="miEnsamblado"
publicKeyToken="543rdfa2l9d7e4"
culture="neutral" />
<codeBase version="3.0.0.0"
href="http://www.miweb.com/miEnsamblado.dll"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>

De este modo se puede forzar la descarga de una determinada versión de un

ensamblado firmado digitalmente desde una ruta concreta en el disco, la red local o
incluso Internet (como en el ejemplo).

Si en la configuración hay una línea como esta para el ensamblado que nos interesa,
entonces se carga desde ahí y se termina el proceso.

Más información sobre esta configuración en: http://msdn.microsoft.com/es-

es/library/efs781xb.aspx.
 3.- Si el ensamblado que se busca no se ha cargado en uno de los dos pasos anteriores,
entonces se intenta cargar buscándolo como si se tratara de un ensamblado privado,
tal como se ha visto en el apartado anterior.

¿Cómo sabe el runtime que el ensamblado es uno compartido y por lo tanto que debe usar
este procedimiento? Muy sencillo: porque en el manifiesto se almacena el nombre completo
del ensamblado (ver figura 3), el cual incluye la clave pública de firma del mismo. Además
gracias a esta se puede comprobar la identidad del ensamblado antes de proceder a cargarlo.

5.- ¿Cómo añado una referencia a un ensamblado en el GAC?

Esta fue en realidad la pregunta que hizo mi alumno, y aunque parece que tiene una respuesta
sencilla y directa, no es así.

Figura 4.- Diálogo de agregar una referencia .NET

Cuando abrimos el diálogo de agregar referencias de Visual Studio disponemos de varias

pestañas. La primera de ellas se llama simplemente “.NET” y aparentemente en ella se listan
los mismos ensamblados que podemos encontrar en la GAC. Sin embargo si añadimos uno de
nuestros ensamblados a la GAC comprobaremos que no aparece en este diálogo.

El motivo es que Visual Studio utiliza unas rutas concretas para llenar esa pestaña del diálogo,
no la lista que hay en la GAC como parece a simple vista. Esas rutas, por defecto, coinciden con
las que contienen las DLLs del framework, que son en general las mismas que están en el GAC,
de ahí que pueda creerse que son listas idénticas cuando no es así.

Entonces, si tengo una DLL propia en el GAC y no va a aparecer en esta lista, ¿cómo añado una
referencia a la misma en mi aplicación?

La respuesta es que si tú tienes un ensamblado firmado sólo debes añadir una referencia al
mismo directamente desde Visual Studio, como si de un ensamblado normal se tratara. A
mayores lo seleccionas, pulsas F4 para ir a sus propiedades, y marcas la opción de no copiarlo
localmente.

Figura 5.- Propiedad CopyLocal para evitar que el ensamblado se distribuya

Esto indica que éste no se debe copiar junto con el proyecto. Más tarde, en tiempo de
ejecución, cuando el runtime busque el ensamblado en cuestión, dado que es un ensamblado
compartido (está firmado), al primer sitio al que irá a buscarlo es al GAC, así que lo usará desde
allí como queríamos si lo hemos añadido previamente. Repasa el apartado anterior y lo verás
claro.

6.- TRUCO: Añadir una DLL propia al diálogo de añadir referencia .NET
Para terminar voy a explicar cómo podemos hacer que una de nuestras DLL compartidas, que
está en el GAC o no, aparezca directamente en el diálogo de añadir referencia, dentro de la
pestaña .NET de la figura 4.

Para conseguirlo es necesario tocar el registro, no queda otro remedio.

Las rutas en las que busca este diálogo sus elementos están especificadas en el registro dentro
de estas dos ramas:
[HKEY_LOCAL_MACHINE]\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders
[HKEY_CURRENT_USER]\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders

que son, respectivamente, donde buscará elementos para todos los usuarios y para un usuario
concreto a mayores. La segunda rama seguramente ni siquiera existe en tu equipo, ya que por
defecto no hay nada especial por usuario, claro.

Si quieres que un ensamblado propio aparezca ahí tendrás que introducir en el registro, en
alguna de estas ramas, un valor personalizado. Así que creas una sub-rama nueva con el
nombre descriptivo que quieras y dentro de ésta, en su valor por defecto, le pones la ruta
física de la carpeta que contiene a tus ensamblados.

Figura 6.- Rama del registro en la que busca el diálogo

De todos modos esto no tiene mucha utilidad dada la forma que tiene el sistema de buscar
ensamblados, según hemos visto. Simplemente te resultará algo más cómodo añadir la
referencia, pero nada más.

Acerca del autor

José Manuel Alarcón Aguín, ASP.NET Visual Developer MVP. Es ingeniero industrial y especialista en
consultoría de empresa. Ha escrito varios libros, habiendo publicado más de 300 artículos sobre
informática e ingeniería en publicaciones especializadas. Es colaborador de MSDN. José Manuel es
también Instructor Certificado de Microsoft (MCT). www.jasoft.org

Acerca de campusMVP
CampusMVP te ofrece la mejor formación en tecnología Microsoft a través de nuestros cursos online y
nuestros libros especializados, impartidos y escritos por conocidos MVP de Microsoft. Visita nuestra
página y prueba nuestros cursos y libros gratuitamente. www-campusmvp.com

Reconocimiento - NoComercial - CompartirIgual (by-nc-sa):

No se permite un uso comercial de este documento ni de las posibles obras derivadas, la distribución de las cuales
se debe hacer con una licencia igual a la que regula esta obra original. Se debe citar la fuente.