Was sind die Anwendung, die Auswirkungen einer netstandard Bibliothek je ein Metapaket?

Angenommen ich habe eine Klassenbibliothek, die ich möchte Ziel netstandard1.3, aber auch BigInteger. Hier ist ein triviales Beispiel - die einzige Quelle die Datei ist 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);            
    }
}

Zurück in die Welt der project.json würde ich den Gegner netstandard1.3 im frameworks Abschnitt, und haben eine explizite Abhängigkeit von System.Runtime.Numerics, z.B. version 4.0.1. Das nuget-Paket erstelle ich eine Liste nur, die Abhängigkeit.

In die schöne neue Welt der csproj-basierte dotnet-Werkzeuge (ich bin mit v1.0.1 des Kommandozeilen-tools) gibt es eine implizite Metapaket-Paket reference zu NETStandard.Library 1.6.1 bei der Ausrichtung netstandard1.3. Dies bedeutet, dass meine Projekt-Datei ist wirklich klein, denn es muss nicht die explizite Abhängigkeit:

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

... aber das nuget-Paket erzeugt eine Abhängigkeit von NETStandard.Library, was darauf schließen lässt, dass, um, um meine kleine Bibliothek, die Sie brauchen alles es.

Es stellt sich heraus, ich kann es deaktivieren, die Funktionalität mit DisableImplicitFrameworkReferences ist, dann fügen Sie in die Abhängigkeit manuell wieder:

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

Nun mein NuGet-Paket genau das sagt, was es abhängt. Intuitiv, das fühlt sich an wie ein "schlanker" - Paket.

Also, was ist der genaue Unterschied für einen Verbraucher, der meine Bibliothek? Wenn jemand versucht, es zu benutzen in einem UWP-Anwendung, nicht die zweite, "getrimmt" form von Abhängigkeiten bedeutet, dass die resultierende Anwendung wird kleiner sein?

Durch nicht dokumentieren DisableImplicitFrameworkReferences klar (soweit ich das gesehen habe; ich habe darüber gelesen,in einer Ausgabe) und durch die implizite Abhängigkeit der standardmäßig beim erstellen eines Projekts in Microsoft sind Förderung Benutzer nur hängt von der Metapaket installieren - aber wie kann ich sicher sein, dass keine Nachteile haben, wenn ich Herstellung eine Bibliothek-Klasse, Paket?

Es sollte angemerkt werden, dass die Abhängigkeit trimmen gearbeitet. Derzeit ist die Größe eines Hello World! eigenständige Anwendung ist reduziert auf < 10 MB.
10MB ist immer noch viel zu viel im Vergleich zu den < 20KB Größe eines klassischen .NET Framework C# Hallo-Welt-Projekt.

InformationsquelleAutor Jon Skeet | 2017-03-22

75

In der Vergangenheit haben wir Entwicklern die Empfehlung, nicht auf die meta -
Paket (NETStandard.Library) von NuGet-Pakete, aber anstatt Referenz
einzelne Pakete, wie System.Runtime und System.Collections. Die
Begründung war, dass wir dachten, der meta-Paket als Sammelbegriff für eine Reihe von
Pakete, waren die eigentlichen atomaren Bausteine der .NET-Plattform. Die
Annahme war: könnten wir am Ende die Schaffung eines anderen .NET-Plattform, die nur
unterstützt einige dieser atomaren Blöcke, aber nicht alle von Ihnen. Daher, je weniger Pakete Sie Referenz, die mehr tragbar Sie sein würden. Es wurden auch Bedenken bezüglich, wie unsere Werkzeuge Angebote mit groß Paket Graphen.

Voran, wir werden vereinfachen:
1. .NET Standard ist eine Atomare Baustein. In anderen Worten, neue Plattformen
  dürfen nicht Teilmenge .NET-Standard-Sie implementieren müssen, um alles.
2. Wir bewegen uns Weg von der Verwendung von Paketen um zu beschreiben, unsere Plattformen,
  inkl .NET Standard.
Bedeutet dies, werden Sie nicht haben, um auf eine NuGet-Pakete für .NET Standard
mehr. Sie äußerte Ihre Abhängigkeit von den mit den lib Ordner, das ist genau, wie
es hat arbeiteten für alle anderen .NET-Plattformen, insbesondere .NET Framework.

