Dependências

A principal maneira de adicionar dependências a uma biblioteca .NET é referenciar pacotes NuGet. As referências de pacote NuGet permitem que você reutilize e aproveite rapidamente a funcionalidade já escrita, mas elas são uma fonte comum de atrito para desenvolvedores do .NET. O gerenciamento correto de dependências é importante para impedir que as alterações em outras bibliotecas do .NET quebrem sua biblioteca do .NET e vice-versa!

Dependências de diamante

É comum que um projeto .NET tenha várias versões de um pacote em sua árvore de dependência. Por exemplo, um aplicativo depende de dois pacotes NuGet, cada um deles depende de uma versão diferente do mesmo pacote. Uma dependência de diamante agora existe no grafo de dependência do aplicativo.

No momento do build, o NuGet analisa todos os pacotes dos quais um projeto depende, incluindo as dependências das dependências. Quando várias versões de um pacote são detectadas, as regras são avaliadas para escolher uma. A unificação de pacotes é necessária porque a execução de versões lado a lado de um assembly no mesmo aplicativo é problemática no .NET.

A maioria das dependências de losangos é facilmente resolvida. No entanto, podem criar problemas em determinadas circunstâncias:

• Referências conflitantes do pacote NuGet impedem que uma versão seja resolvida durante a restauração do pacote.
• Alterações significativas entre as versões causam bugs e exceções em tempo de execução.
• O assembly do pacote tem um nome forte, a versão do assembly é alterada e o aplicativo está em execução no .NET Framework. Redirecionamentos de associação de assembly são necessários.

Não é possível saber quais pacotes serão usados junto com o seu. Uma boa maneira de reduzir a probabilidade de uma dependência de losango provocar falha na sua biblioteca é minimizar o número de pacotes dos quais você depende.

✔️ Examine sua biblioteca do .NET em busca de dependências desnecessárias.

Intervalos de versão de dependência do NuGet

Uma referência de pacote especifica o intervalo de pacotes válidos que ele permite. Normalmente, a versão de referência do pacote no arquivo de projeto é a versão mínima e não há no máximo.

<!-- Accepts any version 1.0 and above. -->
<PackageReference Include="ExamplePackage" Version="1.0" />

As regras que o NuGet usa ao resolver dependências são complexas, mas o NuGet , por padrão , procura a versão mais baixa aplicável. O NuGet prefere a versão mais baixa aplicável em vez de usar a mais alta disponível, pois a mais baixa terá menos problemas de compatibilidade.

Devido à regra de versão mais baixa aplicável do NuGet, não é necessário colocar uma versão superior ou intervalo exato em referências de pacote para evitar obter a versão mais recente. O NuGet já tenta encontrar a versão mais baixa e mais compatível para você.

<!-- Accepts 1.0 up to 1.x, but not 2.0 and higher. -->
<PackageReference Include="ExamplePackage" Version="[1.0,2.0)" />

<!-- Accepts exactly 1.0. -->
<PackageReference Include="ExamplePackage" Version="[1.0]" />

Os limites de versão superior farão com que o NuGet falhe se houver um conflito. Por exemplo, uma biblioteca aceita exatamente 1.0, enquanto outra biblioteca requer 2.0 ou superior. Embora alterações da falha possam ter sido introduzidas na versão 2.0, uma dependência de versão do limite superior ou estrita garantirá um erro.

❌ NÃO tenha referências de pacote do NuGet sem versão mínima.

❌ EVITE referências de pacote NuGet que exigem uma versão exata.

❌ EVITE referências de pacote NuGet com um limite superior de versão.

Para obter mais informações, consulte o controle de versão do pacote.

Pacotes de origem compartilhada do NuGet

Uma maneira de reduzir as dependências externas do pacote NuGet é referenciar pacotes de origem compartilhados. Um pacote de origem compartilhada contém arquivos de código-fonte incluídos em um projeto quando referenciados. Como você está apenas incluindo arquivos de código-fonte compilados com o restante do projeto, não há nenhuma dependência externa e possibilidade de conflito.

Os pacotes de origem compartilhada são ótimos para incluir pequenas partes da funcionalidade. Por exemplo, você pode referenciar um pacote de origem compartilhado de métodos auxiliares para fazer chamadas HTTP.

<PackageReference Include="Microsoft.Extensions.Buffers.Testing.Sources" PrivateAssets="All" Version="1.0" />

Os pacotes de origem compartilhada têm algumas limitações. Eles só podem ser referenciados por PackageReference, portanto, projetos mais antigos packages.config são excluídos. Além disso, os pacotes de origem compartilhada só podem ser usados por projetos com o mesmo idioma. Devido a essas limitações, os pacotes de origem compartilhada são mais usados para compartilhar a funcionalidade em um projeto de software livre.

✔️ CONSIDERE fazer referência a pacotes de origem compartilhada para pequenas partes internas da funcionalidade.

✔️ CONSIDERE tornar seu pacote de um pacote de origem compartilhado se ele oferecer pequenas funcionalidades internas.

✔️ FAÇA referência a pacotes de origem compartilhados com PrivateAssets="All".

Essa configuração informa ao NuGet que o pacote deve ser usado apenas no momento do desenvolvimento e não deve ser exposto como uma dependência pública.

❌ NÃO tenha tipos de pacote de origem compartilhados em sua API pública.

Tipos de origem compartilhada são compilados no assembly de referência e não podem ser trocados entre os limites de assembly. Por exemplo, um tipo de fonte IRepository compartilhada em um projeto é um tipo separado da mesma fonte IRepository compartilhada em outro projeto. Tipos em pacotes de origem compartilhados devem ter uma visibilidade internal.

❌ NÃO publique pacotes de origem compartilhados para NuGet.org.

Os pacotes de origem compartilhados contêm código-fonte e só podem ser usados por projetos com o mesmo tipo de idioma. Por exemplo, um pacote de origem compartilhada em C# não pode ser usado por um aplicativo F#.

Publique pacotes de origem compartilhada em um feed local ou MyGet para consumi-los internamente em seu projeto.

AnteriorPróximo