Como você compartilhar dependências externas entre soluções do Visual Studio?

Question

Eu tenho um Java plano, de forma que eu estou acostumado a ter o Maven lidar com o problema de todos em torno de baixar e manter dependências atualizado.Mas no .NET ambiente, eu ainda não encontrei uma boa forma de gerenciar todas essas dependências externas.

O principal problema aqui é que eu produzir em massa de soluções e todos eles tendem a depender mesmo de terceiros dll.Mas eu não quero manter cópias separadas de cada componente em cada solução.Então, eu preciso de uma maneira de unir todos os diferentes soluções para o mesmo conjunto de dll.

Percebi que uma solução poderia ser a de incluir as bibliotecas externas em um "projeto de biblioteca", que é incluído em todas as soluções e permitir que os outros projetos de referências-los por isso.(Ou apenas certifique-se referência a dll externa a partir do mesmo local para todos os projetos.)

Mas há maneiras melhores de fazer isso?(De preferência, usando algum tipo de plug-in para o Visual Studio.)

Eu olhei para o O Visual Studio Dependência Manager e ele parece ser um jogo perfeito, mas alguém tem tentado isso de verdade?Eu também vi a .NET portas do Maven, mas infelizmente, eu não estava muito impressionado com o estado desses.(Mas, por favor, vá em frente e recomendá-los a ninguém, se você acha que eu deveria dar-lhes outra oportunidade.)

Então, o que seria a forma mais inteligente para resolver este problema?

Atualização:

Eu percebi que eu precisava para explicar o que eu quis dizer com links para o mesmo conjunto de dll.

Uma das coisas que eu estou tentando fazer aqui é para evitar que as diferentes soluções são referência de diferentes versões de cada componente.Se eu atualização de um componente para uma nova versão, ele deve ser atualizado para todas as soluções na próxima compilação.Isto iria obrigar-me a certifique-se de que todas as soluções estão atualizados com os mais recentes componentes.

Atualização 2: Note que essa é uma velha pergunta antes ferramentas como NuGet ou OpenWrap existiu.Se alguém está disposto a oferecer mais up-to-date, por favor, vá em frente e eu vou mudar o aceite de resposta.

Answer 1

1. Encontrar algum lugar para armazenar os conjuntos.Por exemplo, eu a loja .Net núcleo de assemblies, como por exemplo:

   • <branch> etFX\2.0527\*
   • <branch> etFX\3.0\*
   • <branch> etFX\3.5\*
   • <branch> etFX\Silverlight 2\*
   • <branch> etFX\Silverlight 3\*

2. Use o ReferencePath propriedade em MSBuild (ou AdditionalReferencePath na Equipe de Compilação) para apontar os seus projetos de forma adequada caminhos.Para uma questão de simplicidade e de fácil manutenção, eu tenho 1 *.metas arquivo que sabe sobre cada um diretório;todos os meus projetos de Importação de arquivo.

3. Certifique-se de que o seu controle de versão estratégia (ramos, fusão, local<->servidor de mapeamentos) mantém os caminhos relativos entre seus projetos e a sua referência caminhos constante.

EDITAR

Em resposta para a actualização em questão, deixe-me acrescentar mais uma etapa:

4) certifique-se de que cada referência de assembly em cada arquivo de projeto usa o todo .Net forte nome e nada mais.

Ruim:

<Reference Include="Microsoft.SqlServer.Smo">
  <SpecificVersion`>False</SpecificVersion>
  <HintPath>..\..\..\..\..\..\..\Program Files (x86)\Microsoft SQL Server\100\Shared\Microsoft.SqlServer.Smo.dll</HintPath>
</Reference>

Bom:

<Reference Include="Microsoft.SqlServer.Smo, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL" />

Vantagens do último formato:

• Usando um HintPath em um ambiente de desenvolvimento colaborativo, inevitavelmente, levar a situações em que "ele trabalha para mim", mas não em outros.Especialmente o seu servidor de compilação.Omitindo o obriga a obter a sua referência caminhos corretos ou ele não vai compilar.
• Usando um fraco nome convida a possibilidade de "DLL hell." Uma vez que você usar nomes fortes em seguida, é seguro ter várias versões do mesmo conjunto em sua referência caminhos porque o linker irá carregar apenas aqueles que correspondem a cada critério.Além disso, se você decidir atualizar algumas montagens no local (em vez de adicionar cópias) e, em seguida, você será notificado de quaisquer alterações significativas no tempo de compilação em vez de sempre que os erros começam a vir.

Answer 2

Além do que todo mundo está dizendo, basicamente se resume a duas coisas:

1. Garantir que todos os desenvolvedores tenham as mesmas versões de bibliotecas externas
2. Certificando -se de que todos os desenvolvedores tenham as bibliotecas externas localizadas no mesmo local (pelo menos, em relação ao código -fonte)

Como Richard Berg aponta, você pode usar o ReferencePath e/ou o ActerreferencePath para ajudar a resolver o #2. Se você estiver usando o MSBuild em seu processo de construção (no nosso caso, estamos usando o CruiseControl em vez da formação da equipe da MS), também poderá passar a Referência no Path na linha de comando. Para resolver o número 1, eu encontrei SVN: Externos para ser útil (se você estiver usando SVN).

Minha experiência com o MAVEN é que é muito exagerado para a maioria dos propósitos.

Answer 3

Eu geralmente tenho uma estrutura de pastas separada no controle de origem para dependências extrenais ou internas, e esses gargalhadores têm as montagens de acordo com a construção ou o número da versão, por exemplo

Public External Libraries Nunit 2.6

ou

Public Internal Libraries Logger 5.4.312

E dentro das soluções, todos os projetos que precisam usar qualquer uma das dependências apenas adicionam uma referência a esse conjunto nas pastas internas ou extrenais públicas.