Ich habe eine Bibliothek erstellt, die von CEFsharp abhängig ist, was die Erstellung der Bibliothek für bestimmte Plattformen erfordert. Also keine AnyCPU Unterstützung.
Jetzt möchte ich das in einen NuGet packen. Soweit ich verstehe, müssen Sie diese Dateien in den Build-Ordner legen und eine .targets -Datei haben, die die richtige DLL zum Referenzieren auswählt. Also endete ich mit einem NuGet-Paket, das so aussah:
Ich habe Folgendes in die Datei .targets eingefügt:
So weit, so gut. Jetzt zum Problem. Wenn ich dieses NuGet zu einem neuen WPF-Projekt hinzufüge, sehe ich den Verweis auf die Bibliothek in der .csproj -Datei wie:
Obwohl nichts über die .targets -Datei erwähnt wird. Ist das immer noch der Weg mit NuGet 3? Habe ich etwas falsch gemacht? Derzeit schlägt dies zur Laufzeit bei der Ausführung von x64 aufgrund des Verweises auf die x86-Bibliothek fehl.
Nachdem ich viel zu lange damit herumgespielt habe, habe ich es herausgefunden.
Offenbar müssen die Dateien build.prop und build.target den gleichen Namen haben wie das NuGet-Paket, sonst wird es in der csproj-Datei nicht hinzugefügt.
BEARBEITEN:
Ich habe ein kleines Github-Repository erstellt, das zeigt, wie man dieses für Ihr eigenes Projekt verwendet.
Es zeigt eine Lösung mit 3 Projekten, eines für iOS eins für Android und ein Net45, das sowohl auf x86 als auch auf x64 abzielt.
Beachten Sie, in der Datei .props. Die Pfade zeigen auf die Ordnerstruktur des entpackten NuGet. Diese Pfade entsprechen also dem, was Sie in Ihre Nuspec-Datei geschrieben haben.
Wie im Repo definieren Sie einen nuspec wie:
%Vor% Ich habe meine x86-Dateien in build\x86 und x64-Dateien in build\x64 eingefügt. Der Name des Ordner-Builds könnte in diesem Fall für diese Dateien im Wesentlichen beliebig sein. Was hier zählt, ist, dass die Props-Datei unten auf diese Ordner für die jeweiligen Plattformen zeigt.
Ich bin mir nicht sicher, ob es auch wichtig ist, die x86-Lib in lib\net45 zu setzen. Sie können damit experimentieren. Die Requisiten-Datei sollte sowieso die richtige für Sie auswählen.
In diesem Fall wäre $(MSBuildThisFileDirectory) der Ordner build\net45\ , stellen Sie sicher, dass Ihr Pfad korrekt auf die DLLs zeigt. Der Ordner build\net45 ist hier wichtig. So importiert NuGet automatisch Ziele und Requisiten-Dateien.
Beachten Sie auch, dass der Name My.Awesome.Library rundherum ziemlich konsistent ist. Was hier wichtig ist, ist, dass der Name Ihrer Props-Datei mit der NuGet-Paket-ID übereinstimmt. Sonst scheint NuGet es nicht importieren zu können.
Es gibt ein paar Dinge, die ich von der obigen Lösung ablehne.
Die nuspec-Datei muss keine <Files> -Informationen enthalten, wenn Sie die Standarddateistruktur verwenden, indem Sie die Dateien in einen nuget-Ordner hinzufügen. Wenn Sie die nuget-Dateien jedoch aus Ihrem Lösungsordner ausführen möchten, ist dies erforderlich.
besserer nuspec Inhalt:
%Vor% Ich stimme auch nicht zu, dass er die .dll im Ordner build hat, diese sollte in Ihrem lib Ordner liegen und im build Ordner sollten Ihre .targets und .props Dateien enthalten.
Die Dokumentation für nuget hier erwähnt dies.
Auch der Ordner lib ist für .dlls gedacht, die in Ihren Referenzen enthalten sind. Zweitens, .dlls, die Ihrem Ordner build hinzugefügt wurden, sind zusätzliche DLLs, die in einigen Fällen benötigt werden - ähnlich wie SQlite es für seine interop dll tut. In diesem Fall ist es besser, sie im Ordner lib zu speichern.
Bessere Ordnerstruktur:
%Vor%.props Dateiinhalt:
%Vor%.targets Dateiinhalt:
%Vor%Sie können überprüfen, ob das obige funktioniert, indem Sie Ihre nuspec-Datei mit der Nuget Package Manager-App öffnen und alle hinzugefügten Dateien prüfen. Wenn Sie nun diese zu einem Projekt hinzufügen, wird die DLL entsprechend der Architektur geladen, die für das Projekt ausgewählt wurde, auf das sie referenziert wurde. Außerdem wird in der Zieldatei ein Fehler angezeigt, wenn "Beliebige CPU" ausgewählt ist, und den Benutzer darüber informieren muss zwischen x86 und x64
wählenBEARBEITEN:
Ein Punkt, der nicht gut geklärt wurde, war, dass die Benennung von .target und .props mit dem Dateiname der nugget-Paketdatei (also auch der Version) übereinstimmen muss. Ohne diese würde die doppelte Referenz erscheinen wenn Visual Studio wieder geöffnet wird.
Tags und Links nuget msbuild-target