Qual é a melhor maneira de lidar com referências em um aplicativo .NET

Recentemente, no trabalho, encontramos um problema em que marcamos / ramificamos um projeto e tivemos alguns problemas de compilação devido às referências de dll / project que apontavam para a estrutura de pastas antiga.

Criamos uma pasta 'bin externo' para cada um dos projetos e copiamos as DLLs referenciadas para essas pastas. Essa é a melhor maneira ou existe um padrão específico do setor para lidar com isso?

Eu diria que o nuget é a melhor maneira de lidar com dependências.

O nuget pode gerenciar versões E baixar automaticamente as dependências do servidor local do nuget.

É muito fácil criar / configurar um servidor local. Simplesmente crie um novo projeto vazio do ASP.NET e instale o nuget-serverpacote nuget (usando nuget;).

Isso também significa que você não precisará verificar todas as dependências e / ou gerenciar suas versões usando o TFS.

Não é verdade - a Microsoft diz que a melhor maneira de lidar com referências é criar seu projeto em uma solução enorme. Sim, eu sei, eles realmente querem dizer isso também.

A equipe de padrões e práticas reuniu suas melhores práticas em relação ao TFS, mas isso se aplica a construções gerais. Existem 3 tipos de configuração de solução, a "1 solução grande", uma abordagem particionada que é muito parecida com a forma como a maioria das pessoas costumava gerenciar construções criando por sua vez e copiando artefatos em um diretório comum (que não é auxiliado pelo .NET não ter um caminho 'include' ou 'library' para todo o servidor) e uma configuração de soluções múltiplas, que é uma versão mais complexa da particionada.

Eles dizem

In general you should:

    Use a single solution strategy unless the resulting solution is too large to load into Visual Studio.
    Use multiple solutions to create specific views on sub-systems of your application.
    Use multiple solutions to reduce the time it takes to load a solution and to reduce build time for developers.

Para o TFS, eles recomendam ramificar qualquer projeto externo dentro do seu projeto, em vez de confiar no mapeamento da área de trabalho que é mais parecido com o externo do subversion. Pessoalmente, acho que o conselho deles não é uma prática recomendada, mas suponho que eles estejam tentando minimizar os problemas de compilação que você terá ao usar as referências.

Eu tive problemas com as compilações do .NET que tentam atalho para o sistema criando apenas o necessário, uma compilação noturna que faz tudo e copia todos os novos assemblies para um diretório, era a melhor maneira de todos se manterem sincronizados - principalmente os testadores. Observe que isso realmente se aplica apenas aos aplicativos .NET, enquanto os C ++ ainda funcionam porque não possuem assemblies com versão ou aspectos semelhantes que podem causar problemas ao chamar componentes. Essa abordagem funciona bem, mas nem sempre é possível supor que construções parciais são aceitáveis, vaping a coisa toda e reconstrução são mais seguras.

Isso depende de como sua solução está estruturada e de quais são os recursos do software de controle de versão. Anteriormente, costumávamos manter um projeto não construído / ignorado em nossas soluções que continham documentação e uma pasta específica para bibliotecas referenciadas por terceiros. Como fazia parte da solução, o caminho para esses arquivos pode ser referenciado usando o caminho relativo. Depois que nos mudamos para o TFS 2010, nos livramos desse projeto e simplesmente adicionamos um diretório "Suporte" na pasta da solução no projeto de equipe paralelo às nossas ramificações principais. Em ambos os casos, a versão de controle de origem da biblioteca acaba ficando no mesmo local, relativamente, independentemente de como os desenvolvedores tenham suas máquinas configuradas.

Ao usar o subversion para controle de versão, você pode utilizar a propriedade "externals" para esse propósito. Isso permite que você mantenha uma cópia local de uma DLL compartilhada em um caminho relativo próximo ao seu projeto atual. Isso facilita a referência a essa DLL por um caminho relativo do arquivo que não muda, mesmo quando você altera o diretório principal do seu projeto para uma pasta diferente. Os externos permitem definir também qual versão ou revisão específica incluir.