Vous n'avez rien fait de mal, ce qui est susceptible de se produire. Si vous voulez rien de plus que votre propre DLL être ajoutés à un nouveau .NET Framework de projet, vous avez pour cible .NET Standard 2.0 pour votre bibliothèque d'attente pour une .NET Framework version qui prend en charge à la fois de l'API et de l'assemblée versions - qui va être 4.7.2 (tout en .NET Framework 4.7.1 prend en charge toutes les Api, il y avait des bugs avec la façon dont certains assemblages sont versionnés et donc de l'outillage (VS 2017 15.5+) va ajouter des assemblées de le corriger).
Ce que vous voyez sont les effets secondaires du comment .NET Standard est construit et le soutien pour les prises en charge des cadres est mis en œuvre. C'est également différente .NET version Standard vous permet de cibler et de l'outillage utilisé pour faire référence à la bibliothèque de package.
Dans .NET Standard < 2.0, vous faites référence à l' NETStandard.Library meta-paquet qui à son tour références supplémentaires (System.*) des paquets. Ces paquets contiennent la référence à des assemblées qui composent le ".NET Contrat Standard" - un ensemble d'Api et de l'assemblée des noms + les versions.
Lorsque le package NuGet vous créer pour .NET Standard 1.0-1.6 est référencée par une application, chacun de ces paquets n'apporte pas la référence assemblées, mais plutôt de la mise en œuvre des assemblages pour le cadre de l'application des objectifs.
Pour .NET de Base, ces dernières correspondent aux assemblages qui font déjà partie de l'exécution afin que les fichiers DLL ne finira pas à côté de l'application. Ce qui a changé cependant, quand une nouvelle série de paquets a été publié pour .NET de Base 1.1 (NETStandard.Library version 1.6.1). Il en est résulté dans les applications conçues pour .NET Core 1.0 finir obtenir plus récente de la mise en œuvre des assemblages qui sont censés être inclus dans .NET de Base 1.1 (heureusement, 1.1 a ensuite fait le "support à long terme" version depuis qui a déclenché une discussion sur les assemblys qui font partie de la LTS promesse).
Sur .NET Framework de ces bibliothèques (avec quelques exceptions comme System.Net.Http) ne font pas beaucoup - ils juste à l'avant du système des assemblées. Ainsi, par exemple, le "contrat" qui définit System.Object est définie dans un System.Runtime.dll de l'assemblée. Si l' System.Runtime.dll le fichier, vous vous retrouvez avec dans une .NET Framework application contient un System.Runtime.dll qui contient le type à l'avenir .NET Framework mscorlib.dll. .NET de Base contient déjà un autre System.Runtime.dll qui fait quelque chose de différent pour cette plate-forme. Ce mécanisme permet à un fichier DLL à travailler sur les deux plates-formes, puisque celles-type de vers l'avant et supplémentaires implémentations d'assurer un "contrat" (types + assemblages + assemblée versions) à travailler sur les deux implémentations.
.NET Standard 2.0 visant à réduire le nombre de colis et les Dll nécessaires et aussi de supprimer nécessitant des mises à jour de NETStandard.Library chaque fois qu'un nouveau .NET de Base version est disponible.
Donc, pour .NET Standard 2.0 et .NET Core 2.0, l' NETStandard.Library package apporte seulement des assemblies de référence pour la compilation d'un code à un projet, mais le résultat de package NuGet ne dépend plus de ce package. Ainsi, lorsque vous créez une bibliothèque de ciblage .NET Standard 2.0 et de le publier, il n'aura pas de NuGet dépendances (sauf si vous en ajouter d'autres).
Dans la logique de ce "bibliothèques de prise en charge" à apporter lors de la consommation d'un .NET de la bibliothèque Standard a été déplacé à l'outillage qui est utilisé lors de la construction. Alors, quand une bibliothèque qui contient une référence à un netstandard.dll est ajouté à une .NET Framework projet, la capacité de l'outil puis ajouter le soutien nécessaire de la Dll de la version de .NET Framework utilisé. Cela a été fait pour .NET Standard 2.0 ainsi que .NET Standard 1.5+ depuis .NET Framework 4.6.1 a été rétroactivement fait compatible avec .NET Standard 2.0 (1.4 a été précédemment) par le biais de ces types de fichiers DLL. Le même outillage assure également que même si les packages NuGet sont en quelque sorte amené à un tel projet d'application, tout .NET Standard de mise en œuvre de bibliothèques apporté via NuGet sont retirés de la construction. Donc, si vous faites référence à un .NET Standard 1.0 package NuGet qui a été construit lors de l' .NET Core 1.0 a été publié, tous ses NuGet dépendances sont garnis et vous obtenez les bibliothèques de support livré avec la construction de l'outillage à la place.
L'idée était que .NET Framework 4.7.1 contiendrait toutes les assemblées "boîte de réception", pour qu' netstandard.dll, System.Runtime.dll etc. font partie de .NET Framework et tout .NET Standard 1.0-2.0 fichier DLL serait "juste travail", le problème est que ces "boîte de réception" fichiers dll a une trop faible, le numéro de version pour certaines assemblées ainsi, les bibliothèques ne charge ce problème a été résolu par la modification de l'outillage à nouveau pour inclure les fichiers DLL avec plus de numéros de version dans le soutien des bibliothèques qui, à son tour avant de la "boîte de réception" .NET Framework assemblées. Ceci est prévu pour être fixé .NET Framework 4.7.2.
