【问题标题】:Sequentially build configurations in Visual Studio without MSBuild or plugins?在没有 MSBuild 或插件的情况下在 Visual Studio 中按顺序构建配置?
【发布时间】:2016-03-02 18:49:36
【问题描述】:

MSDN 描述了如何创建批处理构建,但没有提供自动化不同批处理的方法(以及 GUI 的一键式解决方案)

This question 描述了有条件地调用第二个构建,但似乎不足以满足两个以上的顺序配置

This question 解决了同样的情况,但同样只适用于两种配置


在我的测试用例中,每个配置:

  • 定义自己的 MACROS(影响源代码)
  • 适用于多个项目(类库)。这些项目是相互依赖的,需要在当前配置的上下文中使用特定的构建顺序

我希望 Visual Studio 使用单个构建命令按顺序构建多个配置。

子配置可以嵌套在父配置下,并在父配置构建时由visual studio顺序执行吗?


更新:尝试的解决方案 1 [2016-03-11]

针对 Stijn 的建议答案,我尝试了以下方法:

使用 3 个测试项目和 6 个配置设置 DotNetFramework 4.5 WinForms 解决方案:

  • CORE_DEBUG
  • CORE_RELEASE
  • EXTENDED_DEBUG
  • EXTENDED_RELEASE
  • 调试
  • 发布

调试配置必须:

  • 不触发它自己的配置构建(即“调试”)
  • 必须依次触发 CORE_DEBUG 和 EXTENDED_DEBUG 配置

我已将以下修改后的目标添加到第一个项目的项目文件中:

<Target Name="AfterBuild" Condition="'$(Configuration)|$(Platform)' == 'Debug|AnyCPU'">

现在使用“调试”配置进行构建会触发 EXTENDED_RELEASE 构建。查看解决方案文件后,我看到 Visual Studio 决定自动将“调试”链接到“EXTENDED_RELEASE”:

    {4F9706AA-26A9-483C-81C4-22E301C54C89}.Debug|Any CPU.ActiveCfg = EXTENDED_RELEASE|Any CPU
    {4F9706AA-26A9-483C-81C4-22E301C54C89}.Debug|Any CPU.Build.0 = EXTENDED_RELEASE|Any CPU

从解决方案文件中删除上述两行并没有帮助,因为 Visual Studio 只是重新生成它们。总而言之,这现在有两个不良结果:

  1. Visual Studio 为 Project1 执行“调试”构建
  2. Visual Studio 然后为 Project2 和 Project3 执行“EXTENDED_RELEASE”

结论:虽然这种方法可行,但它也(首先)分别执行调试和发布配置构建。视觉工作室 还列出了构建菜单中的所有 6 个配置(我们只想要 Debug 和 Release 是可见的,并且在幕后 Debug 必须触发 CORE_DEBUG 和 EXTENDED_DEBUG,Release 必须触发 CORE_RELEASE 和EXTENDED_RELEASE)


更新:尝试的解决方案 2 [2016-03-16]

继续使用 makefile 项目解决方案:我创建了一个由 stijn 在下面的回答中指定的 makefile 项目,它运行良好!

结论:在我看来,这是首选的解决方案,因为它为用户提供了最大的权力和能力来准确控制必须如何执行构建以及必须如何处理配置。

