2008-11-06 11 views
62

Tengo un ensamblado .NET que (por razones fuera de mi control) debe estar en el GAC Sin embargo, otro programa 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: de todos modos hay que decirle a .NET: simplemente use ESTA DLL, aquí en este directorio - ignore lo que encuentre en el GAC o en cualquier otro lado.¿Cómo puedo forzar .NET para usar una copia local de un ensamblaje que está en el GAC

Respuesta

1

¿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 el ensamblado local no estuviera firmado, podría diferenciarlo de esa manera.

Rob

+3

Bonita idea, pero no, no funciona - LoadFile() carga el ensamblaje correcto, pero cuando se utiliza el ensamblaje al que se hace referencia, todavía se carga del GAC. :( – EMP

+2

No hay una forma administrada de cargar una copia local de un ensamblado GAC – JaredPar

+0

Realmente decepcionante que no hay manera. –

43

Asegúrese de que la Asamblea GAC ​​y la Asamblea local de tener diferentes números de versión (no es una mala idea dejar que el número de compilación, al menos, incremento automático por su AssemblyVersion en AssemblyInfo-cardado salvaje: [assembly: AssemblyVersion ("1.0.0. *")]). A continuación, redirigir su estructura de encuadernación mediante configuración de tu aplicación:

En su caso, usted no necesitará el "AppliesTo" atributo de la configuración assemblyBinding. Solo necesita algo como:

<runtime> 
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> 
     <dependentAssembly> 
      <assemblyIdentity name="YourAssembly" publicKeyToken="AAAAAAAAAAAA" culture="neutral"/> 
      <bindingRedirect oldVersion="0.0.0.0-5.2.1.0" newVersion="5.0.8.1"/> 
     </dependentAssembly> 
    </assemblyBinding> 
</runtime> 
+2

¿Puede evitar el uso de esta redirección de encuadernación recompilando la aplicación para usar la nueva versión del dll, o es ¿Algun cambio de configuración siempre es necesario? – user37078

+0

Establecer la parte de revisión de su número de versión en '*' no hace que aumente automáticamente. La documentación de MSDN en [AssemblyVersionAttribute] (http://msdn.microsoft.com/en-us/library /system.reflection.assemblyversionattribute.aspx) indica que debe ser aleatorio, pero en la práctica Visual Studio usa el número de segundos desde la medianoche dividido por 2. –

+0

Entonces, ¿qué está diciendo es que cada ensamblado se volverá a versionar en cada compilación, incluso si no tiene cambios, solo para que podamos romper la dependencia de GAC? ¿Para qué sirve el redireccionamiento obligatorio de ensamblaje? Lo único que se me ocurre es que podría usarse en prod, de modo que si su proyecto hace referencia a 5.0.8.3453 en lugar de 5.0.8.1 en GAC solo porque estaba remodelando la versión en dev sin hacer cambios, será redirigido a 5.0.8.1. ¿Está bien? Clunky, pero no veo otra forma de evitar esto. –

23

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.

+11

@downvoter cuidado de explicar? – JaredPar

+1

No sé quién votó negativamente, pero experimento lo mismo que dice @JaredPar y me vuelve loco. Se carga desde el GAC. Tengo dos ensamblajes con el mismo nombre completo, y quiero cargar mi versión ligeramente modificada. AGAVE. –

+0

has probado esto? http://www.aip.im/2013/04/how-to-force-iis-asp-net-to-use-assembly-from-the-bin-folder-instead-of-gac/ – Niloofar

9

puede establecer el DEVPATH para obligar a cargar un ensamblado, consulte link text

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

1

Tuve un problema similar. Cambié el publicKeyToken del dll de destino utilizando ildasm y ilasm para generar un nuevo dll. Luego lo actualicé en la referencia del proyecto para señalar el nuevo dll. Los pasos que tomé son here.

Esto funcionó para mí.

Cuestiones relacionadas