Quelles sont les implications pour les applications d’une bibliothèque netstandard en fonction d’un méta-paquet?

Question

Supposons que j'ai une bibliothèque de classes qui je veux cible netstandard1.3, mais aussi utiliser BigInteger. Voici un exemple trivial - le seul fichier source est - 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);            
    }
}

De retour dans le monde de l' project.json, je cible netstandard1.3 dans la frameworks section, et explicite la dépendance de l' System.Runtime.Numerics, par exemple, la version 4.0.1. Le package nuget je créer listera que la dépendance.

Dans le meilleur des mondes csproj à base de dotnet outillage (je suis en v1.0.1 des outils de ligne de commande) il y a un implicite méta-paquet paquet de référence pour NETStandard.Library 1.6.1 lorsque le ciblage netstandard1.3. Cela signifie que mon fichier de projet est vraiment petit, car il n'a pas besoin de la dépendance explicite:

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

... mais le package nuget produit a une dépendance sur l' NETStandard.Library, ce qui suggère que, pour utiliser ma petite bibliothèque, vous devez tout .

Il s'avère que je peux désactiver cette fonctionnalité à l'aide de DisableImplicitFrameworkReferences, puis ajouter dans la dépendance à nouveau manuellement:

<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>

Maintenant, mon package NuGet dit exactement ce dont il dépend. Intuitivement, cela se sent comme un "maigre".

Alors, quelle est la différence exacte pour un consommateur de ma bibliothèque? Si quelqu'un essaie de l'utiliser dans un UWP demande, la deuxième, "garnis" forme de dépendances dire que l'application qui en résulte sera plus petits?

En ne documentant pas DisableImplicitFrameworkReferences clairement (autant que je l'ai vu; j'ai lu à ce sujet dans un numéro) et en faisant de l'implicite de la dépendance de la valeur par défaut lors de la création d'un projet, de Microsoft sont en encourageant les utilisateurs à juste dépendra de la méta-paquet - mais comment puis-je être sûr que n'ont pas les inconvénients quand je suis produisant une bibliothèque de classes du package?

Answer 1

Dans le passé, nous avons donné aux développeurs la recommandation de ne pas référence à la méta ensemble (NETStandard.Library) à partir de packages NuGet, mais au lieu de référence emballages individuels, comme System.Runtime et System.Collections. L' la justification que nous avons pensé à la méta-paquet comme une abréviation pour un tas de les paquets qui ont été la réelle atomique blocs de construction de l' .NET plate-forme. L' hypothèse: on va peut-être créer un autre .NET plate-forme uniquement prend en charge certains de ces atomique blocs, mais pas tous d'entre eux. Par conséquent, le nombre de paquets de référence, le plus portable que tu aimerais être. Il y avait aussi des préoccupations concernant la façon dont notre outillage traite avec de gros paquets graphiques.

Aller de l'avant, nous allons simplifier ce:

1. .NET Standard est atomique bloc de construction. En d'autres termes, de nouvelles plateformes ne sont pas autorisés à sous-ensemble .NET Standard, ils ont à mettre en œuvre tous.

2. Nous nous dirigeons loin de l'aide de paquets pour décrire nos plates-formes, y compris .NET Standard.

Cela signifie, que vous n'aurez pas à référencer les packages NuGet .NET Standard plus. Vous avez exprimé votre dépendance avec le dossier lib, ce qui est exactement la façon dont il a travaillé pour tous les autres .NET plates-formes, en particulier .NET Framework.

Cependant, pour l'instant, notre outillage sera toujours graver dans la référence à NETStandard.Library. Il n'y a pas de mal à qui que ce soit, il va juste devenir redondant aller de l'avant.

Je vais mettre à jour la FAQ sur le .NET Standard pensions de titres à inclure cette question.

Mise à jour: Cette question est maintenant de la partie de la FAQ.

Answer 2

