2013-07-12 11 views
10

Tôi đã thiết lập tùy chỉnh NuGet server cho công ty của mình. Tất cả hoạt động tuyệt vời - Tôi có thể xuất bản, xem các gói, v.v.NuGet - không cho phép ghi đè gói (có cùng tên và số phiên bản)

Mối quan tâm duy nhất của tôi là tôi có thể xuất bản gói có cùng tên và số phiên bản, do đó ghi đè lên gói hiện có. Đây không phải là lý tưởng và tôi muốn máy chủ NuGet trả về lỗi nếu gói có cùng tên và phiên bản đã tồn tại.

Bất kỳ manh mối nào về cách tôi có thể thực hiện việc này?

Trả lời

9

Tôi cũng sẽ đánh giá cao việc không cho phép ghi đè các gói hiện có. Tuy nhiên, dường như không thể sử dụng máy chủ NuGet ra khỏi hộp. A similar feature request has been closed about two years ago.

Nhưng nhìn vào source code sẽ mở ra một số tùy chọn. Hãy xem CreatePackage() -method. Nó sử dụng một IPackageAuthenticationService để kiểm tra xem mức khoán quy định được phép được bổ sung (chỉ kiểm tra chính API) và một IServerPackageRepository để thực sự thêm gói:

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

Cả hai đều thông qua việc sử dụng constructor injection để thật dễ dàng để mở rộng hành vi bằng cách chuyển các triển khai tùy chỉnh (Sửa đổi Ninject bindings cho điều đó).

Ngay từ cái nhìn đầu tiên, tôi sẽ chuyển đến IServerPackageRepository tùy chỉnh. Triển khai hiện tại sử dụng IFileSystem.AddFile (...) để thêm gói. Bạn có thể sử dụng IFileSystem.FileExists (...) để kiểm tra xem gói đã tồn tại chưa.

Từ góc độ tích hợp liên tục, điều này hoàn toàn có ý nghĩa khi không cho phép ghi đè gói hiện tại vì NuGet theo dõi Semantic Versioning. Do đó, một bản dựng mới nên kết hợp một bugfix, một tính năng mới hoặc một thay đổi đột phá. Tuy nhiên, tôi sẽ chọn cho phép ghi đè ảnh chụp nhanh/bản phát hành trước.

Cập nhật: Dường V2.8 sẽ có một tùy chọn allowOverrideExistingPackageOnPush mặc định là đúng đối với khả năng tương thích ngược. Nó đã được đính kèm với 1e7345624d. Tôi nhận ra rằng sau khi làm việc. Dường như tôi đã quá muộn lần nữa ;-)

+0

Cập nhật: Trong 2 năm qua tôi đã sử dụng [Klondike] (https://github.com/themotleyfool/Klondike) hỗ trợ ootb này. Thật tuyệt vời. – mkoertgen

1

Tôi đã gặp phải vấn đề tương tự. Tôi chạy máy chủ SymbolSource của riêng mình. Tôi quyết định duy trì nhật ký các gói đã xuất bản. Trước khi tôi xuất bản một gói, tôi có thể kiểm tra nhật ký để xem nó đã được xuất bản chưa và chưa xuất bản nó. Điều này là tất cả được thực hiện trong một tập tin batch MS-DOS. Xem bên dưới.

@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%