繁体 English 中英

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

[英]Locally developed nuget with dependent projects

原文 2019-05-01 07:33:23 8 2 c#/ visual-studio/ nuget

假设我有项目A和项目B。 项目A取决于项目B。 因此， A通常会直接引用B的DLL。

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

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

我看到在更新A对B的引用时可以指向本地nuget包，这确实有所帮助。 但是，如果我对B进行更改，则在A看到更改之前，我仍然必须经历生成新包并更新A对包的引用的步骤。 通过预先的安排，我简单地构建了B，而A可以看到更改。

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

在这种情况下，最佳做法是什么？ 当然，有很多人正在使用github和nuget来处理这种事情。

UPDATE

这个话题引起了有关C＃subreddit的讨论，并指出了一些有趣的方法。

Azure开发人员- 原始评论-感谢B0dona

我们要做的是在新提交后使用azure devops（ https://azure.microsoft.com/zh-cn/services/devops/ ）自动构建并将nuget软件包推送到我们自己的存储库中（nuget.org较慢）。已被推。

设置一次，推动项目B喝点咖啡，享受更新软件包的乐趣。

git子模块- 原始评论-感谢alkrun

您提到了GitHub，所以我会提出一些不同的建议：

我认为，如果在项目A上进行的工作很可能导致项目B发生变化，则将B引用为git子模块的A比处理nuget容易得多。 Git子模块并非没有头痛，但这就是它们的设计目标。 一些好处：

1）最大的问题是，如果您说“如果我需要更改B，那么我将进行更改并推动构建新的程序包，然后在A中对其进行测试”，这不是一个非常流畅的模型，它可以要求开发人员将未经测试的代码推送到B中。然后，CI构建/打包的1-3分钟转换时间变成了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是我发现用于处理子模块的最直观的界面。 在VS Code中打开A，然后切换到版本控制标签，您会看到A和所有子模块以及它们正在跟踪的分支列在顶部。 将更改提交给子模块，然后提交给父模块，您就可以开始了。