【问题讨论】:

    标签: visual-studio build-process


    【解决方案1】:

    第二个SO question的原理可以通过多次调用MsBuild来调整为顺序构建多个配置/平台。例如:

    <Target Name="AfterBuild" Condition="'$(Configuration)|$(Platform)' == 'Debug|AnyCPU'">
      <MSBuild Projects="$(MySolution)" Properties="Configuration=Release;Platform=x86"/>
      <MSBuild Projects="$(MySolution)" Properties="Configuration=Debug;Platform=x64"/>
      <MSBuild Projects="$(MySolution)" Properties="Configuration=Release;Platform=x64"/>
    </Target>
    

    这可以通过使用项目批处理、删除条件并自动确定调用哪个配置然后只构建其他配置等来清理,但这有点超出了这里的范围。

    我并不认为在 AfterBuild 目标中执行此操作是最好的方法,因为这样您就需要调整一个“正常”项目以触发其他所有项目的构建。另一种方法是将MakeFile Project 添加到您的解决方案中,设置它的依赖项,使其在构建顺序中排在最后(至少如果这是您需要的),并将其设置为命令行以类似于以下方式调用 msbuild如上所述。您甚至可以将所有逻辑保存在同一个项目文件中:将“构建命令行”设置为

    msbuild $(MsBuildThisFile) /t:CustomBuild /p:Configuration=$(Configuration);Platform=$(Platform)
    

    因此,构建项目将“递归”并使其再次调用自身,并使用与 VS 调用相同的属性,但执行 CustomBuild 目标,然后您可以在其中构建其他项目/解决方案以品尝。

    重新编辑:更新 您快到了,但您必须转到配置管理器并确保配置正确设置开始。从一开始:

    • 创建新解决方案,添加 3 个项目
    • 右击解决方案,选择配置管理器
    • 活动解决方案配置组合框中选择新建
    • name 输入 CORE_DEBUG,在 Copy settings from 下选择 DEBUG,并确保像 一样选中 Create new project configurations
    • 重复其他配置
    • 例如,对于 EXTENDED_RELEASE,它现在应该看起来像
    • 您可能已经完成了大部分工作,但不知何故 Debug 被分配给 EXTENDED_RELEASE,所以这是您应该修复的一件事;您可以通过手动编辑解决方案来做到这一点,但您不必删除行,而是必须编辑它们以使其正确,否则 VS 只需再次添加它们,正如您所注意到的那样

    现在在文本编辑器中打开第一个项目,在已插入 AfterBuild 但已注释掉的文件末尾附近,添加

    <ItemGroup>
      <Configurations Condition="'$(Configuration)'=='Debug'" Include="CORE_DEBUG;EXTENDED_DEBUG" />
      <Configurations Condition="'$(Configuration)'=='Release'" Include="CORE_RELEASE;EXTENDED_RELEASE" />
      <Projects Include="$(SolutionDir)WindowsFormsApplication1.csproj;$(SolutionDir)WindowsFormsApplication2.csproj;$(SolutionDir)WindowsFormsApplication3.csproj" />
    </ItemGroup>
    <Target Name="AfterBuild" Condition="'@(Configurations)' != ''">
      <Message Text="Projects=@(Projects) Configuration=%(Configurations.Identity)" />
      <MSBuild Projects="@(Projects)" Targets="Build" Properties="Configuration=%(Configurations.Identity)" />
    </Target>
    

    您可能需要调整项目的路径。这将为 Debug 构建构建 CORE_DEBUG 和 EXTENDED_DEBUG,对于 Release 构建也是如此。当 Configurations ItemGroup 为空时,即不构建 Debug 或 Release 时,会跳过 AfterBuild。

    重新编辑:makefile

    您可以为 makefile 命令行指定多个命令。单击“构建命令行”框旁边的箭头并选择“”为确保一切正常,必须将配置管理器设置为仅构建用于调试/发布的 makefile 项目,例如:

    makefile 项目的命令行看起来像

    或者,我自己更喜欢这个,您创建一个与上述内容相同的 msbuild 文件:

    <?xml version="1.0" encoding="utf-8"?>
    <Project ToolsVersion="12.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
      <ItemGroup>
        <Configurations Condition="'$(Configuration)'=='Debug'" Include="CORE_DEBUG;EXTENDED_DEBUG" />
        <Configurations Condition="'$(Configuration)'=='Release'" Include="CORE_RELEASE;EXTENDED_RELEASE" />
        <Projects Include="$(SolutionDir)WindowsFormsApplication1.csproj;$(SolutionDir)WindowsFormsApplication2.csproj;$(SolutionDir)WindowsFormsApplication3.csproj" />
      </ItemGroup>
      <Target Name="Build" Condition="'@(Configurations)' != ''">
        <Message Text="Projects=@(Projects) Configuration=%(Configurations.Identity)" />
        <MSBuild Projects="@(Projects)" Targets="Build" Properties="Configuration=%(Configurations.Identity)" />
      </Target>
    </Project>
    

    然后您的 makefile 命令会像调用该文件一样

    msbuild /path/to/msbuildfile /t:Build /p:Configuration=Debug;SolutionDir=$(SolutionDir)
    

    【讨论】:

    • 谢谢@stijn,我已经在 csproj 文件和 makefile 中尝试过 AfterBuild,但不幸的是两者都对我不起作用(无法有条件地调用所需的平台 - “构建”目标根本不'不从 MSBuild 的递归调用触发(我做了双重检查条件),makefile 项目不允许我指定多个项目文件 - 如果我指定一个解决方案文件,那么它不允许我将目标传递给项目,并且确实不允许在解决方案文件中定义目标)。我在上面花了 10 个小时然后放弃了 - 只需要手动构建两次。
    • 我自己使用过这样的东西,没有你提到的任何问题,所以也许你只是缺乏 msbuild 经验/知识:它 definitley 是可行的。如果您编辑您的问题并清楚说明您想要构建的平台/配置/目标,以及您的解决方案/项目/目录结构的(简短)示例,我可以发布一个完整的工作示例。
    • 我已经用第一次尝试及其结果更新了我的问题(基于您的第一个建议)-也许您可以发现问题?
    • 查看更新;在这里从头开始对其进行测试,以确保它可以正常工作
    • 无论如何,问题是你在这里逆流而上 - VS 是一个配置/平台或批量构建。通常通过编写扩展或命令行 msbuild 来完成更多操作。后者,如果你想要的基本上是多个配置的单击构建,那么是最简单的 imo:创建一个单独的 msbuid 文件来执行此操作,并将其作为外部工具调用(你也可以绑定键盘快捷键),请参阅工具->外部工具...
    猜你喜欢
    • 1970-01-01
    • 2011-02-03
    • 2010-12-16
    • 1970-01-01
    • 2021-07-29
    • 2017-12-13
    • 2013-04-17
    • 2016-03-04
    • 2015-11-04
    相关资源
    最近更新 更多