Melhor prática para uma biblioteca .NET multi-alvo

Question

Estou planejando lançar uma biblioteca de código aberto (MIT) .NET, mas também incluir DLLs para facilitar as pessoas para que elas não precisem compilar tudo sozinho.

Minha biblioteca é muito simplista nos tipos de referência, a única dependência real parece ser .NET 3.0 ou superior (já que se refere Func<T> e similar).

Quero que minha biblioteca seja utilizável por vários alvos, incluindo o .NET 4.0 Server, .NET 3.5 Server, Windows Phone 7 Silverlight, Silverlight normal, XNA (telefone), XNA (Windows) e XNA (Xbox 360).

Certifico -me de não usar nenhum tipo que não esteja disponível nas plataformas que estou direcionando, por exemplo HashSet<T> Não está disponível no Windows Phone 7, então não estou usando.

Vou precisar fazer projetos diferentes e, portanto, várias DLLs para cada um desses alvos ou há alguma maneira de produzir uma DLL comum para que todos usem?

Answer 1

Houve uma palestra no PDC este ano sobre fazer esse tipo de coisa:

Este é o vídeo e Estes são os slides.

Answer 2

Arquivos de projeto separados com arquivos de origem comum e compartilhados é o caminho a seguir. Verifique se os projetos estão configurados para construir para diferentes pastas de saída (por exemplo, não \bin\Debug, mas \CF\bin\debug) para evitar aborrecimentos ao consumir a biblioteca de vários alvos (como um projeto de desktop e dispositivo).

o OpenNetcf.ioc Framework é um exemplo disso - ele suporta a área de trabalho, CF, Windows Phone e Monotouch todos com os mesmos arquivos de origem, mas separam arquivos de projeto por plataforma. Tentar compilar em uma única montagem binária que é utilizável em todos eles era muito confusa e difícil de manter.

O principal ponto da dor aqui é manter todos os arquivos do projeto sincronizados quando você adiciona/altera arquivos e certifica -se de que todos eles sempre compilam. Um servidor de construção pode fazer isso se você tiver acesso à automação (que o CodePlex infelizmente não expõe).

Answer 3

Eu faço algo semelhante com uma biblioteca que tem como alvo .NET e Silverlight. Eu tenho um único conjunto de arquivos de origem e arquivos de projeto separados que vinculam aos mesmos arquivos compartilhados.

Às vezes, uso a compilação condicional para incluir recursos apenas para .NET e não Silverlight, ou para tirar proveito dos recursos disponíveis no .NET que levam a uma implementação mais agradável e a uma implementação de volta para o Silverlight, onde possui lacunas.

A mesma abordagem pode ser usada para as outras plataformas que você menciona - um conjunto de arquivos de origem, mas um arquivo de projeto separado por destino da plataforma.

Se você usar uma ferramenta de construção como MSBuild ou NANT, poderá produzir a compilação Produza todas as DLLs para todas as plataformas de destino quando executar o script.

Answer 4

Olhe para a Ferramentas de biblioteca portáteis (Última atualização: 17/06/2011) Extensão de Equipe BLC (Microsoft) e esta introdução Artigo do MSDN (Última atualização: agosto de 2011).

Answer 5

Eu sugeriria uma biblioteca para cada uma das plataformas. Deixe-me explicar.

Digamos o completo .NET Framework inclui vários recursos, métodos que não fazem parte do .NET Compact Framework Como aquele que você pode encontrar com Windows CE e smartphones. Portanto, para aproveitar completamente a carga total de possibilidades de cada plataforma, eu aproveitaria uma biblioteca comum muitas interfaces e você implementa essas interfaces dentro de um .NET Framework platform specific Biblioteca de classes que permitirá que você aproveite totalmente o que é oferecido em uma plataforma específica.

Por outro lado, se a reutilização comum de código e, por uma questão de manutenção, você pode preferir ir com uma única biblioteca "dothe-them-all". Sob tais requisitos, você precisará estar plenamente ciente de cada uma das diferenças entre as muitas plataformas que deseja apoiar.

Essa é obviamente uma questão importante de análise e arquitetura, como ambos sofrerão a falta de uma plataforma sobre a outra.

Veja como eu procederia na frente de tal situação:

1. Eu investigaria as diferenças entre a estrutura .NET específica da plataforma;
2. Eu deixaria de lado tudo (conforme necessário) os objetos comuns que você acha que pode precisar;
3. Eu destacaria as diferenças, ou seja, objetos que você pode usar em uma plataforma, mas não a outra;

Esta é uma análise orgânica que você terá que executar para ver o que está por vir a seguir.

Isto é, para algum tipo de abordagem em cascata.

---

Quanto a uma abordagem de scrum, se eu posso dizer isso, pois isso sugere empirismo, eu diria que tente uma única biblioteca comum para todos eles e veja o que você pode fazer. Se você se deparar com algumas coisas que absolutamente não pode fazer, pode ser relevante apenas criar outra biblioteca de classes que dependeria da sua biblioteca de "fazer tudo", para que você tenha um bloco comum para cada plataforma, então alguns outros outros específicos Bibliotecas para o que você não pode fazer no comum. Faça isso e veja quais vantagens você obteve e encontre uma maneira de sair quando chega a hora de ser mais específico.