【问题标题】:Locally developed nuget with dependent projects本地开发的具有依赖项目的 nuget
【发布时间】:2019-05-01 07:33:23
【问题描述】:

假设我有项目 A 和项目 B。项目 A 依赖于项目 B。所以 A 通常会直接引用 B 的 DLL。

然后我决定将 B 发布为 nuget 包。现在,A 通过 nuget 而不是本地 DLL 引用了 B

这种安排的缺点是,如果我更新 B,我需要上传一个新的 nuget 并等待它可用,以便从 A 使用它.

我发现在更新 AB 的引用时,我可以指向一个本地 nuget 包,这确实有点帮助。但是,如果我对 B 进行更改,我仍然需要执行生成新包和更新 A 之前的包的引用的步骤>A 会看到变化。使用 pre-nuget 安排,我只是简单地构建了 B 并且 A 会看到变化。

另一种方法是删除 AB 的 nuget 包的引用,并在进行本地开发时恢复指向本地 DLL。但是,如果 A 发布到 github,那么在推送到 github 之前,必须将引用恢复为 nuget 引用。

在这种情况下,最佳做法是什么?随着 github 和 nuget 的广泛使用,肯定很多人都在处理这类事情。


更新

在 C# subreddit 上为discussion 提出了这个主题,并指出了一些有趣的方法。

Azure 开发 - original comment - thanks to B0dona

我们所做的是使用 azure devops ( https://azure.microsoft.com/en-us/services/devops/ ) 构建和推送 我们的 nuget 包到我们自己的存储库(nuget.org 很慢) 在推送新的提交后自动进行。

你设置一次,推项目B喝点咖啡,享受快乐 那就是更新包。

git 子模块 - original comment - thanks to alkrun

你提到了 GitHub,所以我会提出一些不同的建议:

在我看来,如果项目 A 的工作可能会导致 项目 B,A 引用 B 作为 git 子模块比 处理nuget。 Git 子模块并非没有令人头疼的问题,但是 这就是他们的设计目的。一些好处:

1) 最大的问题是,如果你说“如果我需要改变 B,那么我会 只需进行更改并推动构建一个新包然后对其进行测试 out in A" 这不是一个非常流畅的模型,它在问 开发人员将未经测试的代码推送到 B. 然后 1-3 分钟 围绕 CI 构建/打包变成 3 x 1-3 分钟的周转时间和 当我过去尝试过时,感觉很糟糕。这是一个巨大的 生产力杀手。

2) 有关更改 csproj 文件的任何其他选项,它们都可以工作,但是 他们很容易出错。开发人员并不总是擅长 在提交之前审查所有更改,您将拥有 开发人员忘记并签入项目的更改 参考,这将导致构建失败。

3) 使用 B 作为 A 的子模块并不妨碍您拥有 在 B 上自动构建生成 nuget 包,也许还有其他 不太可能改变 B 的项目可以/应该指那些

4) 在 A 发展的某个阶段,如果它成熟并成为 不太可能导致 B 发生变化,那么您可以将 A->B 切换为 nuget 包参考也

另一种选择,我记得几年前读过一篇文章,其中有人 已经创建了一个生成 msbuild xproj 文件的工具,该文件将 用项目引用替换包引用。他们已经设置好了 xproj 文件在 .gitignore 上的位置,如果文件没有 存在,则使用了 nuget 包引用。这样一来,开发商 将运行命令切换到项目引用,使 他们需要的更改,提交,推送更改,然后更新 nuget 参考。这对我来说似乎很干净,但我找不到 这篇文章比我说的要复杂一些。

所以我还是会选择 git 子模块路线。有一些怪癖 使用 git 子模块,但它们更容易处理 在过去的几年里,感觉怪癖更容易 解释比其他选项。在几个项目中使用它 现在,它非常直观。了解 Git 子模块中的什么 分离头状态是以及如何避免它,请确保使用 -b 添加子模块时的选项,并找到一个可以 处理好子模块。就其价值而言,VS Code 是最有价值的 我发现用于处理子模块的直观界面。打开 A 中 VS Code 然后切换到版本控制选项卡,你会看到 A 和 顶部列出的任何子模块以及它们正在跟踪的分支。 提交对子模块的更改,然后提交给父模块,你很高兴 去吧。

【问题讨论】:

  • 这两个项目是否在同一个存储库中?
  • @zivkan 他们不在同一个github仓库中。
  • 在这种情况下,我不同意“所以 A 通常会直接引用 B 的 DLL”。那怎么行?你在使用子模块吗?我希望使用 NuGet 包是正常的。事实上,即使在同一个 repo 中,您也会使用项目引用,而不是直接引用 dll。但我对您的问题没有任何建议,除了如果可能的话考虑将它们移到同一个仓库中。我们在之前的团队中也遇到过同样的情况,这是生产力的消耗。我会暂时将其作为开发的项目参考,但最终检查是您描述的两步过程

标签: c# visual-studio nuget


【解决方案1】:

Node 社区展示了一种更强大的方法。 npm link 命令开箱即用(另见this blog post),创建从分布式包目录到包源目录的符号链接。这样:

  • 包消费者被透明地重定向到包源项目
  • 包源的变化会自动反映在消费者端

npm link 方法与引用切换相比还具有以下优势:

  • 不会对消费者的源代码进行任何更改 - 可能会意外提交。
  • 跨平台工作,不需要特定的 IDE
  • 可以编写脚本并与团队共享

NuGet 社区显然需要此功能,但由于某些原因,NuGet 仍然缺少它。有一个功能请求https://github.com/NuGet/Home/issues/1821,表示他们没有添加它的计划。

同时我为 NuGet 包创建了一个类似于 npm link 的工具,您可能想尝试一下:https://www.nuget.org/packages/NuLink

【讨论】:

    【解决方案2】:

    如果您使用的是 Visual Studio 2017,则可以安装 NuGet Reference Switcher for Visual Studio 2017 扩展。以下是如何使用它的指南:https://github.com/RicoSuter/NuGetReferenceSwitcher/wiki/Guide

    【讨论】:

    • 听起来很有用,但前提是不使用“新型”csproj 格式。一看到我的 VS 解决方案,它就抱怨我使用了新风格的项目并且没有继续。
    猜你喜欢
    • 2015-12-21
    • 2018-11-30
    • 2020-07-29
    • 1970-01-01
    • 2019-03-19
    • 2018-11-15
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多