2013-02-04 15 views
12

Heute habe ich ein seltsames Verhalten von NuGet bei der Installation eines Pakets konfrontiert.Wie entscheidet NuGet, ob der lokale Paketcache verwendet wird oder nicht?

Eine kurze Beschreibung: als Ergebnis meines Build-Skripts gibt es ein NuGet-Paket. Ich ändere nicht die Version jedes Mal, so dass jeder Build produziert MyPackage.1.0.0.nupkg. Als letzten Schritt des Builds schiebe ich das Paket auf den NuGet-Server, der im lokalen Netzwerk bereitgestellt wird.

Jetzt, auf einer anderen Maschine, ich nuget install MyPackage -Source http://myserver/nuget ausführen, die offensichtlich installiert das NuGet-Paket.

Das Problem kommt ins Spiel, wenn ich ein anderes Update von MyPackage - noch der Version 1.0.0 drücke. Wenn ich versuche, es erneut auf dem Client-Computer zu installieren, erhalte ich die vorherige Version des Pakets.

fand ich it is the local cache to be blamed aus: Wenn das Paket installiert wurde, ist es den lokalen Cache in dem und das nächste Mal das Paket der gleichen Version installiert ist, wird es aus dem Cache genommen. Meinetwegen!

Aber auf der anderen Seite gibt es eine -NoCache Option des Befehls nuget install, und ich erwarte, dass es den lokalen Cache ignoriert.

Dies ist jedoch nicht wahr. Das erste Mal, wenn ich es mit -NoCache starte, aktualisiert es den Cache und installiert die wahre neueste Version. Aber das nächste Mal das Paket noch aus dem Cache, auch mit -NoCache Option.

Wird es erwartet? Liegt es daran, dass die Version nicht geändert wurde?

Nur für den Fall: Alle NuGet-Operationen sind mit NuGet.exe und von PowerShell-Sitzung erledigt.

UPDATE: Ich beobachte seltsames Verhalten, das ich nur durch Cache-Ablauf erklären kann. Wenn das Paket zwischengespeichert wird, ziehen alle nachfolgenden Aufrufe von nuget install das Paket aus dem Cache , bis einige Zeit vergeht. Ich habe den genauen Zeitraum nicht bemerkt, aber es ist definitiv mehr als eine Stunde. Danach aktualisiert nuget install das Paket im Cache, und die Situation wird den gleichen ...

+0

Vielleicht, wenn Sie umfassen die -verbosity die zusätzlichen Protokolle detailliert uns einige Hinweise geben könnte? – allen

+0

Wenn ich '-verbosity detailed' an die Kommandozeile anschließe, gibt es keine weiteren Informationen aus, nur' Erfolgreich installiert 'MyPackage.1.0.0'' Weißt du, warum ist das so? –

+0

Ich hatte gehofft, dass die Protokolle eine Richtung zeigten – allen

Antwort

10

Yan,

schiebe ich ein weiteres Update von MyPackage - nach wie vor der Version 1.0.0.

Sie sollten nicht mehr als ein Paket mit einer bestimmten Version drucken: Pakete sollten unveränderlich sein. Wenn Sie etwas im Paket geändert haben, erhöhen Sie die Build-Nummer a.b.C und schieben Sie eine neue Version des Pakets.

Das Verhalten, das Sie erleiden, ist ein Nebeneffekt von NuGet, das erwartet, dass eine bestimmte Paketversion im Wesentlichen unbegrenzt zwischengespeichert werden kann.

+1

Vielen Dank für Ihre Antwort! Der Grund, warum ich die Version nicht ändere, ist, dass das Paket noch in Entwicklung ist und 10 - 20 Mal am Tag neu aufgebaut wird. Wenn ich das Paket zu Beginn "freigebe", möchte ich immer noch 1.0.0. Was schlägst du in diesem Fall vor? Verwenden der 0.x.x-Notation und/oder Vorabversion von NuGet? –

+1

Hi Yan, können Sie die Build-Nummer 'D' auf dem Paket erhöhen: ABCD Dies ermöglicht es Ihnen, zu behalten 1.0.0.x, wo x könnte 73 gebaut werden. Pre-Release ist eine andere Option, aber die Semantik sind immer noch sehr in Bewegung mit NuGet, so dass Sie zwischen verschiedenen Versionen von NuGet unerwartete Ergebnisse erhalten können; Ich würde empfehlen, stattdessen die Build-Nummer "D" zu verwenden. –

+3

Ich empfehle [semantische Versionierung] (http://semver.org), insbesondere die Nomenklatur vor der Veröffentlichung (z. B. 'MyPackage.1.0.0-alpha1440.nupkg' oder so). Ein Vorteil davon (abgesehen davon, dass es der Industriestandard ist) besteht darin, dass Paket-Feeds (wie nuget.org) dies verstehen und entsprechend kennzeichnen. Siehe hierzu [Beispiel für Antlr] (http://www.nuget.org/packages/Antlr/3.4.1.9004-pre). –

12

Yan,

NuGet speichert die Pakete auf der lokalen Festplatte herunterlädt. Für meine Windows 7-Maschine befindet sich der Cache unter C: \ Benutzer \ jmelosegui \ AppData \ Local \ NuGet \ Cache. So können Sie das nuget-Paket, das Sie vergessen möchten, aus dem lokalen Cache-Verzeichnis löschen. Wenn Sie das Paket das nächste Mal installieren, erhalten Sie die neueste Version vom Server.

BTW: Ich bin mit @ Matthew-Skelton einverstanden.

Sie sollten nicht mehr als ein Paket mit einer bestimmten Version drucken: Pakete sollten unveränderlich sein. Wenn Sie etwas im Paket geändert haben, erhöhen Sie die Build-Nummer a.b.C und schieben Sie eine neue Version des Pakets.

Ich hoffe, diese aproach fit in Ihrem Szenario

+2

Danke für Ihre Antwort! Dies ist, was ich vorübergehend getan habe - den NuGet-Cache auf "schmutzige" Weise zu säubern. Aber ich denke, ich sollte das Konzept der Paketunveränderlichkeit untersuchen ... –