Каковы последствия применения библиотеки netstandard в зависимости от метапакета?

Предположим, у меня есть библиотека классов, которую я хочу нацелить на netstandard1.3, но также используйте BigInteger. Вот тривиальный пример-единственный исходный файл Adder.cs:

using System;
using System.Numerics;

namespace Calculator
{
    public class Adder
    {
        public static BigInteger Add(int x, int y)
            => new BigInteger(x) + new BigInteger(y);            
    }
}

в мире project.json, Я бы элемент netstandard1.3 на frameworks раздел, и имеют явную зависимость от System.Runtime.Numerics, например, версия 4.0.1. Пакет NuGet я создать список всего, что зависимость.

в дивном новом мире инструментов dotnet на основе csproj (я использую v1.0.1 из инструменты командной строки) есть неявное пакет Базовый пакет до NETStandard.Library 1.6.1 при использовании netstandard1.3. Это означает, что мой файл проекта действительно мал, потому что ему не нужна явная зависимость:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netstandard1.3</TargetFramework>
  </PropertyGroup>
</Project>

... но производимый пакет nuget имеет зависимость от NETStandard.Library, что предполагает, что для того, чтобы использовать мою небольшую библиотеку, вам нужно все там.

оказывается, я могу отключить эту функциональность, используя DisableImplicitFrameworkReferences, затем снова добавьте зависимость вручную:

<Project Sdk="Microsoft.NET.Sdk">    
  <PropertyGroup>
    <TargetFramework>netstandard1.3</TargetFramework>
    <DisableImplicitFrameworkReferences>true</DisableImplicitFrameworkReferences>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="System.Runtime.Numerics" Version="4.0.1" />
  </ItemGroup>    
</Project>

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

так в чем же разница для потребителя из моей библиотеки? Если кто-то пытается использовать его в приложении UWP, означает ли вторая, "обрезанная" форма зависимостей, что полученное приложение будет меньше?

не документируя DisableImplicitFrameworkReferences ясно (насколько я видел; я читал об этом на вопрос) и неявных зависимостей по умолчанию при создании проекта в Microsoft поощрение пользователи просто зависят от метапакета - но как я могу быть уверен, что у этого нет недостатков, когда я создаю пакет библиотеки классов?

94
.net-core .net-standard nuget

3 ответов

в прошлом мы дали разработчикам рекомендацию не ссылаться на meta пакет (NETStandard.Library) из пакетов NuGet, но вместо ссылки индивидуальные пакеты, как System.Runtime и System.Collections. Этот обоснованием было то, что мы думали о мета-пакете как о стенографии для группы пакеты, атомный строительные блоки .Net платформы. Этот предположение было: мы можем создать другую платформу .NET, которая только поддерживает некоторые из этих атомных блоков, но не все из них. Следовательно, чем меньше пакетов вы ссылаетесь, тем более портативным вы будете. Были также опасения относительно того, как наш инструмент имеет дело с большими графиками пакетов.

двигаясь вперед, мы упростим этот:

  1. .NET Standard-это атомарный строительный блок. Другими словами, новые платформы не разрешено подмножество .NET Standard - они должны реализовать все это.

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

это означает, что вам не придется ссылаться на какие-либо пакеты NuGet для .NET Standard больше. Вы выразили свою зависимость с папкой lib, которая именно так он работал для всех других платформ .NET, в частности .NET Framework.

однако, прямо сейчас наш tooling все еще сгорит в ссылке к NETStandard.Library. В этом нет никакого вреда, это просто станет избыточные перемещения вперед.

я обновлю часто задаваемые вопросы на .Объем стандартного РЕПО включить этот вопрос.

обновление: этот вопрос сейчас часть FAQ.

70

команда использовала, чтобы рекомендовать выяснить, какой самый тонкий набор пакетов был. Они больше не делают этого, и рекомендуют людям просто принести в NETStandard.Вместо этого библиотека (в случае проекта в стиле SDK это будет сделано автоматически для вас).