Aber jetzt unsere Werkzeuge werden immer noch brennen in der Referenz zu
NETStandard.Library. Es ist nicht schlimm, dass entweder, es wird nur geworden
redundante voran.

Ich werde aktualisieren, die FAQ auf die .NET-Standard-repo zu dieser Frage.

Update: Diese Frage ist jetzt Teil der FAQ.
- Vielen Dank - das macht sehr viel Sinn. Ich glaube, ich war teilweise verwirrt, weil in das Projekt.json-Welt, die ich hatte, um Abhängigkeiten, selbst wenn die Pakete waren logisch Teil des Rahmens ich war targeting (z.B. System.- Laufzeit.Numerik für netstandard1.3) - so dachte ich NETStandard.Die Bibliothek war wirklich zieht Sie in Abhängigkeiten.
- Mist. Ich mochte die Idee von Referenzen, Pakete, weil es das Gefühl, ich könnte nur als Referenz, was ich wollte, anstatt die ganze "Küche Spüle". Vielleicht bin ich nicht darüber nachdenke, richtig?
- Sie sind nicht unbedingt Gedanken über es der falsche Weg, aber die Frage ist, warum Sie kümmern. Es ist wichtig zu verstehen, die Plattform ist nicht endlos zusammensetzbar. Wenn Sie laufen in einem gemeinsamen framework-Umgebung (.NET Framework, Mono, .NET Core) alle diese bits sind sowieso vorhanden. Wenn Sie bauen eine eigenständige app (Xamarin, Mono -/.NET-Core-linker) können wir automatisch trim auf Basis Ihrer tatsächlichen Nutzung. So oder so, Sie nicht zu verlieren alles, was nicht durch verweisen auf kleinere Blöcke.
- Was ist mit der compiler-Regeln durchsetzen, wie verhindert einen Entwickler aus, die eine http-Anforderung in einer business-Logik-Projekt, indem Sie nicht, die Paket - Abfall Aufwand?
- Nicht unbedingt, aber wie wollen Sie durchsetzen, also was hält einen Entwickler aus der addition der Referenz? Ich würde schreiben ein Analysator eingespritzt wird, bei der Erstellung zu erzwingen Ebene Regeln und verursacht Fehler auf der build-Maschine.
InformationsquelleAutor Immo Landwerth
18

Sich das team zu empfehlen, herauszufinden, was die flachste Paket gesetzt wurde. Sie nicht mehr dies tun, und empfehlen, die Menschen bringen Sie nur in NETStandard.Bibliothek statt (im Falle von SDK-Stil Projekt, wird dies automatisch für Sie erledigt).

Habe ich nie bekommen ein völlig straight forward Antwort auf die Frage, warum das war, so erlauben Sie mir einige Vermutungen.

Der Hauptgrund ist wahrscheinlich, dass es Ihnen ermöglicht, diese zu verstecken, die Unterschiede in den Versionen der abhängigen Bibliotheken, die Sie sonst benötigt, um zu verfolgen, sich selbst beim verändern target frameworks. Es ist auch eine viel mehr benutzerfreundliche system mit dem SDK-basierte Projekt-Dateien, weil Sie ehrlich gesagt brauchen keine Referenzen um ein ordentliches Stück von der Plattform (wie Sie verwendet, um mit dem Standard-Referenzen in Desktop-land, insbesondere mscorlib).

Durch das drücken der meta-definition von was es bedeutet, ein netstandard Bibliothek oder eine netcoreapp Anwendung in den entsprechenden NuGet-Pakets, das Sie nicht haben, um zu bauen ohne Besondere Kenntnisse in der definition dieser Dinge wie Visual Studio (oder dotnet new) sieht.

Statische Analyse verwendet werden könnten, die während der Veröffentlichung zu begrenzen, werden die mitgelieferten DLLs, das ist etwas, was Sie heute tun, wenn dabei die native Kompilierung für UWP (wenn auch mit einigen Einschränkungen). Sie tun das nicht, heute für .NET-Core, aber ich vermute, es ist eine Optimierung, die Sie betrachtet habe (wie auch die Unterstützung von native code).

