Зависимости

Основным способом добавления зависимостей в библиотеку .NET является ссылка на пакеты NuGet. Ссылки на пакеты NuGet позволяют быстро использовать уже написанные функции, но они часто являются источником проблем для разработчиков .NET. Правильное управление зависимостями важно, чтобы предотвратить ситуации, когда изменения в других библиотеках .NET нарушают работу вашей библиотеки .NET и наоборот!

Зависимости алмазов

В проекте .NET обычно используется несколько версий пакета в дереве зависимостей. Например, приложение зависит от двух пакетов NuGet, каждый из которых зависит от другой версии одного пакета. Теперь зависимость алмазов существует в графе зависимостей приложения.

Во время сборки NuGet анализирует все пакеты, от которых зависит проект, включая зависимости зависимостей. Когда обнаруживаются несколько версий пакета, правила оцениваются для выбора одной. Объединение пакетов необходимо, так как выполнение параллельных версий сборки в том же приложении проблематично в .NET.

Большинство зависимостей алмазов легко разрешаются; однако они могут создавать проблемы в определенных обстоятельствах:

• Конфликтующие ссылки на пакет NuGet препятствуют определению версии во время восстановления пакета.
• Критические изменения между версиями вызывают ошибки и исключения во время выполнения.
• Сборка пакета имеет строгое имя, изменена версия сборки, а приложение работает в .NET Framework. Требуются редиректы привязки сборок.

Невозможно знать, какие пакеты будут использоваться вместе с вашими собственными. Хороший способ уменьшить вероятность нарушения алмазной зависимости — свести к минимуму количество пакетов, от которых вы зависите.

✔️ Проверьте библиотеку .NET для ненужных зависимостей.

Диапазоны версий зависимостей NuGet

Ссылка на пакет указывает диапазон допустимых пакетов, которые он разрешает. Как правило, эталонная версия пакета в файле проекта является минимальной версией, и максимальное значение отсутствует.

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

Правила, используемые NuGet при разрешении зависимостей, являются сложными, но NuGet по умолчанию ищет самую низкую применимую версию. NuGet предпочитает самую низкую применимую версию по сравнению с самой доступной, так как самый низкий будет иметь наименьшие проблемы совместимости.

Из-за правила NuGet о минимальной применимой версии не требуется устанавливать максимальную версию или точный диапазон для ссылок на пакеты, чтобы избежать обновления до последней версии. NuGet уже пытается найти самую низкую, наиболее совместимую версию для вас.

<!-- 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]" />

Ограничения верхних версий могут привести к сбою NuGet в случае конфликта. Например, одна библиотека принимает ровно 1.0, а для другой библиотеки требуется 2.0 или более поздней версии. Хотя критические изменения, возможно, были введены в версии 2.0, зависимость версии строгого или верхнего предела гарантирует ошибку.

❌ Не допускайте наличия ссылок на пакеты NuGet без указания минимальной версии.

❌ Избегайте ссылок на пакеты NuGet, требующие точной версии.

❌ Избегайте ссылок на пакеты NuGet с верхним ограничением версии.

Дополнительные сведения см. в разделе "Управление версиями пакетов".

Пакеты общедоступного исходного кода NuGet

Одним из способов уменьшения внешних зависимостей пакета NuGet является ссылка на общие исходные пакеты. Общий исходный пакет содержит файлы исходного кода, которые включаются в проект при ссылке на него. Так как вы просто включаете файлы исходного кода, скомпилированные с остальной частью проекта, нет внешней зависимости и вероятности конфликта.

Общие исходные пакеты отлично подходят для включения небольших компонентов функций. Например, можно ссылаться на общий исходный пакет вспомогательных методов для выполнения http-вызовов.

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

Общие исходные пакеты имеют некоторые ограничения. Ссылаться можно только с помощью PackageReference, поэтому старые проекты packages.config исключаются. Кроме того, общие исходные пакеты доступны только для проектов с тем же языком. Из-за этих ограничений общие исходные пакеты лучше всего использовать для совместного использования функциональных возможностей в проекте с открытым исходным кодом.

✔️ Рассмотрите возможность ссылки на общие исходные пакеты для небольших внутренних компонентов функций.

✔️ Рекомендуется сделать пакет общим исходным пакетом, если он предоставляет небольшие внутренние компоненты функций.

✔️ Используйте общие исходные пакеты с PrivateAssets="All".

Этот параметр сообщает NuGet, что пакет должен использоваться только во время разработки и не должен предоставляться как общедоступная зависимость.

❌ Не используйте общие типы пакетов источников в вашем общедоступном API.

Типы общих источников компилируются в ссылочную сборку и не могут передаваться через границы сборок. Например, тип общего источника IRepository в одном проекте является отдельным типом одного и того же общего источника IRepository в другом проекте. Типы в общих исходных пакетах должны иметь internal видимость.

❌ Не публикуйте общие исходные пакеты в NuGet.org.

Общие исходные пакеты содержат исходный код и могут использоваться только проектами с тем же типом языка. Например, общий исходный пакет C# нельзя использовать приложением F#.

Опубликуйте общие исходные пакеты в локальном веб-канале или MyGet , чтобы использовать их внутри проекта.

НазадДалее