¿Cómo determina Visual Studio qué copiar en el directorio de salida con soluciones multiproyecto?

votos
26

Digamos que tenemos una solución con la siguiente estructura:

  • Project.DAL - Capa de acceso a datos, depende de una biblioteca de nivel inferior, por ejemplo, Oracle.DataAccess w / copy local = true
  • Project.BLL - Capa de lógica de negocios, hace referencia a Project.DAL como proyecto
  • Project.UI - Capa UI, compila en ejecutable, hace referencia a Project.BLL, proyecto predeterminado

Cuando se compila Project.UI, VS es lo suficientemente inteligente como para copiar Project.DAL.dll al directorio de salida, pero no es lo suficientemente inteligente como para darse cuenta de que quería copiar Oracle.DataAccess en el directorio de salida y distribuirlo a los clientes. .

¿Alguien puede explicar por qué esto es así? ¿Es porque ve Oracle.DataAccess en el GAC y asume que los clientes también lo tendrán en el GAC?

No es gran cosa, pero es un poco molesto que cada vez que agregue una nueva referencia de ensamblaje, tenga que recordar configurarlo para copiar localmente y agregar un elemento para copiarlo en mi script de compilación también.

Publicado el 09/12/2008 a las 18:46
fuente por usuario
En otros idiomas...                            


4 respuestas

votos
27

Una cosa más.

Cuando no se utiliza el archivo DLL que se hace referencia en el código en absoluto, ignorará la CopyLocal y no copiará a su directorio de salida.

Respondida el 14/02/2010 a las 18:36
fuente por usuario

votos
25

Sí, Visual Studio copiará una DLL a la ruta de salida en cualquiera de las dos condiciones siguientes:

  1. La DLL se hace referencia explícitamente con CopyLocal = true
  2. Se hace referencia a la DLL sin CopyLocal o implícitamente a través de otra DLL referenciada y no está en el GAC

La razón por la que no se copiará localmente cuando el archivo está en GAC, es que cuando se resuelven nombres de ensamblado, el GAC tiene la prioridad más alta, es decir, incluso si tiene una copia local (diferente), se usará la versión del GAC.

Le sugiero que configure un directorio de biblioteca donde coloque todos los ensamblajes externos a los que se hace referencia. Luego, configura un script automático de MSBuild en una computadora (o VM) que no tiene el archivo Oracle gac'ed (ni Visual Studio instalado por ese motivo). De esta forma, el archivo se copiará en la compilación, y tendrá más control sobre lo que se hace que al usar VS.

Respondida el 02/02/2009 a las 17:49
fuente por usuario

votos
15

Tenía una extraña situación en que a pesar de que la asamblea era una referencia de proyecto y se hace referencia a "Copia Local" aparecer como "True" en la ventana de propiedades de referencia, el DLL no se está copiando en el directorio de salida. Tenía una versión anterior del archivo DLL en la GAC, pero yo no veo por qué esto debería evitar que la DLL está copiando.

He descubierto que al descargar el proyecto y manualmente editando el XML de referencia del proyecto de la siguiente manera:

<ProjectReference Include="..\SomeProject.csproj">
  <Project>{11111111-1111-1111-1111-111111111111}</Project>
  <Name>Some Project Name</Name>
  <Private>True</Private>
</ProjectReference>

La DLL se copia en el directorio ouput como se esperaba. He descubierto que sólo la creación de copia local True en la ventana de propiedades significaba que el <Private>elemento era totalmente ausente, pero en el caso de que sea establecido en false que estuvo presente con un valor de "falso".

Respondida el 13/05/2010 a las 16:47
fuente por usuario

votos
3

@RenniePet hay un enlace a un blog que describe la RenniePet método descrito en un comentario anterior aquí (si no desea editar el archivo de proyecto manualmente como se sugiere @Shaun):

http://blogs.msdn.com/b/jjameson/archive/2009/11/18/the-copy-local-bug-in-visual-studio.aspx

Respondida el 29/11/2013 a las 00:06
fuente por usuario

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more