Quando alguém deve usar uma referência de projeto em oposição a uma referência binária?

Question

Minha empresa possui uma biblioteca de código comum que consiste em muitos projetos de biblioteca de classes, além de projetos de teste de suporte.Cada projeto de biblioteca de classes gera um único binário, por ex.Company.Common.Serialization.dll.Como possuímos os binários compilados e testados, bem como o código-fonte, há um debate se nossos aplicativos de consumo devem usar referências binárias ou de projeto.

Alguns argumentos a favor das referências de projetos:

• As referências do projeto permitiriam aos usuários depurar e visualizar todo o código da solução sem a sobrecarga de carregar projetos/soluções adicionais.
• As referências do projeto ajudariam a acompanhar as alterações de componentes comuns comprometidas com o sistema de controle de origem, pois as alterações seriam facilmente identificáveis ​​sem a solução ativa.

Alguns argumentos a favor das referências binárias:

• As referências binárias simplificariam as soluções e acelerariam o tempo de carregamento das soluções.
• As referências binárias permitiriam que os desenvolvedores se concentrassem no novo código, em vez de se distrair potencialmente com o código que já está preparado e comprovadamente estável.
• As referências binárias nos forçariam a usar adequadamente nossas coisas, pois estaríamos usando a biblioteca comum, assim como aqueles fora de nossa organização seriam obrigados a fazer.
• Como uma referência binária não pode ser depurada (introduzida), seria forçado a replicar e corrigir problemas estendendo os projetos de teste existentes, em vez de testar e corrigir apenas no contexto do aplicativo consumidor.
• As referências binárias garantirão que o desenvolvimento simultâneo no projeto da biblioteca de classes não terá impacto no aplicativo consumidor, pois uma versão estável do binário será referenciada em vez de uma versão de influxo.Caberia ao líder do projeto a decisão de incorporar ou não uma versão mais recente do componente, se necessário.

Qual é a sua política/preferência quando se trata de usar referências binárias ou de projeto?

Answer 1

Parece-me que você cobriu todos os pontos principais.Tivemos uma discussão semelhante no trabalho recentemente e ainda não estamos decididos.

No entanto, uma coisa que analisamos é fazer referência aos arquivos binários, para obter todas as vantagens que você observa, mas ter os binários construídos por um sistema de compilação comum onde o código-fonte está em um local comum, acessível a partir de todas as máquinas do desenvolvedor ( pelo menos se eles estiverem na rede trabalhando), para que qualquer depuração possa de fato mergulhar no código da biblioteca, se necessário.

No entanto, na mesma nota, também marcamos muitas classes base com atributos apropriados para fazer o depurador ignorá-las completamente, porque qualquer depuração que você fizer em suas próprias classes (no nível que você está desenvolvendo) seria só será amplamente superado pelo código das bibliotecas básicas.Dessa forma, quando você acertar o Entre Ao depurar a tecla de atalho em uma classe de biblioteca, você ressurge no próximo trecho de código em seu nível atual, em vez de ter que percorrer toneladas de código de biblioteca.

Basicamente, eu definitivamente voto a favor (em termos SO) seus comentários sobre manter o código comprovado da biblioteca fora da vista do desenvolvedor normal.

Além disso, se eu carregar o arquivo de solução global, que contém todos os projetos e basicamente tudo, o ReSharper 4 parece ter algum tipo de problema coronário, já que o Visual Studio praticamente para.

Answer 2

Na minha opinião, o maior problema da utilização de referências de projetos é que não fornece aos consumidores uma base comum para o seu desenvolvimento.Estou assumindo que as bibliotecas estão mudando.Se for esse o caso, construí-los e garantir que eles tenham versão proporcionará um ambiente facilmente reproduzível.

Não fazer isso significará que seu código será quebrado misteriosamente quando o projeto referenciado for alterado.Mas apenas em algumas máquinas.

Answer 3

Costumo tratar bibliotecas comuns como essa como recursos de terceiros.Isso permite que a biblioteca tenha seus próprios processos de construção, testes de controle de qualidade, etc.Quando o controle de qualidade (ou quem quer que seja) "abençoa" um lançamento da biblioteca, ele é copiado para um local central disponível para todos os desenvolvedores.Cabe então a cada projeto decidir qual versão da biblioteca consumir, copiando os binários para uma pasta do projeto e usando referências binárias nos projetos.

Uma coisa importante é criar arquivos de símbolos de depuração (pdb) com cada compilação da biblioteca e disponibilizá-los também.A outra opção é realmente criar um armazenamento de símbolos local em sua rede e fazer com que cada desenvolvedor adicione esse armazenamento de símbolos à sua configuração do VS.Isso permitiria que você depurasse o código e ainda tivesse os benefícios de usar referências binárias.

Quanto aos benefícios que você menciona nas referências de projetos, não concordo com o seu segundo ponto.Para mim, é importante que os projetos consumidores saibam explicitamente qual versão da biblioteca comum estão consumindo e que tomem uma medida deliberada para atualizar essa versão.Essa é a melhor maneira de garantir que você não receba acidentalmente alterações na biblioteca que não tenham sido concluídas ou testadas.

Answer 4

quando você não quiser isso em sua solução ou tiver potencial para dividir sua solução, envie toda a saída da biblioteca para um diretório bin comum e faça referência lá.

Fiz isso para permitir que os desenvolvedores abram uma solução compacta que possua apenas o Domínio, testes e projetos Web.Nossos serviços win, coisas do silverlight e bibliotecas de controle da web estão em soluções separadas que incluem os projetos que você precisa ao olhar para eles, mas a nant pode construir tudo.

Answer 5

Acredito que sua pergunta seja sobre quando os projetos andam juntos na mesma solução;a razão é que os projetos na mesma solução devem ter referências de projeto entre si, e os projetos em soluções diferentes devem ter referências binárias entre si.

Tenho tendência a pensar que as soluções devem conter projetos desenvolvidos em estreita colaboração.Como seus assemblies de API e suas implementações dessas APIs.

A proximidade é relativa, no entanto.Um designer de um aplicativo, por definição, está intimamente relacionado ao aplicativo, mas você não gostaria de ter o designer e o aplicativo na mesma solução (isto é, se eles forem complexos).Você provavelmente desejaria desenvolver o designer em uma ramificação do programa que é mesclada em intervalos mais espaçados do que a integração diária normal.

Answer 6

Acho que se o projeto não faz parte da solução você não deveria incluí-lo aí...mas essa é apenas a minha opinião

Eu separo por conceito resumidamente