【问题标题】:NuGet - disallow overwriting packages (with same name and version number)NuGet - 不允许覆盖包(具有相同的名称和版本号)
【发布时间】:2013-07-12 04:28:22
【问题描述】:

我为我的公司设置了一个自定义NuGet server。这一切都很好 - 我可以发布、查看包等。

我唯一担心的是我可以发布具有相同名称和版本号的包,从而覆盖现有包。这并不理想,如果已存在具有相同名称和版本的包,我希望 NuGet 服务器返回错误。

关于我如何做到这一点的任何线索?

【问题讨论】:

    标签: nuget-server


    【解决方案1】:

    我也非常感谢不允许覆盖现有包。但是,开箱即用的 NuGet 服务器似乎是不可能的。一个similar feature request has been closed about two years ago

    但是查看source code 会打开一些选项。看看 CreatePackage() 方法。它使用一个 IPackageAuthenticationService 来检查是否允许添加指定的包(仅检查 API Key)和一个 IServerPackageRepository 来实际添加包:

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

    两者都是使用构造函数注入传入的,因此很容易通过传递自定义实现来扩展行为(为此修改Ninject bindings)。

    乍一看,我会选择自定义的IServerPackageRepository。当前实现使用 IFileSystem.AddFile(...) 来添加包。您可以使用 IFileSystem.FileExists(...) 来检查包是否已经存在。

    从持续集成的角度来看,禁止覆盖现有包是完全有意义的,因为 NuGet 遵循 Semantic Versioning。因此,新版本应该包含错误修复、新功能或重大更改。 不过,我会选择允许覆盖快照/预发布版本。

    更新:似乎 v2.8 将有一个选项 allowOverrideExistingPackageOnPush,该选项默认为 true 以实现向后兼容性。它已与1e7345624d 共同提交。分叉后我意识到了这一点。看来我又来晚了;-)

    【讨论】:

    • 更新:在过去的 2 年里,我一直在使用支持这个 ootb 的 Klondike。太棒了。
    【解决方案2】:

    我遇到了同样的问题。我运行自己的 SymbolSource 服务器。我决定维护已发布包的日志。在发布包之前,我可以查看日志看是否已经发布,然后不发布。这一切都在 MS-DOS 批处理文件中完成。见下文。

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

    【讨论】:

      【解决方案3】:

      我编写了一个 PowerShell 脚本来删除现有的包版本,但前提是它与我希望推送的版本匹配:

      param (
          [string]$buildconfiguration = "Debug"
       )
      
      function Update-Package ([string]$package,[string]$version,[string]$path)
      {
          dotnet nuget delete $package $version -s https://<mynugetserver>/nuget -k <my access code if used> --non-interactive
          dotnet nuget push "$path\bin\$buildconfiguration\$package.$version.nupkg" -s https://<mynugetserver>/nuget -k <my access code if used>
      }
      
      Update-Package -package "My.Package" -version "2.2.0" -path "MyPackage"
      

      这样做的主要缺点是可能会在更改包时忘记更新 NuSpec 或 vsproj 包部分中的包版本以及忘记更改脚本文件中的版本号。

      我永远不会在公共 NuGet 服务器上使用这种技术。

      我还使用了这个文件的一个版本,它不会推送,只是删除它,它在我的 Azure DevOps (VSTS) 构建中用作 PowerShell 任务。

      我知道 NuGet 说它会列出可用的版本,但我真的不想编写一个脚本来读回列表的结果以确定我正在构建的版本号是否已经存在。

      一件好事是,如果新版本号不存在,删除的 CLI 调用不会抱怨太多,并且不会影响任何包版本。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 2018-03-16
        • 2019-12-21
        • 2019-08-31
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2011-03-10
        相关资源
        最近更新 更多