c# - 具有相关项目的本地开发的 nuget

Question

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

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

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

我发现在更新 A 对 B 的引用时我可以指向本地 nuget 包，这确实有点帮助。但是，如果我对 B 进行了更改，我仍然必须在 之前完成生成新包和更新 A 对包的引用的步骤>A 会看到变化。通过 pre-nuget 安排，我只需构建 B 和 A 即可看到更改。

另一种方法是删除 A 对 B 的 nuget 包的引用，并在进行本地开发时恢复指向本地 DLL。但是，如果 A 已发布到 github，则在推送到 github 之前必须将引用还原为 nuget 引用。

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

---

更新

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

Azure 开发运营 - original comment - thanks to B0dona

What we do is use azure devops ( https://azure.microsoft.com/en-us/services/devops/ ) to build and push our nuget packages to our own repository (nuget.org is slow) automatically after a new commit has been pushed.

You set it up once, push project B drink some coffee and enjoy the joy that is updating packages.

git 子模块 - original comment - thanks to alkrun

You mention GitHub so I'll propose something a bit different:

In my opinion, if work on project A is likely to cause changes in project B, A referencing B as a git submodule is much easier than dealing with nuget. Git Submodules aren't without their headaches, but this is what they were designed for. Some of the benefits:

1) The biggest is that if you say "If I need to change B then I'll just make the change and push to get a new package built then test it out in A" it's not a very fluid model to work with and it's asking developers to push untested code into B. Then that 1-3 minute turn around for CI build/package turns into 3 x 1-3 minute turnarounds and it just feels horrible when I've tried it in the past. It's a massive productivity killer.

2) Any other options around changing csproj files, they can work, but they're very error prone. Developers aren't always great about reviewing all changes before they commit them, you're going to have developers forgetting and checking in the change to a project reference and it's going to cause build failures.

3) Using B as a submodule for A doesn't prevent you from having automated builds on B that produce nuget packages, and maybe other projects which are less likely to change B could/should refer to those

4) At some point in the development of A, if it matures and becomes less likely to cause changes in B, then you can switch A->B to a nuget package reference also

Another option, I remember reading an article years ago where someone had created a tool that generated an msbuild xproj file that would replace package references with project references. They had it set up where the xproj file was on the .gitignore and if the file didn't exist, the nuget package reference was used. In this way, a developer would run a command to switch over to project references, make the changes they need, commit them, push changes, then update the nuget reference. This seemed fairly clean to me, but I can't find the article and it was a bit more complicated than I'm making it sound.

So I'd still go with the git submodule route. There are some quirks with git submodules but they have gotten a lot easier to deal with in the last couple years and it feels like the quirks are easier to explain than the other options. Having used this for a few projects now, it's very intuitive. Understand what a Git Submodule in a detached head state is and how to avoid it, make sure to use the -b option when adding a submodule, and find a good tool that can handle submodules well. For what it's worth, VS Code is the most intuitive interface I've found for working with submodules. Open A in VS Code then switch to the version control tab and you'll see A and any submodules listed up top along with the branches they're tracking. Commit changes to the submodule, then to the parent and you're good to go.

Answer 1

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

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

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

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

这个功能显然是 NuGet 社区所需要的，但出于某种原因，NuGet 仍然缺少它。有一个功能请求 https://github.com/NuGet/Home/issues/1821 ，这表明他们没有添加它的计划。

与此同时，我创建了一个工具，其工作方式类似于用于 NuGet 包的 npm 链接，您可能想尝试一下:https://www.nuget.org/packages/NuLink