Nicht automatisch aktualisieren können ein NuGet-Paket auf die neueste version beim bauen

Haben wir zwei verschiedene .NET solutions:

Läuft ein build für die erste Lösung produziert unser Endprodukt: ein paar DLLs. Diese DLLs an unsere Kunden ausgeliefert werden, die über ein NuGet-Paket.
Der zweiten Lösung dient als ein Produkt-test-Lösung: das NuGet-Paket installiert ist, um es, und es wird gebaut und ausgeführt - so macht es die Verwendung unserer Produkte genau auf die gleiche Weise wie unsere Kunden tun würde.

Die Herausforderung hier ist, dass es sollte eine Möglichkeit unsere aktuelle NuGet-Paket wird automatisch installiert, um die Produkt-test-Lösung, bevorzugt während der Erstellung dieses Produkt-test-Lösung.

Basiert auf den Ideen von eine ähnliche Frage, ich bin soweit gekommen mit der Konfiguration, die Produkt-test-Lösung:

Zuerst habe ich aktiviert NuGet-Package-Restore. Dies ermöglicht mir loszuwerden, das Verzeichnis "Pakete" komplett aus VCS, da das Paket mit der version definiert in packages.config-Datei automatisch heruntergeladen werden von NuGet vor dem Bau.
Dann habe ich noch folgende pre-build-Ereignis in Visual Studio: $(SolutionDir).nuget\nuget update -prerelease $(ProjectDir)packages.config. Dies lässt mich ziehen in die neueste version unserer NuGet-Paket bei bauen.

Derzeit nutze ich das oben beschriebene Szenario zum ausführen von lokalen builds mit Visual Studio und unbeaufsichtigte baut mit TeamCity. Die Lösung scheint zu funktionieren für beide Szenarien auf den ersten Blick, aber eigentlich es nicht zu dem erwarteten Ergebnis: wenn die Produkt-test-Lösung gebaut, in der bin Verzeichnis habe ich nicht die neueste version der DLLs, nur in der neuesten version 1.

Das problem ist, dass, obwohl die nuget update Befehl aktualisiert, alles wie erwartet, einschließlich der packages.config und die .csproj Datei, deren neue Inhalte nicht abgeholt zu bauen, deshalb - so meine Vermutung geht - die HintPath Einstellungen aus der .csproj Datei noch spiegeln eine "Ehe bauen" - Zustand, also die alten DLLs kopiert bin - Verzeichnis. Ich nehme an, die .csproj Datei nur einmal verarbeitet wird: vor dem pre-build-Ereignis wird ausgelöst, und die änderungen, die die pre-build-Ereignis werden ignoriert, bis die nächste build.

Als ich die folgenden Lösungen:

Offenbar pre-build ist nicht "pre" genug. Wenn es einem noch früheren Punkt, den ich einfügen könnte die nuget update Befehl, meine obige Lösung würde wahrscheinlich funktionieren.
Ich gelesen, ich könnte das überschreiben der HintPath-s in der .csproj-Datei mit der Definition einer ReferencePath. Aber ich bezweifle, ich könnte ganz einfach herausfinden, den richtigen Weg oder könnte ich es früh genug, so dass das bauen in die Hand nimmt.
Als workaround konnte ich die builds zweimal: duplizieren Sie die build-Schritt für die Produkt-test-Lösung TeamCity und konnte ich immer bauen die Lösung zweimal lokal in Visual Studio.

Hat jemand herausgefunden, wie die automatische update ein NuGet-Paket auf die neueste version während bauen?

brendanforster.com/doing-the-build-server-dance-with-nuget.html
Das ist eine lange Lesen. Sind Sie darauf hindeutet, Sie zu bewegen, das update-Paket auf einer separaten build-Schritt?
danke für den link zu dem blog-Beitrag - sehr hilfreich.

InformationsquelleAutor remark | 2013-02-22

6

Haben Sie einen Blick auf einen blog-post, ich habe gerade in Bezug auf diesen Prozess. Anstelle der Konfiguration Zeug auf dem server, ich habe es durch die Erhöhung der Nuget.Ziele-Datei, die im Ort mit der Nuget-Package-Restore-option. Die Schönheit dieses Ansatzes ist, führt es lokal UND auf dem server (so erhalten Sie, um zu sehen, mögliche Nebenwirkungen, bevor Sie brechen die build -)

Geschrieben details hier: http://netitude.bc3tech.net/2014/11/28/auto-update-your-nuget-packages-at-build-time/
- Schöne Arbeit. Ich würde kommentiert haben auf Ihrem blog aber Disqus.. urggh. Ich benutzte eine modifizierte version des Ansatzes. Ich erstellt einen separaten Artikelgruppe genannt 'InternalPackageSources" und meine interne Futter und geliefert, die als parameter an UpdateCommand, so dass ich tun konnte, eine Wiederherstellung für alle Paketquellen und ein update für die interne feed. Ich ausgespart -id, weil ich habe Dutzende von internen Paketen und nicht wollen, um einen Befehl zu erstellen, - pro Paket
- Macht diese Arbeit für 3.2+?
- ehrlich gesagt, ich bezweifle es. Sie verändert viel, wie nuget läuft, etc w/ 3.x, leider. 🙁
- Wie kommt es, ich kann nicht finden, dieses Nuget.Targets Datei?
- es funktioniert nicht in vs 2017
InformationsquelleAutor bc3tech
4

