Trabalhando com bibliotecas comuns/utilitárias

Question

Na empresa em que trabalho, temos um projeto de "Utilitário" que é referenciado por praticamente todos os aplicativos que construímos.Tem muitas coisas como NullHelpers, ConfigSettingHelpers, Common ExtensionMethods etc.

A maneira como trabalhamos é que, quando queremos fazer um novo projeto, obtemos a versão mais recente do projeto do controle de origem, adicionamos-a à solução e, em seguida, referenciamos o projeto a partir de quaisquer novos projetos adicionados à solução.

Isso funcionou bem, no entanto, houve alguns casos em que as pessoas fizeram "alterações significativas" no projeto comum, o que funciona para elas, mas não funciona para outras.

Tenho pensado que, em vez de adicionar a biblioteca comum como referência do projeto, talvez devêssemos começar a desenvolver a biblioteca comum como uma dll independente e publicar versões diferentes e direcionar uma versão específica para um projeto específico, para que as alterações possam ser feitas sem qualquer risco. para outros projetos usando a biblioteca comum.

Dito tudo isso, estou interessado em ver como outras pessoas fazem referência ou usam suas bibliotecas comuns.

Answer 1

Isso é exatamente o que estamos fazendo.Temos um projeto utilitário que possui algumas funções úteis não específicas do projeto.Aumentamos a versão manualmente (menor), construímos o projeto na versão Release, assinamos e colocamos em um local compartilhado.

As pessoas então usam a versão específica do biblioteca.

Se alguns métodos úteis forem implementados em alguns projetos específicos que possam ser incluídos no projeto Utilitário principal, colocamos os em uma classe auxiliar especial no projeto e os marcamos como possíveis candidatos a Utilitário (simples //TODO).Ao final do projeto, analisamos os candidatos e se persistirem, passamos para a página principal biblioteca.

Mudanças significativas são proibidas e marcamos métodos e classes como [Obsoletos], se necessário.

Mas isso realmente não importa porque aumentamos a versão a cada publicação.

Espero que isto ajude.

Answer 2

Usamos ramificação no controle de origem;todo mundo usa o branch head até fazer um lançamento.Quando eles ramificarem a versão, eles também ramificarão o projeto de utilitários comuns.

Além disso, nosso projeto de utilidades possui seus próprios testes unitários.Dessa forma, outras equipes podem saber se quebrariam a construção de outras equipes.

Claro, ainda temos problemas como você menciona ocasionalmente.Mas quando uma equipe verifica uma mudança que quebra a construção de outra equipe, isso geralmente significa que o contrato para aquele método/objeto foi quebrado em algum lugar.Vemos isso como oportunidades para melhorar o desenho do projeto de serviços públicos comuns...ou pelo menos escrever mais testes unitários :/

Answer 3

Eu tive o EXATO mesmo problema!

Eu costumava usar referências de projetos, mas tudo parece dar errado, quando, como você disse, você tem muitos projetos fazendo referência a isso.

Agora compilo em uma DLL e defino a propriedade CopyLocal para a referência da DLL como falsa após a primeira compilação (caso contrário, acho que ela pode substituir subprojetos e se tornar uma bagunça).

Acho que, em teoria, provavelmente deveria ser GAC, mas se for um problema que está mudando muito (como o meu), isso pode se tornar problemático.