Es hindert Sie nichts daran, dass Sie sehr selektiv, wenn Sie so wählen. Ich glaube, du wirst finden, dass du bist fast der einzige der dies tut, auch die Niederlagen der Zweck (da es werde davon ausgegangen werden, jeder bringt in NETStandard.Library oder Microsoft.NETCore.App).
- Ich Stimme zu, es ist definitiv Niederlagen der Zweck, sobald es mehr als eine Abhängigkeit, wenn jedes von Ihnen bringt in NETStandard.Library. Es ist etwas selbst zu erfüllen, natürlich... wenn ich hängt NETStandard.Library für Noda-Zeit, das bedeutet andere Bibliothek baut auf der Noda-Zeit hat keinen Grund zu trimmen, Abhängigkeiten, etc. Es ist verlockend, wählerisch zu sein, jetzt (Noda Time ist in Richtung 2.0), dann entspannen Sie sich ein wenig später auf einmal Konventionen etabliert haben - Wechsel von selektiven zu lib-basiert, wäre ein non-breaking ändern, nehme ich an, aber das Gegenteil ist nicht wahr.
InformationsquelleAutor Brad Wilson
8

Sollten Sie nicht brauchen, deaktivieren Sie die implizite Referenz. Alle Plattformen, die Bibliothek wird in der Lage sein zu laufen, wird bereits die Assemblys, die NETStandard.Library Abhängigkeit erfordern würde.

Den .NET Standard Library) ist eine Spezifikation, die einen Satz von Referenz-Assemblys, die Sie kompilieren vor, das eine Reihe von APIs, die garantiert sind, bestehen auf einer Reihe von Plattformen und Versionen-Plattformen, wie .NET Core oder die .NET-Framework. Es ist nicht eine Implementierung dieser Versammlungen, die gerade genug von der API-Form, damit der compiler erfolgreich bauen Sie Ihre code.

Die Umsetzung für diese APIs werden von einer Ziel-Plattform, wie .NET-Core, Mono-oder .NET-Framework. Sie liefern mit der Plattform, denn Sie sind ein wesentlicher Bestandteil der Plattform. So gibt es keine Notwendigkeit, geben Sie eine kleinere Abhängigkeit gesetzt - alles ist schon da, werde Sie nicht ändern.

Den NETStandard.Library - Paket bietet diese Referenz Baugruppen. Ein Punkt der Verwirrung ist die Versionsnummer - das Paket ist version 1.6.1, aber das bedeutet nicht, dass ".NET Standard 1.6". Es ist nur die version des Pakets.

Die version von der .NET-Standard-Sie ' re-targeting kommt aus dem Ziel-framework geben Sie in Ihrem Projekt.

Wenn Sie eine Bibliothek an und möchte es weiter ausführen .NET-Standard 1.3, solltest du die Referenz NETStandard.Library Paket, derzeit version 1.6.1. Aber noch wichtiger ist, Ihre Projekt-Datei mit der Ziel -netstandard1.3.

Den NETStandard.Library Paket geben Sie einen anderen Satz von Referenz-Baugruppen je nach Ziel-framework-moniker (ich bin Vereinfachung für die Kürze, aber denke lib\netstandard1.0, lib\netstandard1.1 und Abhängigkeit von Gruppen). Also, wenn Sie Ihre Projekt-Ziele netstandard1.3 erhalten Sie die 1.3 reference assemblies. Wenn Sie als Ziel netstandard1.6 kriegt man den 1.6 reference assemblies.

Wenn Sie erstellen eine Anwendung, die Sie kann nicht als Ziel der .NET Standard. Es macht keinen Sinn - Sie kann nicht laufen, die auf eine Spezifikation. Stattdessen Zielen Sie konkrete Plattformen, wie net452 oder netcoreapp1.1. NuGet kennt die Zuordnung zwischen diesen Plattformen und die netstandard Ziel-framework-moniker, so weiß die lib\netstandardX.X Ordner sind kompatibel mit der Zielplattform. Es weiß auch, dass die Abhängigkeiten von NETStandard.Library zufrieden sind, die von der Zielplattform, also nicht ziehen in andere Baugruppen.

Ähnlich wie beim erstellen eines standalone .NET-Core-app .NET-Standard-Implementierung Baugruppen kopiert mit der app. Der Verweis auf NETStandard.Library bringt nicht in jedem anderen neuen apps.

