Como o visual studio determinar o que copiar para o diretório de saída com soluções multi-projeto?

votos
26

Vamos dizer que temos uma solução com a seguinte estrutura:

  • Project.DAL - camada de acesso a dados, depende de uma biblioteca de nível inferior, por exemplo Oracle.DataAccess w / cópia local = true
  • Project.BLL - camada de lógica de negócios, referente ao Project.DAL como projeto
  • Project.UI - camada de interface do usuário, compila para o executável, referente ao Project.BLL, projeto padrão

Quando Project.UI é compilado, VS é inteligente o suficiente para copiar Project.DAL.dll no diretório de saída, mas não é inteligente o suficiente para descobrir o que eu queria Oracle.DataAccess a serem copiados para o diretório de saída, bem como para distribuição aos clientes .

Alguém pode explicar por que isso acontece? Será que é porque ele vê Oracle.DataAccess no GAC e assume que os clientes irão tê-lo no GAC também?

Não é que de um grande negócio, mas é meio irritante que cada vez que eu adicionar uma nova referência de montagem, eu tenho que lembrar-se de configurá-lo para copiar local e adicionar um item para copiá-lo no meu script de construção também.

Publicado 09/12/2008 em 18:46
fonte usuário
Em outras línguas...                            


4 respostas

votos
27

Mais uma coisa.

Quando você não usar a DLL referenciado no seu código em tudo, ele irá ignorar a CopyLocal e não irá copiar para o seu diretório de saída.

Respondeu 14/02/2010 em 18:36
fonte usuário

votos
25

Sim, Visual Studio irá copiar a DLL para o caminho de saída em qualquer uma das duas condições abaixo:

  1. O DLL é referenciado explicitamente com CopyLocal = verdadeiro
  2. A DLL é referenciada sem CopyLocal ou implicitamente através de algum outro DLL referenciado e não está no GAC

A razão pela qual não irá copiar-local quando o arquivo está no GAC, é que quando resolver nomes de montagem do GAC tem maior prioridade, ou seja, mesmo se você tiver uma cópia local (diferente), será utilizada a versão do GAC.

Eu sugiro que você criar um diretório da biblioteca onde você coloca todos os conjuntos externos que são referenciados. Em seguida, você configurar um script automático MSBuild em um computador (ou VM) que não tem o arquivo do Oracle gac'ed (nem Visual Studio instalado para esse amor). Dessa forma, o arquivo será copiado para a construção, e você terá mais controle sobre o que é feito do que ao usar VS.

Respondeu 02/02/2009 em 17:49
fonte usuário

votos
15

Eu tive uma situação estranha em que, mesmo que a montagem era uma referência de projeto e foi referenciado com "Copy Local" aparecendo como "True" na janela de propriedades de referência, a DLL não estava sendo copiados para o diretório de saída. Eu tinha uma versão anterior da DLL no GAC, mas eu não vejo por que isso deve impedir a DLL que está sendo copiado.

Descobri que, descarregando o projeto e manualmente editar o XML referência de projeto como segue:

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

A DLL foi copiado para o diretório ouput como esperado. Descobri que apenas a criação Copy Local como True na janela de propriedades significou o <Private>elemento estava completamente ausente, mas no caso de ele ser definido como falso que esteve presente com um valor de "falso".

Respondeu 13/05/2010 em 16:47
fonte usuário

votos
3

@RenniePet Aqui está um link para um blog que descreve a RenniePet método descrito em um comentário anterior (se você não deseja editar o arquivo de projeto manualmente, como @Shaun sugerido):

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

Respondeu 29/11/2013 em 00:06
fonte usuário

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