¿Cómo funciona Copy-local? log4net.dll no se está copiando en el directorio de salida MyProject

Me pregunto qué copia-local = verdadero para las referencias exactamente. ¿Copia el ensamblado al que se hace referencia junto con todas sus dependencias al directorio de salida?

Mi situación es la siguiente: tengo un contenedor de registro personalizado que utiliza log4net. Construyo un ensamblado de lanzamiento de MyLogWrapper.dll con el conjunto de referencia log4net.dll para copiar local verdadero. Hacer referencia a MyLogWrapper.dll desde MyProject con copy local set en true debería dar como resultado que log4net.dll se copiara también, ¿no? Solo estoy haciendo referencia a MyLogWrapper.dll y ninguna de sus dependencias en MyProject. log4net.dll no se está copiando al directorio de salida MyProject, pero sí a todas las demás dependencias de MyLogWrapper. ¿Cual podría ser el problema?

He hecho algunos experimentos más y parece que si elimino el ensamblado (log4net.dll) de GAC, comienza a copiarse localmente. ¿Alguien puede confirmar que este es el problema?

Desafortunadamente, parece que de acuerdo con la siguiente statement tomada de la documentación de MSDN, la funcionalidad CopyLocal no funciona como se esperaba para los ensamblados que ya están en el GAC.

Si implementa una aplicación que contiene una referencia a un componente personalizado que está registrado en el GAC, el componente no se implementará con la aplicación, independientemente de la configuración CopyLocal. En versiones anteriores de Visual Studio, podía establecer la propiedad CopyLocal en una referencia para asegurarse de que se implementó el ensamblado. Ahora, debe agregar manualmente el ensamblado a la carpeta \ Bin. Esto pone todo el código personalizado bajo escrutinio, reduciendo el riesgo de publicar código personalizado con el que no está familiarizado.

Se puede encontrar más información en la siguiente página que explica detalles sobre cómo funcionan las referencias de proyectos.

MSDN: referencias del proyecto

Después de hacer esta pregunta en MSDN aquí , parece que este comportamiento es por diseño. “Si implementa / copia una aplicación que contiene una referencia a un componente personalizado que está registrado en el GAC, el componente no se implementará / copiará con la aplicación, independientemente de la configuración de Copiar local”.

Hay un truco: establezca la referencia Copiar local en falso y luego nuevamente en verdadero, y Visual Studio agrega los metadatos privados automáticamente para esa referencia. Al menos, VS 2010 lo hace. Hace poco hice esto para resolver un problema con nuestro servidor TFS Build, que por alguna razón extraña tenía muchos componentes de Enterprise Library instalados en el GAC, por lo que tuvimos problemas importantes al implementar nuestro proyecto desde la carpeta TFS Drop. Ese truco falso / verdadero nos salvó.

¡Tienes que ser un poco cauteloso con la copia local ya que me ha sorprendido en el pasado!

Solo ocasionalmente, para un archivo .dll particular, silenciosamente no podrá copiarlo a la carpeta de comstackción. Por lo general, esto no aparece en una máquina de desarrollo, ya que las dll también suelen estar en el GAC (si ha instalado una herramienta / biblioteca de desarrollo que está utilizando para el desarrollo) y no se da cuenta hasta que se distribuye / se empaqueta en un instalador y los archivos necesarios faltan en una máquina cliente.

No hay mucha información sobre este error, pero este hilo lo demuestra para una biblioteca en particular: aquí .

Habiendo quedado atrapado por esto, creo que es una buena idea (generalmente, en cualquier caso) saber exactamente qué ensamblajes requiere tu proyecto y tener un script o acción automatizada similar que garantice que todos los componentes necesarios estén presentes, ya sea cuando construyas, o más probablemente cuando haces un instalador, o recolectas archivos para distribución,

Cuando la copia local se establece en verdadero, copiará todos los ensamblajes cuyo atributo local copy = tue para el directorio del contenedor de la aplicación.

En su caso, la dll podría estar utilizando la otra dll, por lo que también es necesario.

Descubrí que esto no se respeta más en Visual Studio 2015 con las referencias de proyectos si el proyecto al que se hace referencia tiene una dependencia con un ensamblado de GAC. El ensamblado de GAC siempre se copia en la salida del proyecto raíz y se respeta la copia de local = false únicamente con respecto a la salida del proyecto que contiene la referencia al dll de GAC.

Conectar comentarios