NuGet - Überschreiben von Paketen (mit gleichem Namen und Versionsnummer)

Question

Ich habe eine benutzerdefinierte NuGet server für meine Firma eingerichtet. Es funktioniert alles super - ich kann veröffentlichen, Pakete anzeigen, usw.

Meine einzige Sorge ist, dass ich ein Paket mit dem gleichen Namen und der Versionsnummer veröffentlichen kann, wodurch das vorhandene Paket überschrieben wird. Dies ist nicht ideal und ich möchte, dass der NuGet-Server einen Fehler zurückgibt, wenn bereits ein Paket mit demselben Namen und derselben Version existiert.

Irgendwelche Hinweise, wie ich das erreichen kann?

Answer 1

Ich würde es auch sehr schätzen, die bestehenden Pakete nicht zu überschreiben. Es ist jedoch nicht möglich, den NuGet-Server sofort zu verwenden. A similar feature request has been closed about two years ago.

Aber Blick auf die source code öffnet einige Optionen. Werfen Sie einen Blick auf die CreatePackage() -Methode. Es verwendet eine IPackageAuthenticationService zu überprüfen, ob das angegebene Paket hinzugefügt werden darf (nur überprüft den API Key) und ein IServerPackageRepository, um tatsächlich das Paket hinzufügen:

// Make sure they can access this package 
if (Authenticate(context, apiKey, package.Id)) 
{ 
    _serverRepository.AddPackage(package); 
    WriteStatus(context, HttpStatusCode.Created, ""); 
} 

Beide werden sie mit dem Konstruktor Injektion geführt, so Es ist einfach, das Verhalten zu erweitern, indem Sie benutzerdefinierte Implementierungen übergeben (Ändern Sie dafür die Ninject bindings).

Auf den ersten Blick würde ich für eine benutzerdefinierte gehen IServerPackageRepository. Die aktuelle Implementierung verwendet IFileSystem.AddFile (...), um das Paket hinzuzufügen. Sie können IFileSystem.FileExists (...) verwenden, um zu überprüfen, ob das Paket bereits vorhanden ist.

Aus kontinuierlicher Integrationsperspektive ist es absolut sinnvoll, ein bestehendes Paket nicht zu überschreiben, da NuGet Semantic Versioning folgt. Daher sollte ein neuer Build einen Bugfix, eine neue Funktion oder eine brechende Änderung enthalten. Ich würde jedoch erlauben, Snapshots/Pre-Releases zu überschreiben.

Update: Es scheint v2.8 eine Option allowOverrideExistingPackageOnPush die standardmäßig auf true für die Abwärtskompatibilität haben. Es wurde mit 1e7345624d verbunden. Das habe ich nach dem Abzweigen erkannt. Scheint, ich war wieder zu spät ;-)

Answer 2

Ich lief in das gleiche Problem. Ich betreibe meinen eigenen SymbolSource Server. Ich entschied mich, ein Protokoll der veröffentlichten Pakete zu führen. Bevor ich ein Paket veröffentliche, kann ich das Protokoll überprüfen, um zu sehen, ob es bereits veröffentlicht wurde, und es dann nicht veröffentlichen. Dies ist alles in einer MS-DOS-Batch-Datei getan. Siehe unten.

@echo off 

rem Requires that the Visual Studio directory is in your 
rem PATH environment variable. It will be something like: 
rem C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE 

rem API key for publishing to SymbolSource server 
set apiKey=<<<GUID>>> 

rem URL of the SymbolSource web app 
set lib=http://<<<address>>> 

rem Path to a simple text file on a file share - which happens to be the 
rem same place that the SymbolSource server web app is published. 
set log=\\<<<path>>>\publish_log.txt 

rem Path to the Visual Studio solution that contains the projects to be published. 
set sln=..\<<<solution name>>>.sln 

rem Build all projects in the solution. 
devenv %sln% /rebuild Debug 

rem Delete packages produced during last run. 
del *.nupkg 

rem Each line in projects.txt is a path to a .csproj file that we want to 
rem create a nuget package for. Each .csproj file has a corresponding .nuspec 
rem file that lives in the same directory. 
for /F %%i in (projects.txt) do nuget.exe pack %%i -IncludeReferencedProjects -Prop Configuration=Debug -Symbols 

rem Delete any local packages that have already been published. 
for /F %%i in (%log%) do if exist %%i del %%i 

for %%F in (".\*.symbols.nupkg") do nuget push %%~nxF %apiKey% -source %lib% 

rem Log information about published packages so, in the next run, 
rem we can tell what has been published and what has not. 
for %%F in (".\*.symbols.nupkg") do echo %%~nxF >> %log%