Resolve .NET 4.7 externes Projekt NuGet Abhängigkeiten über MSBuild Ziele

Question

Wir müssen diese Projekte erstellen und sie haben einige seltsame Praktiken. Sie basieren auf verknüpften Codedateien, die als Ergebnis des Buildprozesses eines anderen Projekts generiert werden. Diese Projekte befinden sich in einem Unterordner.

Bevor wir unsere Projekte erstellen, müssen wir das Teilprojekt erstellen. Dies geschieht durch Hinzufügen eines benutzerdefinierten Build-Ziels zum BeforeBuild-Ziel jedes Projekts und scheint zu funktionieren. Das Unterprojekt wird jedoch nicht erstellt, ohne dass die NuGet-Abhängigkeiten wiederhergestellt wurden.

Zur Verdeutlichung: Wir wissen, dass dieses Muster völlig verrückt ist, aber wir haben nicht die Manpower, um jedes Projekt umzuformen, das dieses Muster verwendet. Wir versuchen nur, sie in einem Schritt zuverlässig zu kompilieren. Jede dieser externen Projektabhängigkeiten

wird in einem benutzerdefinierten ItemGroup, aufgeführt wie folgt:

<ItemGroup> <ExternalDependantProjects Include= "..\<subfolder>\<project>\<project>.csproj" /> </ItemGroup>

Wir haben versucht, dieses Problem zu lösen, indem das Hinzufügen von benutzerdefinierten Ziele erstellen, die Before Ziel durch jedes Projekt aufgerufen werden . Wir haben zunächst versucht, ResolveNuGetPackageAssets als Build-Ziel zu verwenden, haben aber festgestellt, dass dies nur in netcore unterstützt wird, während wir auf net47 abzielen.

Jetzt versuchen wir ein benutzerdefiniertes Build-Ziel zu schreiben, das die NuGet-Abhängigkeiten im externen Projekt wiederherstellen wird. Wir haben den Straight-Forward-Ansatz versucht, etwa so: <Exec Command="nuget restore @(ExternalDependantProjects)" /> und einen etwas komplexere & Hacky Powershell Versuch: <Exec Command="powershell.exe -command &quot;&apos;@(ExternalDependantProjects, '&apos; &apos;')&apos; | foreach { nuget restore $_ }&quot;" />

In beiden Fällen ist es einfach versucht, die Pakete des Hauptprojektes wieder herzustellen, nicht die externen Projekte. Es scheint, dass @ (ExternalDependantProjects) leer ist und daher kein neues Argument hinzugefügt wird. Using hat gezeigt, dass @ (ExternalDependantProjects) nichts zurückgibt. Es funktioniert jedoch als der "Projects" Parameter, wenn wir ein MSBuild "Build" Ziel aufrufen. Also, ich vermute, dass wir den Item-Parameter falsch verwenden? Vielleicht gibt es eine Syntax, um auf die Include-Eigenschaft des Elements zuzugreifen?

Ich bin mir jedoch nicht sicher, ob es auch funktioniert, wenn wir dieses Problem lösen können. Wir haben mit dem Befehl nuget restore für das Unterprojekt getestet und erhalten immer die Antwort, dass alle Pakete in packages.conf installiert sind. Dennoch ist .. \ packages \ von diesem externen Projekt leer und packages.conf gibt ein halbes Dutzend Pakete an (Sie fehlen auch in "Referenzen" in VS und die Referenzen 'HintPath gehen korrekt zu .. \ packages).

Also wir sind auf drei Fronten verwechselt: Wie verweisen wir den ExternalDependentProjects Item Include-Pfad von MSBuild Ziele, warum funktioniert das NuGet Restore CLI nicht, und ist dies sogar der richtige Weg zur Lösung dieses Problems ? Sind wir völlig falsch gegangen?

Answer 1

Wie verweisen wir die die ExternalDependentProjects Artikel umfassen Weg von MSBuild Zielen, warum nicht die NuGet wiederherstellen CLI Arbeit, und das ist auch der richtige Weg, um die Lösung dieses Problems zu gehen? Sind wir völlig falsch gegangen?

<Target Name="BeforeBuild"> 
     <Exec Command="nuget restore @(ExternalDependantProjects) -OutputDirectory ..\<subfolder>\packages" /> 
    </Target> 

Mit diesem Ziel, NuGet Paket für externe Projekte wird erfolgreich gestellt:

Sie sollten Ihr benutzerdefiniertes Build-Ziel mit der Option -OutputDirectory, so dass das benutzerdefinierte Build-Ziel sollte wie unten sein schreiben.

Außerdem ist der Wert @(ExternalDependantProjects) nicht leer, Sie können ein Ziel Echo diesen Wert verwenden.

Unten ist meine Testprobe, können Sie bis zu einem gewissen Detailinfo siehe:

ExternalpProject sind der Unterordnername, TestExternalProject ist der externe Projektname ein.

<ItemGroup> 
    <ExternalDependantProjects Include= "..\ExternalpProject\TestExternalProject\TestExternalProject.csproj" /> 
</ItemGroup> 

<Target Name="BeforeBuild"> 
    <Message Text="Restore package for Externalp Project" Importance="high"></Message> 
    <Exec Command="nuget restore @(ExternalDependantProjects) -OutputDirectory ..\ExternalpProject\packages" /> 
</Target> 

<Target Name="AfterBuild"> 
    <Message Text="Display the value of ExternalDependantProjects" Importance="high"></Message> 
    <Message Text="@(ExternalDependantProjects)"></Message> 
</Target> 

Answer 2

NuGet entdeckt pakete.config-Projekte zum Wiederherstellen aus der Lösungsdatei. Wenn sich alle Projekte in der Lösungsdatei befinden und Sie nuget.exe restore <solution file> ausführen, sollten sie wiederhergestellt werden, unabhängig davon, was in den Projektdateien passiert.

Als Workaround für ein beliebiges benutzerdefiniertes Szenario könnten Sie ein Skript schreiben, um alle packages.config-Dateien im Ordner zu ermitteln, und dann direkt die Dateien nuget.exe restore <packages.config> -SolutionDirectory <solution root> für die Dateien aufrufen. Für die Wiederherstellung von packages.config wird nur die Liste der IDs/Versionen aus den packages.config-Dateien ermittelt, damit sie heruntergeladen und in den Paketordner auf Lösungsebene extrahiert werden können.

Ich empfehle auch, Projektreferenzen mit ReferenceOutputAssembly=false zu verwenden, um sicherzustellen, dass Projekte in der von Ihnen gewünschten Reihenfolge erstellt werden und ohne sich gegenseitig zu referenzieren.Siehe: https://blogs.msdn.microsoft.com/kirillosenkov/2015/04/04/how-to-have-a-project-reference-without-referencing-the-actual-binary/