2

通常，“持续包集成”涉及源代码控制、构建服务器和参与团队尽可能频繁地获取更新的包。但我正在寻找这个故事的一个更极端的版本——没有 CM——完全发生在开发人员的机器上，一举一动。我想要的更详细的描述是这样的......

使用 Visual Studio 2010 或 2012，假设有一个实现插件系统的“foo.csproj”应用程序。每个插件代表一个 nuget 包，并具有相应的 Visual Studio 项目。这些项目中的每一个都是包含基本应用程序的同一 VS 解决方案的一部分。

我想要以下发展故事：

  1. 更改插件的源代码。
  2. 构建解决方案，或执行调试启动，这会导致 msbuild...
    1. 重建更改的插件
    2. 然后 nuget 将每个插件打包并上传到本地存储库（可以只是 VS 解决方案的子文件夹）
    3. 重建基础应用程序。
    4. 刷新基础应用程序的 nuget-plugin 依赖项，这些依赖项刚刚在前面的步骤中更新。 备注：
      1. 这假设 MSBuild 神奇地知道在构建、打包和上传所有插件之前不执行最后一步。
      2. “foo”应用程序本身可以使用 nuget.core 来刷新包，但在这种情况下，我假设 VS 构建过程完成了这一步。

我想知道这个故事是否足够普遍，以至于有“常见”（msbuild？）脚本。

我自己对应该如何处理的猜测如下：

  1. 所有插件项目都放置在 VS 解决方案文件夹结构中某处的公共“插件”文件夹中。
  2. 基本应用程序“项目依赖项”配置有对所有插件项目的引用。 注意：我不喜欢手动管理这些项目依赖项的想法。
  3. 基础应用程序“foo.csproj”有一个构建步骤，它扫描“foo.csproj”XML 以查找它在“plugins”文件夹中的依赖项，并为每个启动 nuget 打包和部署。
  4. 然后，基础应用程序启动 nuget“全部更新”。希望这是可能的，即使 msbuild 已经在执行中。

简而言之，基础应用程序能够立即使用已更改的插件。这是在没有签入、构建服务器或手动和任意请求更新插件包的情况下完成的。

如果这个故事不存在预先存在的脚本，那么我将自己制作。但我还是想知道：

  1. 可以将上面的第 2 步转换为通用的吗？也就是说，我如何说服 msbuild 在特定文件夹中的所有项目都已构建之前不要构建“基础应用程序”？请记住，我不想手动管理项目依赖项。
  2. 这种整体方法有什么缺陷吗？

我特别想知道是否有一个已经存在的 nuget-visual-studio 集成可以帮助我可能忽略的这个故事。

4

1 回答 1

3

这是一个很长的问题要回答，所以不确定我是否涵盖了这个问题的所有内容；我将尽我所能。首先，您的情况并不少见。您计划的方法的前两个步骤对我来说似乎没问题（您可以自由选择插件项目的位置）。

有一点是肯定的：您必须手动定义构建顺序，因为您的解决方案不知道使用 (NuGet) 插件的项目是否依赖于包含这些插件源代码的项目。不要使用 Visual Studio 中的内置构建顺序对话框，而是查看MSDN 博客上的这篇文章，了解正确的方法（或者您最终可能会得到在本地工作但在构建服务器上不起作用的东西）。参考帖子中的关键 MSBuild 元素如下：

<ProjectReference Include="... foo.csproj"> 
    <ReferenceOutputAssembly>false</ReferenceOutputAssembly> 
</ProjectReference>

现在，关于那些插件的打包、部署和使用：

  • 每个插件项目都应在构建后步骤中触发包创建和发布。我博客上的这篇文章包含 ZIP 下载，其中包含很多可用于入门的 MSBuild 内容。例如，我在 Release 版本中为类库版本、打包和发布 NuGet 包。我正在使用 NuGet 命令行工具来pack（命令参考）和push（命令参考）包。
  • 消费应用程序项目应在预构建步骤中运行NuGet.exe update <packages.config>（命令参考）。

还要注意你不是在并行运行构建。

于 2012-12-29T20:16:04.323 回答