Ich denke, dass die automatische update zur pre-build-Schritt, es ist nicht NuGet-Stil. Können Sie verstehen, dass müssen Sie diesen Vorgang jedes mal, wenn Sie es tun. Vor allem, weil es kann erhöhen, bauen Zeit. Zum Beispiel, wenn Sie verwenden TDD und oft Projekt neu und führen Sie tests durch, die Sie erwarten, dass es schnell erledigt wird. Außerdem kann update unerwartete Pakete und brechen, etwas, nach, dass Sie verbringen eine Menge Zeit, um das problem zu finden.

Ich schlage vor, das zu tun-update als separaten Schritt. Auf TeamCity, die Sie verwenden können NuGet installer build-Schritt. Für die Durchführung von update-überprüfung nur zwei Checkboxen im unteren Bereich-Schritt-Konfiguration:

Zusätzlich, wenn Sie möchten, halten das Ergebnis der update-nach dem erfolgreichen Aufbau und das bestehen der Prüfung, können Sie später hinzufügen build-Schritt, der vorsieht, dass diese änderungen VCS (mit cmd oder PowerShell zum Beispiel).

Wenn Sie lokal arbeiten, ich glaube, der bessere Weg, führen Sie update-Pakete einmal, bevor Sie anfangen zu arbeiten mit project. Sie können Package Manager Console für diese, mit Befehl Update-Package -IncludePrerelease.
- Danke für deine Antwort. Wie Sie empfohlen, ich habe eine NuGet-Installer-build-Schritt. Meiner Meinung nach ist das im wesentlichen die gleiche Art der Problemumgehung als die #3 "als Lösung" in meiner ursprünglichen Frage, aber offensichtlich viel mehr elegant und angemessen ist, so werde ich bleiben für eine Weile.
- Hinweis: ich denke, ein build-time-NuGet-Paket-update ist immer noch gültige Idee: 1) wird ähnlich wie der "offizielle" Paket Wiederherzustellen, ist nicht weit von NuGet-Prinzipien 2) erhöht sich die build-Zeit nur schlecht wenn das update nicht notwendig war und bei unserem demo - /test-Anwendung, es würde selten passieren + man kann immer noch "abschalten" der pre-build-Ereignis 3) es ist leichter Unterstützung eines build-Prozesses mit der automatischen update-Paket, wenn es ein muss, um die Lösung zu erstellen, die für den aktuellen NuGet-Paket, vor allem, wenn ein Kunde sein wird konfrontiert mit dieser Anforderung ("bauen ist nicht-arbeiten" vs. "bauen ist langsam").
- Ich bin mir sicher, dass die manuelle Suche nach updates jedes mal, wenn Sie öffnen die Lösung funktioniert. Aber es wäre wirklich schön, wenn es war eine nette automatisierte Möglichkeit, dies zu tun.
InformationsquelleAutor Pavel Bakshy
-1

MSBuild-Lösung, die ich herausgefunden habe, ist das überschreiben der BuildDependsOn Eigenschaft. Daher erstellte ich eine UpdateNugetPackages.target die wie folgt aussieht:
```
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <BuildDependsOn>
      UpdateNugetPackages;
      $(BuildDependsOn);
    </BuildDependsOn>
    <UpdateCommand>"$(SolutionDir)pathToYourNugetExe.exe" update "$(SolutionDir)NameOfYourSolution.sln"</UpdateCommand>
  </PropertyGroup>
  <Target Name="UpdateNugetPackages">
    <Exec Command="$(UpdateCommand)"></Exec>
  </Target>
</Project>
```
Den UpdateCommand definiert, wo, und mit welchen Argumenten die nuget.exe aufgerufen wird. Fühlen Sie sich frei, dies zu übernehmen für Ihre eigenen Bedürfnisse.

Diesem Ziel hat sich dann verwiesen werden, die in Ihrem .csproj - Datei. So einfach ist das:
```
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
 ...
    <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
            
    <Import Project="UpdateNugetPackages.target" Condition="Exists('UpdateNugetPackages.target')" />
```
Beachten, dass die import-Reihenfolge ist wichtig. Sie haben, um Ihr Ziel zu importieren-Datei (UpdateNugetPackages.targets), mit overrides (oder eigentlich schmückt) die BuildDependsOn Eigenschaft, nach die Ziel-Datei Microsoft.Common.targets die es definiert. Andernfalls wird die Eigenschaft neu zu setzen und entfernen Sie Ihre änderungen, wie die ursprüngliche definition in Microsoft.Common.targets umfassen nicht vorhandenen Wert in BuildDependsOn. Microsoft.Common.targets importiert Microsoft.CSharp.targets für ein C# - Projekt. So, Ihr import zu gehen hat nach den import von Microsoft.CSharp.targets.
- Ich habe versucht, aber es immer noch nicht aktualisieren Sie die dll in den bin-Ordner.
InformationsquelleAutor David Leitner

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.