L'équipe a utilisé à recommander à comprendre le plus mince paquet était. Ils ne le font plus, et de recommander des gens il suffit d'apporter NETStandard.La bibliothèque de la place (dans le cas d'un SDK-projet de style, ce sera fait automatiquement pour vous).

Je n'ai jamais eu un totalement direct réponse pourquoi il en était, alors permettez-moi de faire quelques hypothèses.

La principale raison est probablement que cela leur permet de masquer les différences dans les versions des bibliothèques dépendantes que vous ce qui serait autrement nécessaire de suivre vous-même lors de la modification de la cible des cadres. C'est aussi un moyen beaucoup plus convivial de système avec le kit de développement basé sur des fichiers de projet, parce que franchement vous n'avez pas besoin de références pour obtenir un morceau décent de la plate-forme (comme vous l'habitude d'utiliser avec les références par défaut dans le Bureau de la terre, particulièrement mscorlib).

En poussant la méta-définition de ce que signifie être un netstandard bibliothèque, ou un netcoreapp application appropriée dans le package NuGet, ils n'ont pas à construire des connaissances spéciales dans la définition de ces choses que Visual Studio (ou dotnet new) voit.

L'analyse statique pourrait être utilisé lors de la publication de limiter le expédiés Dll, ce qui est quelque chose qu'ils font aujourd'hui, quand on fait de compilation native pour UWP (quoique avec quelques mises en garde). Ils ne le faisons pas aujourd'hui .NET de Base, mais je présume que c'est une optimisation ils ont considéré (ainsi que le soutien à du code natif).

Il n'y a rien qui vous empêche d'être très sélectif, si vous le souhaitez. Je crois que vous constaterez que vous êtes presque le seul à le faire, aussi, qui l'emporte sur l'objectif (depuis ça va être assumé tout le monde est d'amener de l' NETStandard.Library ou Microsoft.NETCore.App).

Answer 3

Vous ne devriez pas avoir besoin de désactiver la référence implicite. Toutes les plates-formes que la bibliothèque sera capable de fonctionner sur n'aura déjà les assemblées que l' NETStandard.Library de dépendance.

L' .NET de la Bibliothèque Standard est une spécification, un ensemble de référence assemblées que vous compilez contre qui fournit un ensemble d'Api qui sont garantis d'exister sur une série de plates-formes et versions des plates-formes, telles que .NET de Base ou dans le .NET Framework. Ce n'est pas une mise en œuvre de ces assemblées, juste assez de la forme d'API pour permettre au compilateur de réussir à construire votre code.

La mise en œuvre de ces Api sont fournies par une plate-forme cible, tels que .NET Core, Mono ou .NET Framework. Ils livrés avec la plate-forme, car ils sont une partie essentielle de la plate-forme. Donc, il n'est pas nécessaire de spécifier une petite dépendance à définir - tout est déjà là, vous n'aurez pas à changer cela.

L' NETStandard.Library paquet fournit ces assemblées. D'un point de confusion est le numéro de version - le paquet est la version 1.6.1, mais cela ne signifie pas ".NET Standard 1.6". C'est juste la version du paquet.

La version de l' .NET Standard que vous ciblez vient de le framework cible que vous spécifiez dans votre projet.

Si vous êtes à la création d'une bibliothèque et souhaitez l'exécuter .NET la Norme 1.3, vous feriez de référence de l' NETStandard.Library package, actuellement à la version 1.6.1. Mais plus important encore, votre fichier de projet viserait netstandard1.3.

L' NETStandard.Library forfait vous donnera un ensemble différent de référence assemblées en fonction de votre cible cadre surnom (je simplifie pour des raisons de concision, mais pensez - lib\netstandard1.0, lib\netstandard1.1 et la dépendance des groupes). Donc, si votre projet vise netstandard1.3, vous aurez la 1.3 référence assemblées. Si vous ciblez netstandard1.6, vous obtiendrez le 1.6 référence assemblées.

Si vous êtes à la création d'une application, vous ne pouvez pas cibler les .NET Standard. Il ne fait pas de sens, vous ne pouvez pas exécuter sur un cahier des charges. Au lieu de cela, vous ciblez les plates-formes en béton, tels que l' net452 ou netcoreapp1.1. NuGet connaît la correspondance entre ces plateformes et l' netstandard cible cadre de monikers, de sorte que connaît lib\netstandardX.X des dossiers sont compatibles avec votre plate-forme cible. Il sait aussi que les dépendances de l' NETStandard.Library sont satisfaits par la plate-forme cible, afin de ne pas tirer dans tous les autres assemblées.

De même, lors de la création d'une application autonome .NET de Base d'application, l' .NET Standard de mise en œuvre assemblées sont copiés avec votre application. La référence à l' NETStandard.Library ne met pas dans d'autres applications.

Notez que dotnet publish permettra de créer une application autonome, mais il ne peut pas ne dispose pas actuellement de faire le parage et le publiera toutes les assemblées. Ce sera gérée automatiquement par l'outillage, donc encore une fois, le parage des dépendances dans votre bibliothèque ne va pas aider ici.

Le seul endroit où je peux imaginer où il peut aider à supprimer l' NETStandard.Library de référence est si vous visez une plate-forme qui ne prend pas en charge les .NET Standard, et vous pouvez trouver un paquet de la .NET Standard où toutes les dépendances transitives pouvez exécuter sur votre plate-forme cible. Je soupçonne il n'y a pas beaucoup de paquets qui correspondent à ce projet de loi.