¿Cómo puedo obligar a .NET a usar una copia local de un ensamblaje que está en el GAC?

Tengo un ensamblado .NET que (por razones fuera de mi control) debe estar en el GAC. Sin embargo, otro progtwig utiliza el mismo conjunto, que tiene su propia copia de una versión anterior del mismo conjunto. Debe usar su propia copia y no lo que esté en el GAC. El control de versiones correcto es probablemente más complicado de lo que vale en este caso, por razones que no entraré. Mi pregunta es: ¿hay alguna forma de decirle a .NET: simplemente use ESTE archivo DLL, aquí en este directorio, ignore lo que encuentre en el GAC o en cualquier otro lugar .

Asegúrese de que el Ensamble GAC y el Ensamblado local tengan diferentes números de versión (no es una mala idea dejar que su número de comstackción, al menos, aumente automáticamente al cargar su AssemblyVersion alojado en AssemblyInfo: [assembly: AssemblyVersion (“1.0.0. *”] )]). A continuación, redirija su encuadernación de ensamblaje con la configuración de su aplicación:

En su caso, no necesitará el atributo “applyTo” de la configuración AssemblyBinding. Solo necesitas algo como:

        

Si tienen el mismo número de versión, la respuesta es que no puede. Si intenta cargar un ensamblaje que tenga el mismo nombre completo de ensamblaje (nombre, versión, clave) que un ensamblaje GAC, el CLR seleccionará el ensamblaje GAC cada vez.

Puede configurar DEVPATH para forzar la carga de un conjunto, consulte el texto del enlace

Esto no responde a su pregunta, ya que solo fue para uso de desarrollo e incluso entonces no fue realmente recomendable ya que no refleja el uso de producción. Sin embargo, pensé que lo compartiría de todos modos, ya que es bueno saberlo.

¿Has probado Assembly.LoadFromFile ()? Esto es algo manual, pero debe cargar su ensamblaje en la memoria antes de que sea necesario. .NET usará el que está en la memoria en lugar de buscarlo.

Otra forma sería si la asamblea local no estuviera firmada, podrías diferenciarla de esa manera.

Robar

Tuve un problema similar. Cambié el publicKeyToken de la dll de destino utilizando ildasm y ilasm para generar una nueva dll. Luego lo actualicé en la referencia del proyecto para señalar el nuevo dll. Los pasos que tomé están aquí .

Esto funcionó para mí.