nuget适合日常开发工作流程吗？

Question

我正在研究nuget在开发过程中改进依赖关系（内部和第三方）的自动处理。

只要您通过CI构建服务器开发，一切都很好：

1. 获取A和B的最新来源，其中B取决于A
2. 修复A
中的错误
3. 建立A
4. 检查源代码管理
5. CI Build Server已启动
6. 创建新的nuget包并将其放置在公司存储库中
7. 构建B（将获得更新的A包）
8. 运行B以验证A中的错误是否已修复 ñ。重复n次

但是，我想知道是否可以在本地作为单个开发人员工作，而不必等待CI Build Server生成新的包？

Nuget有一个功能Package Restore，它将在构建时自动下载所有依赖项。您还可以列出程序包还原应查找程序包的存储库顺序。

如果工作流程可能变为：

1. 获取A和B的最新来源，其中B取决于A
2. 修复A
中的错误
3. 建立A
4. （建筑创建一个本地nuget包）
5. 运行B来测试A中的（已解决的）错误（现在应该使用我们的本地nuget包，而不是本地存储库）
6. ...重复n次
7. 检查源代码管理
8. CI Build Server已启动
9. 在公司存储库中创建的新nuget包

这可能使用Visual Studio，MSBuild，CI构建服务器和nuget吗？我特别感兴趣的是在本地开发时制作本地包。

请注意，我有本机项目，但除了生成nuget包后构建时，这将是一个工作流程，我希望它应该适用于C＃和C ++项目。

Answer 1

我现在所拥有的解决方案虽然远非理想，但却是我能想到的最佳解决方案。哦!这是一项正在进行中的工作，因此我会在未来几周/几个月内改变，因为我想知道如何解决这些问题。

我现在大部分时间都要处理托管DLL，但我确实有一些本机代码和最糟糕的多平台本机代码来处理。

创建一个本地存储库，基本上只是一个文件夹，并在nuget feed列表中对其进行配置。

然后我创建了一个任务（MSBuild），它将打包项目并将其输出到本地存储库的根文件夹中。确保包的版本始终在增加。目前我通过编辑程序集版本手动执行此操作。

构建完成后，更新引用它的其他项目，我通常通过包管理器控制台（update-package）来执行此操作。

每个已更新的项目，将其版本冲洗车床并重复，直到您进入最顶层的项目（实际程序）。

一旦一切都很好并且您已准备好提交，那么构建系统应该自己打包并将其发送到您的官方存储库。

好

• 没有使用中间开发版本阻塞存储库和构建系统，垃圾仍然存在（应该）本地。
• 本地回购设置非常容易设置，甚至可以通过全局nuget配置在不更改VS的情况下完成。
• 这对包恢复或包含项目的签入包的范例都很友好。这就是说我建议不要检查你在本地构建的软件包，而是选择一个通过构建系统提交到本地存储库的软件包。本地建造的应该保留在当地。

错误

• 比仅仅将项目添加到解决方案还要复杂得多。
• 你的依赖树越深（或越宽），痛苦就越大。

丑陋

• 使一些原生的nuget行为非常古怪和恼人：
  • 如果您的VS连接到版本系统（perforce for me），则更新操作将永久进行。我听说他们“解决”了这个问题，如果它现在最糟糕的话，就不愿意看到它是怎么回事！
  • 让nuget将非代码引用更改为永不复制是一件非常痛苦的事。

仅限

• 直接从nuspec配置内容依赖项的所需状态（永远复制，永不复制或更新）并完成它！ （与ClickOnce内容状态相同的故事包括，排除等）
• 快速更新操作，十几个项目的2分钟就是疯了，特别是如果最终目标是管理500 +。
• 也许是混合模式，本地我们使用项目包含，但构建系统可以使用nuget依赖（并在必要时构建它们）
• 如果要解析项目，请遵循MSBuild解析规则并遵守条件语句。 我还有一些问题尚未弄清楚如何管理存储库中代码的多个分支。如何在食物链中进一步处理版本冲突。在一个大型项目中（最终我们必须在一个应用程序可执行文件中将500多个单独的项目放在一起，预计会发生冲突）。

我很想带来Maven理智的依赖管理，但到目前为止，我还没有发现nuget足够成熟，甚至没有考虑过向开发团队提出建议。

Answer 2

当然可以。在我们的解决方案中，NuGet将库停放在解决方案层次结构的“packages”目录中，该目录最终保存在TFS中。这允许完整的解决方案检出，包括所需的库。如果您打算更新通常由NuGet提供的库，则需要更新依赖项目的引用以指向包含通常由NuGet进程提供的更新代码的项目。

在签入常规解决方案工作（而不是NuGet相关的库）之前，请确保解决方案的NuGet库是最新的，并且解决方案中的引用指向NuGet安装的库。当然，您将事先登记并获取与NuGet相关的库。