Generalmente una aplicación no se compone de un único ensamblado, sino que contiene múltiples ensamblados, cada uno con una funcionalidad determinada.
Si suponemos una aplicación de consola o WinForm, lo más habitual es que los ensamblados que necesita la aplicación de consola se encuentren en el mismo directorio que la aplicación principal, para que el motor de ejecución pueda encontrar las dependencias de la aplicación al ejecutarla. En un aplicación ASP.NET todos los ensamblados estarían en el directorio bin.
- MiAplicacion.exe
- AccesoDatos.dll
- Logica.dll
- Utilidades.dll
En ciertas situaciones puede ser que no nos interese que todas los ensamblados se encuentren dentro del mismo directorio. Nos puede interesar tener múltiples directorios con ensamblados y que cuando se ejecute la aplicación el CLR busque y cargue las dependencias de la aplicación desde cualquiera de los directorios que definamos.
- MiAplicacion.exe
- MiDirectorioAccesoDatos.dll
- MiOtroDirectorioLogica.dll
- MiTercerDirectorioUtilidades.dll
Cierto es que también podríamos cargar los ensamblados en la GAC pero yo al menos soy partidario de usar los menos posible este recurso y cargar los ensamblados desde los directorios de la aplicación.
En estas situaciones podremos usar la característica de probing, que nos permite especificar, a través del fichero de configuración subdirectorios de la aplicación en los que el CLR busque cuando se cargan los ensamblados.
Digo subdirectorios, porque los directorios “extras” a definir deben ser subdirectorios del directorio base ( del directorio bin en aplicaciones ASP.NET ).
En el fichero de configuración ( app.config o web.config ) dentro de la sección runtime>assemblyBinding podemos especificar los path privados dónde el CLR buscará las dependencias de la aplicación. Podemos definir tantos como consideremos.
<configuration> <runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <probing privatePath="MiDirectorio"/> </assemblyBinding> </runtime> </configuration>
Ya para terminar me parece interesante, para aquellos que no lo conozcáis, que leáis los pasos que el motor en tiempo de ejecución lleva a cabo para resolver una referencia a un ensamblado;Cómo el motor en tiempo de ejecución ubica ensamblados.
Muy interesante!!
Es genial, lástima que solo pueda hacer probing, en subdirectorios del directorio en el cual está el ejecutable…s. En fin… 🙂
En un cliente tenemos el ejecutable en un directorio y (por obligación) todos los assemblies (y son bastantes) en otros directorios completamente distintos… como el tema de la GAC no les pitufa mucho, el resultado es un .exe.config lleno de
@Eduard, puede mostrar el exe.config para ver cómo se ponen los codeBase
@Ibon, existe alguna merma de rendimiento al situar los ensamblados en los directorios ??
Gracias.
Especificar la ubicación de un ensamblado
http://msdn.microsoft.com/es-es/library/4191fzwb.aspx
Y al menos que sepa yo, no supone un problema de rendimiento usar estas caracteristicas.