Beachten Sie, dass dotnet veröffentlichen erstellt eine eigenständige Anwendung, aber es wird nicht derzeit nicht tun, trimmen, und veröffentlichen alle Baugruppen. Dies wird erfolgt automatisch durch Werkzeuge, so wieder, trimmen Abhängigkeiten, die in Ihrer Bibliothek nicht helfen hier.

Der einzige Ort, den ich mir vorstellen kann, wo es könnte helfen, entfernen Sie die NETStandard.Library Referenz ist, wenn Sie auf einer Plattform nicht unterstützt die .NET Standard, und Sie können finden, ein Paket von der .NET Standard, wo alle transitiven Abhängigkeiten kann die Ausführung auf der Zielplattform. Ich vermute, es gibt nicht viele Pakete, die würde passen, dass bill.
- Wenn Sie dotnet publish zu einer bestimmten Laufzeit, es werden alle Abhängigkeiten, einschließlich dotnet.exe (oder Ihr Linux - /OS X-äquivalent). Das sollte eine völlig eigenständige Bereitstellung an diesem Punkt. Schauen Sie sich die Ergebnisse für einen unit-test-Projekt: gist.github.com/bradwilson/6cc5a8fdfa18230aa6c99b851fb85c01
- Ich denke, der Letzte Absatz ist genau das Thema... und wenn es nicht ein Problem ist, warum benötigen wir verschiedene Versionen von netstandard1.x überhaupt? Wenn jede Plattform hat alles, was in netstandard1.6, warum auch müssen netstandard1.0 als ein Konzept? Das ist das verwirrend Teil für mich.
- Und die Liste der Plattformen, die das unterstützen .NET-Standard umfasst keine der vielen Unity-Plattformen.
- Richtig, aber bedeutet das nicht, dass, wenn Sie eine Anwendung bereitstellen, mithilfe einer Bibliothek, die hängt davon ab, NETStandard.Bibliothek auf Windows 8.1, die Sie am Ende bringen Sie einen laden, der extra-Pakete, die in netstandard1.3-netstandard1.6? Das ist genau das, was ich versuche zu vermeiden - ich brauche nicht alles in NETStandard.Bibliothek, also warum würde ich wollen, dass Anwendungen, die die Installation auf älteren Versionen bis zum Ende einschließlich der Pakete, die Sie nicht benötigen? Es fühlt sich an wie ich muss sein Missverständnis etwas...
- Hmm. Es beginnt Sinn zu machen, aber können wir es konkreter? Meine Rechner-Bibliothek (im Sinne der Frage) muss BigInteger, aber das ist nicht Teil der netstandard1.3. Was passiert - entweder in der Verpackung - Szenario- wenn das ist verwendet als Teil einer Anwendung, welche Ziele sich eine Plattform, die nur unterstützt netstandard1.3 und früher? Vermutlich, dass die Plattform nicht System.Runtime.Numerics, also eine Abhängigkeit, die in der Anwendung Paket. Wenn ich hing auf NETStandard.Library, wie Sie ist, die Abhängigkeit gezogen, andere aber nicht? Oder würde es überhaupt nicht funktionieren?
- (Wird Ihre Geduld viel geschätzt, btw. Ich hoffe wirklich, dass dies alles Sinn, und dass es helfen wird, die viele, viele Entwickler...)
- Lassen Sie uns weiter, diese Diskussion im chat.
- (Heads-up, die zusammen - Matt und ich werde weiter diskutieren, dann schlage ich vor, wir aktualisieren seine Antwort, um sicherzustellen, dass alles wichtige da ist.)
- Sieht aus wie dotnet veröffentlichen erlaubt die Erstellung einer standalone-Anwendung, obwohl es auch aussieht, es nicht tun, trimmen, und veröffentlicht alles. Richtig. Wir planen auf die Bewältigung dieser mit einem linker. Wir denken nicht der richtige Weg ist, zu Fragen, alle Entwickler zur hand trimmen Ihren Graphen.
- Ich aktualisiert meine Antwort zu bedecken, was wurde in den Kommentaren und der anschließenden Diskussion. Ich bin das löschen meiner alten Kommentare
InformationsquelleAutor citizenmatt

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.