NuGet: Force-Projekt spezifischere Zielrahmen über netstandard

Question

Short Version

ich ein Paket Autor, welche Ziele .NET Standard-1.3 und 1.6 zu wählen. Meine 1.6 Build-Referenzen System.Runtime.Loader. Dieses Paket hat eine placeholder für das MonoAndroid-Framework, was bedeutet, dass mein NuGet-Paket jetzt nicht in Android 7.x-Projekten geladen werden kann.

Mein .NET Standard 1.3 Build hat diese Abhängigkeit nicht. Wie kann ich NuGet zwingen, den netstandard-1.3-Build für Android-Projekte anstelle von netstandard-1.6 zu laden?

Details

Wenn ich versuche, und unser aktuelles Paket in einem Android-7-Projekt zu laden, die project.json verwendet, ich die folgende Fehlermeldung angezeigt:

System.Runtime.Loader 4.3.0 provides a compile-time reference assembly for System.Runtime.Loader on MonoAndroid,Version=v7.1, but there is no run-time assembly compatible with win. 

Mein Verständnis ist, dass Dies wird durch die System.Runtime.Loader NuGet package Platzhalter für eine Anzahl der Zielframeworks verursacht. Die Struktur dieses Pakets, ist als solche:

lib -> netstandard1.5 -> System.Runtime.Loader.dll 
     MonoAndroid10 -> _._ 

I Paket auch einen netstandard-1.3 build meines Pakets, das nicht den System.Runtime.Loader Baugruppe referenziert. Ich bin froh, dass Android-Nutzer die eingeschränkte Funktionalität in der Version 1.3 erhalten - aber ich kann nicht herausfinden, wie man NuGet dazu bringt, dieses Framework über .NET Standard 1.6 zu wählen.

Meine aktuelle Paketstruktur ist unten:

lib -> netstandard1.3 -> build13.dll 
     netstandard1.6 -> build16.dll 

ich versucht habe es an den unten zu ändern - NuGet zu zwingen, die spezifischere Zielrahmen zu holen, aber NuGet scheint netstandard1.6 über MonoAndroid zu bevorzugen . (Ich habe auch versucht MonoAndroid10)

lib -> netstandard1.3 -> build13.dll 
     MonoAndroid -> build13.dll 
     netstandard1.6 -> build16.dll 

Gibt es eine Möglichkeit, als Paket Autor, kann ich meinen nachgeschaltete Anwender Android Projekte zwingen, das .NET-Standard-1.3-Build von meinem Projekt zu verwenden, statt dem 1,6 Build, die aufgrund der Platzhalterelemente im System.Runtime.Loader-Paket nicht wiederhergestellt werden kann?

Answer 1

Ich fand schließlich, dass dies ein Caching-Problem war.

Alles, was ich davon hielt, wie NuGet funktionieren sollte, war korrekt. Das Problem war, dass NuGet Paketabhängigkeiten zu cachen scheint. Als ich mein Paket neu erstellte, verwendete es immer noch die alte Abhängigkeitsliste. Ärgerlich ist dies nur ein interner Cache - die Benutzeroberfläche von Visual Studio ließ erkennen, dass die Abhängigkeiten meines neuen Pakets korrekt erkannt wurden, aber die Protokolle zeigten die alten Abhängigkeiten, die installiert wurden.

Die Lösung bestand darin, den NuGet-Cache zwischen jedem Umpacken zu löschen.