Я никогда не получал абсолютно прямого ответа о том, почему это было, поэтому позвольте мне сделать некоторые обоснованные догадки.

основной причиной, вероятно, будет то, что она позволяет им скрывать различия в версиях зависимые библиотеки, которые в противном случае потребовалось бы отслеживать при изменении целевых фреймворков. Это также гораздо более удобная система с файлами проектов на основе SDK, потому что вам, честно говоря, не нужны ссылки, чтобы получить приличный кусок платформы (так же, как вы привыкли к ссылкам по умолчанию в Desktop-land, особенно mscorlib).

путем нажатия мета-определения того, что значит быть netstandard библиотека, или netcoreapp заявление в соответствующие Пакет NuGet, им не нужно создавать какие-либо специальные знания в определении этих вещей как Visual Studio (или dotnet new) их видит.

статический анализ может использоваться во время публикации для ограничения отгруженных библиотек DLL, что они делают сегодня при выполнении собственной компиляции для UWP (хотя и с некоторыми оговорками). Они не делают этого сегодня для .NET Core, но я предполагаю, что это оптимизация, которую они рассмотрели (а также поддержка собственного кода).

нет ничего не позволять тебе быть очень избирательным, если ты так хочешь. Я верю, что вы обнаружите, что вы почти единственный, кто это делает, что также разрушает цель (поскольку предполагается, что все приносят NETStandard.Library или Microsoft.NETCore.App).

17

вам не нужно отключать неявную ссылку. Все платформы, на которых библиотека сможет работать, уже будут иметь сборки, которые NETStandard.Library потребуется зависимость.

стандартная библиотека .NET-это спецификация, набор ссылочных сборок, которые вы компилируете против, который предоставляет набор API, которые гарантированно существуют на известном наборе платформ и версий платформ, таких как .NET Core или .NET Framework. Это не реализация эти сборки, как раз достаточно формы API, чтобы позволить компилятору успешно построить ваш код.

реализация этих API обеспечивается целевой платформой, такой как .NET Core, Mono или .NET Framework. Они поставляются с платформой, потому что они являются неотъемлемой частью платформы. Поэтому нет необходимости указывать меньший набор зависимостей - все уже есть, вы этого не измените.

на NETStandard.Library пакет предоставляет эти ссылки сборки. Одним из моментов путаницы является номер версии-пакет версии 1.6.1, но это не означает ".NET Standard 1.6". Это просто версия пакета.

версия .NET Standard, на которую вы ориентируетесь, происходит из целевой платформы, указанной в вашем проекте.

если вы создаете библиотеку и хотите, чтобы она работала на .NET Standard 1.3, вы должны ссылаться на , в настоящее время в версии 1.6.1. Но что более важно, ваш файл проекта будет элемент netstandard1.3.

на NETStandard.Library пакет даст вам другой набор ссылочных сборок в зависимости от вашего целевого фреймворка (я упрощаю для краткости, но думаю lib\netstandard1.0, lib\netstandard1.1 и группы зависимостей). Поэтому, если ваш проект нацелен netstandard1.3, вы получите 1.3 ссылочные сборки. Если вы нацелены netstandard1.6, вы получите 1.6 сборки.

если вы создаете приложение, вы не можете нацелить Стандарт .NET. Это не имеет смысла - вы не можете работать по спецификации. Вместо этого вы ориентируетесь на конкретные платформы, такие как net452 или netcoreapp1.1. NuGet знает отображение между этими платформами и netstandard target framework моникеры, так что знает, какие lib\netstandardX.X папки совместимы с вашей целевой платформы. Он также знает, что зависимости NETStandard.Library удовлетворяются целевой платформой, поэтому не будут тянуть в каких-либо других сборках.

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

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

только место я могу себе представить, где это может убрать NETStandard.Library ссылка, Если вы ориентируетесь на платформу, которая не поддерживает стандарт .NET, и вы можете найти пакет из стандарта .NET, где все транзитивные зависимости могут работать на вашей целевой платформе. Я подозреваю, что не так много пакетов, которые бы соответствовали этому счету.

6