- VisualStudio2022插件的安装及使用-编程手把手系列文章
- pprof-在现网场景怎么用
- C#实现的下拉多选框,下拉多选树,多级节点
- 【学习笔记】基础数据结构:猫树
在服务器上构建项目时,需要引用 nuget.org 之外的包,如公司内部开发的、第三方未发布到 nuget.org 上的。怎么办?
GitLab 提供了 Package Registry 来解决这个问题.
新建或使用一个已有项目,作为存放 NuGet 包的项目,为其他需要引用对应 NuGet 包的项目提供 Nuget 源和源上所有包的依赖.
在该项目的【仓库】设置中,设置【部署令牌(Deploy Token)】 。
首先设置一个权限为【write_package_registry】的令牌,允许对软件包库进行读取、写入和删除访问。定义一个合适的名称和到期日期,到期日期不设置则默认永不过期。用户名选填。记录服务器为令牌生成的密码,该密码只会在设置时出现,之后无法再次查看。用于上传包.
再设置一个权限为【read_package_registry】的令牌,允许对软件包仓库进行只读访问。定义一个合适的名称和到期日期,到期日期不设置则默认永不过期。必须填写一个合适的用户名,如 DEPLOY_READ。记录服务器为令牌生成的密码,该密码只会在设置时出现,之后无法再次查看。用于添加源.
定位到所需上传的 Nuget 包,如在本地磁盘目录下,执行命令:
dotnet nuget push <待上传的Nuget包> --source https://gitlab.example.com/api/v4/projects/<your_project_id>/packages/nuget/index.json --api-key <write_package_registry的令牌密码>
api-key 还可以是个人访问令牌或者流水线作业令牌,该指令需要 GitLab v16.1 以上的支持 。
构建前,为项目所在构建环境内添加新的 NuGet 源,执行命令:
dotnet nuget add source "https://gitlab.example.com/api/v4/projects/<项目ID>/packages/nuget/index.json" --name <源名称> --username <read_package_registry的令牌用户名> --password <read_package_registry的令牌密码>
源名称可以是任意合适的名称,如 gitlab-software-group-projects 。
在 %APPDATA%/NuGet/ 中找到 NuGet.Config,进行编辑。也可以在如 Visual Studio 这样的 IDE 中找到对应的【NuGet 包管理器设置】,从而在 UI 界面选项中对配置文件进行修改.
使用 CLI 添加过 NuGet 源,可以在配置文件中 packageSources 查看到.
<packageSources>
<add key="nuget.org" value="https://www.nuget.org/api/v2/" />
<add key="Microsoft Visual Studio Offline Packages" value="C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\" />
<add key="gitlab-software-group-projects" value="https://gitlab.example.com/api/v4/projects/<项目ID>/packages/nuget/index.json" />
</packageSources>
出于安全考虑,NuGet 现要求对程序包进行包源映射,告知机器某个程序包应该访问哪个包源进行下载,避免不法分子利用同名的程序包链接到未知的地址。配置文件中编辑 packageSourceMapping 来进行包源映射设置.
<packageSourceMapping>
<packageSource key="nuget.org">
<package pattern="*" />
</packageSource>
<packageSource key="gitlab-software-group-projects">
<package pattern="A.*" />
<package pattern="B.*" />
</packageSource>
</packageSourceMapping>
最后此篇关于GitLab管理NuGet包的文章就讲到这里了,如果你想了解更多关于GitLab管理NuGet包的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。
我已经在Visual Studio中创建了新的解决方案,启用了nuget包还原,并进入了解决方案根.nuget文件夹,该文件夹包含使包还原正常工作所需的以下文件:NuGet.exe,NuGet.con
自 Nuget 1.5 以来,我的团队一直在使用“启用包还原”选项,以使包不受我们的源代码控制。当 Nuget 1.6 发布时,我们注意到一个问题,即它没有拉取软件包,并跟踪它到 .nuget 文件夹
我维护了一些小的 Nuget 包。 我在 git 存储库中有一个 Nuget README 文件,.nupkg 文件由 VS 根据“Package”配置自动构建,存储在 .csproj 文件。 每当我
我们是一个小型开发团队,我们希望开始使用我们的库作为 NuGet 包。现在我已经看到我们可以创建 NuGet 提要或 NuGet 服务器或 NuGet 画廊。 现在我们不确定有什么区别,对于我们的小团
我正在编写一个脚本,它将自动打包 Nuget 文件并将其发布到我的私有(private)存储库(文件共享)和私有(private)符号服务器(在 localhost 上)。 当我运行 nuget pa
我有一个解决方案,我想从两个项目中创建一个 NuGet 包。 如果它只是一个项目,我会使用 .csproj 文件来规范 NuGet 打包器,但由于我希望两个不同的项目进入完成的包,我不能这样做。 我创
我正在做一个需要处理 Excel 文件的项目。我为这项工作找到了一个名为 Aspose.cells 的库。它不是一个免费的图书馆,我们应该从它的网站购买它的许可证,以便在我们的项目中使用它。但是,我发
我已经使用 Nuget 安装程序创建了一个 TeamCity 构建步骤,但是当我运行这些步骤时出现错误: Updating sources: server side checkout [15:35:4
是否有任何指南或建议来管理不在 nuget 上的库以及在 nuget 上的包。 其中大多数可能是 3rd 方库,除非我们专门安装它们,否则它们可能永远不会继续使用 nuget。 最好将这些 dll 放
我一直在研究自托管 NuGet,但很难理解如何设置它以及它如何帮助支持我们的开发过程。 有没有人对使用哪个,如何设置有任何建议? 或者我应该只使用托管服务? 最佳答案 在查看了各种解决方案(自托管和托
我正在为 OSGeo.FDO 创建 nuget 包,但我遇到了以下问题。 FDO 使用 providers.xml列出它可以使用的所有提供程序的文件。所以我创建了一个名为 OSGeo.FDO 的主包包
我想知道 NuGet 的含义是什么。它是像blah blah get这样的东西吗?它甚至有一个有意义的名字吗?或者它是某物的缩写还是有人为了好玩而决定这个名字?请帮忙,这个问题已经困扰了我 1 周。
This question already has answers here: Is it possible to change the location of packages for NuGet?
如何在 Visual Studio 之外下载 NuGet 包?所以它可以用来创建离线包。 最佳答案 如何在没有 Visual Studio 或 Nuget 包管理器的情况下下载 NuGet 包: 在
我似乎在网络上找不到任何对此表示赞同或反对的地方。谁能指出我的答案吗?或者更好的是,如果您从事 NuGet 工作,您能否给出一些指示,说明是否有任何计划允许商业库包(我认为需要某种身份验证)包含在未来
我已经打开了 TeamCity 的 NuGet 服务器,我想推送公共(public)包(即来自 NuGet.org 等公共(public)资源),因为构建服务器无法看到我们公司外部的信息,因此从 Nu
在我的工作团队中,我们依赖两个 NuGet 提要:来自 NuGet.org 的官方提要用于公共(public)包,而我们文件服务器上的文件夹用于内部包。 这对我们来说效果很好,但我认为我们有一个潜在的
我在我工作的 Web 服务器(在 IIS 7.0 下)上设置了新的 NuGet Gallery。该网站本身已设置并运行良好。我们能够注册帐户、确认电子邮件地址,甚至通过网站本身上传新包。 我们的自动构
当我们在 Visual Studio 2017 中创建 nuget 包时,它默认将项目引用添加为另一个 nuget 引用。 我们如何在创建包时禁用它,而是: 选择不同的包名 在创建包时包含项目的 dl
我可以执行类似 - mono --runtime=v4.0.30319 /Library/TeamCity/buildAgent/work/b0d2d3fefe88d393/.nuget/NuGet.
我是一名优秀的程序员,十分优秀!