visual-studio-2010 - Visual Studio、插件和 Nuget

Question

通常，“continuous package integration”涉及源代码控制、构建服务器和参与团队，他们可以根据需要随时获取更新的包。但我正在寻找这个故事的更极端的版本——没有 CM——完全发生在开发人员的机器上，一举一动。我想要的更详细的描述是这样的......

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

我想要以下发展故事:

更改插件的源代码。

构建解决方案，或执行调试启动，这会导致 msbuild...

重建更改的插件

然后 nuget 将每个插件打包并上传到本地存储库(可以只是 VS 解决方案的子文件夹)

重建基础应用程序。

刷新基础应用程序的 nuget-plugin 依赖项，这些依赖项刚刚在前面的步骤中更新。笔记:

这假设 MSBuild 神奇地知道在构建、打包和上传所有插件之前不执行最后一步。

“foo”应用程序本身可以使用 nuget.core 来刷新包，但在这种情况下，我假设 VS 构建过程完成了这一步。

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

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

所有插件项目都放置在 VS 解决方案文件夹结构中某处的公共(public)“插件”文件夹中。

基本应用程序“项目依赖项”配置有对所有插件项目的引用。
注意:我不喜欢手动管理这些项目依赖项的想法。

基础应用程序“foo.csproj”有一个构建步骤，它扫描“foo.csproj”XML 以查找它在“plugins”文件夹中的依赖项，并为每个启动 nuget 打包和部署。

然后，基础应用程序启动 nuget“全部更新”。希望这是可能的，即使 msbuild 已经在执行中。

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

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

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

这种整体方法有什么缺陷吗？

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

Answer 1

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

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

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

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

每个插件项目应该在 中触发包创建和发布构建后步骤 . This post在我的博客上包含 ZIP 下载，其中包含很多可用于入门的 MSBuild 内容。例如。我在 Release 版本中为类库版本、打包和发布 NuGet 包。我正在使用 NuGet 命令行工具来 pack ( command reference ) 和 push ( command reference ) 包。

消费应用项目 (s) 应该运行 NuGet.exe update <packages.config> ( command reference ) 在 预构建步骤 .

还要注意你是 不是 运行 builds in parallel .