【问题标题】:Using an external tool for C# builds in Visual Studio在 Visual Studio 中使用用于 C# 构建的外部工具
【发布时间】:2010-12-18 09:30:02
【问题描述】:

使用 Visual Stdio 2008 时,您可以使用内部工具构建 C++ 项目,而不是让 IDE 直接调用 MSVC。如果使用跨平台构建系统,这将提高跨平台构建的一致性。

但是,我不知道如何像 C# 项目那样做。可以简单地将其注册为具有 C# 源的本机项目,但是,您会失去通过拥有 C# 项目获得的一些优势。更重要的是,这意味着允许项目直接构建和使用外部工具(遗憾的是这是必要的)将需要两个单独的项目,而不是仅仅创建替代构建配置来调用外部工具。

有谁知道是否可以阻止 Visual Studio 自己调用 csc 而是调用外部工具?

编辑:显然有一些误解。这里的目标不是在 Visual Studio 之外编译任何东西。相反,它允许 Visual Studio 作为 IDE 而不是构建系统。已经有一个(基于 Scons 的)构建系统能够编译 C# 和 C++ 源代码,并且 Visual Studio 已配置为调用 Scons 来编译 C++ 项目。我正在尝试对其进行配置,以便当您点击“构建”按钮时,它会为 C# 项目和 C++ 项目调用 Scons。

【问题讨论】:

  • 在下面的回答中查看我的编辑。
  • 你有没有试过在 MSDN 论坛上发布这个问题,让那些更熟悉 VS 及其局限性的人可以解决这个问题?
  • 不,我没有。谢谢你的想法。

标签: c# visual-studio build


【解决方案1】:

您可以像这样从命令行构建您的解决方案:

C:\WINDOWS\Microsoft.NET\Framework\v3.5>msbuild.exe "C:\path\Your Solution.sln"

【讨论】:

  • 您在发帖前是否阅读了 coppro 的评论和其他答案?他说他不是在寻找在 VS 外部编译的方法,而是在寻找从 VS 内部替换对 csc.exe 的调用的方法。
【解决方案2】:

编辑:仍然使用 MSBuild 回答了您的问题(如果您只是想在 IDE 之外进行编译)。 IDE(Visual Studios)只是构建由 MSBuild 构建的构建文件的一种“奇特”方式。 Visual Studios 不会构建文件,它只是调用随 .NET Framework 2.0 及更高版本提供的 MSBuild,它会根据您创建的项目文件编译您的代码。如果 Scons 可以读取和处理 MSBuild 文件,那么我相信您可以调用它来构建您的项目。但考虑到 C# 是 Microsoft 语言这一事实​​,我认为您将很难找到不使用 MSBuild 的附加值,因为我假设该语言和构建工具都非常适合协同工作。 - 结束编辑

您可以使用 MSBuild 编译您的 C# 项目。如果您在文本编辑器中打开 .csproj 文件,您将看到它是一个 MSBuild 文件。如果您想在 IDE 之外编写一些 C#,您可以使用 .csproj 文件作为起点构建一个构建文件,然后调用 MSBuild 来编译您的应用程序。 IDE 只是为您抽象出 MSBuild 文件的编辑的一种方式。

如果您真的很勤奋,您可以创建一组自定义任务来执行自定义构建过程中的操作,例如移动文件和版本控制。 MSBuild Community Tasks 是在 MSBuild 期间使用自定义代码为您完成任务的一个很好的例子。

【讨论】:

  • 我根本不是在寻找在 IDE 之外编译的方法。我正在尝试单击 IDE 中的“编译”按钮并让它调用 Scons。我可以使用 Makefile 项目为 C++ 执行此操作。该构建现在可以在 Scons 上正常工作,我只是在寻找 IDE 集成。
【解决方案3】:

编辑您的项目文件并更新 CscToolPath 键以指向包含您的工具的目录并添加包含目录名称的 CscToolExe 键:

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|.NET 3.5' ">
   .
   .
   .
   <CscToolPath>path\to\custom\tool\directory</CscToolPath>
   <CscToolExe>exe name</CscToolExe>
   .
   .
   .
</PropertyGroup>

我没有对此进行测试,CscToolExe 键可能会导致问题,在这种情况下,我只需将外部工具可执行文件重命名为“csc.exe”。

【讨论】:

  • 虽然我喜欢这个建议,但这不是一个选择;如果您将所有 csc 标志都传递给 SCons,SCons 就会心脏病发作
  • 在这种情况下,也许一个自定义的 .targets 文件将使用您想要的参数调用 SCons 会起作用吗?您可以基于 CSharp 一个,并在项目文件中将导入更改为您的自定义 .targets 文件:
【解决方案4】:

查看答案,我似乎很清楚,以与调试器兼容的方式将 scons 集成到 Visual Studio 中等等是不会发生的......

您可能会考虑一个选项,我知道您不想更改构建系统,但请耐心等待,是使用元构建系统,即“cmake”。 http://www.cmake.org/

Cmake 实际上并没有构建项目。它的作用是为您创建构建文件,您可以使用它来构建项目,在 Windows 上,它为您创建的构建文件是:Visual Studio 项目文件。您可以简单地将它们直接加载到您的 IDE 中,然后编译并正常使用!

我觉得CMake非常好用,并且提供了高水平的透明性和可维护性。

Linux 上完全相同的 CMakeLists.txt 文件将导致生成 linux makefile。

在 mingw 上,他们可以生成 mingw makefile。

cmake 中有许多可用的生成器。列表在这里:

http://www.cmake.org/cmake/help/cmake-2-8-docs.html#section_Generators

http://springrts.com 是一款大型开源 rts 游戏,以前使用 scons 作为其跨平台构建系统,现在使用 cmake。

我了解您并不想真正改变构建系统,因此这是一个中长期解决方案。

Cmake 在任何情况下都是另一种选择,可以添加到使用自定义构建工具、使用 msbuild 或手动从命令行运行 scons 构建的选项中。

【讨论】:

    【解决方案5】:

    鉴于所有其他答案,可以在 .Net 附带的 Targets 文件中找到 MSBuild 在 VS 或 MSBuild 执行构建时所做的事情。这些可以在系统的 FrameWork 目录中找到。就我而言:

    C:\Windows\Microsoft.NET\Framework64\v3.5
    

    包含Microsoft.Common.targets 等。此文件包含以下代码段:

    <!--
    ============================================================
                                        Build
    
    The main build entry point.
    ============================================================
    -->
    <PropertyGroup>
        <BuildDependsOn>
            BeforeBuild;
            CoreBuild;
            AfterBuild
        </BuildDependsOn>
    </PropertyGroup>
    <Target
        Name="Build"
        Condition=" '$(_InvalidConfigurationWarning)' != 'true' "
        DependsOnTargets="$(BuildDependsOn)"
        Outputs="$(TargetPath)"/>
    

    这意味着重新定义这个 Target 可以让 MSBuild 成为一个 VS 做任何你想做的事情。上述文件的顶部包含一条重要信息:

    Microsoft.Common.targets
    
    WARNING:  DO NOT MODIFY this file unless you are knowledgeable about MSBuild and have
              created a backup copy.  Incorrect changes to this file will make it
              impossible to load or build your projects from the command-line or the IDE.
    
    This file defines the steps in the standard build process for .NET projects.  It
    contains all the steps that are common among the different .NET languages, such as
    Visual Basic, C#, and Visual J#.
    

    我的建议是阅读有关 MSBuild 及其构建文件语法的所有信息,并尝试在您的项目中重新定义构建目标。我的印象是,在阅读了 MSBuild 之后,您可能会找到一种更简单的方法来满足您的要求。您可以在this so question 的答案之一中找到像这样重新定义目标的示例。

    编辑:

    如何重新定义目标? 重新定义本质上是在定义它之后定义相同的目标。因此,例如在您的 .*proj 文件中,在 &lt;Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" /&gt; 行之后定义一个 Build Task,该行导入在这种情况下构建 C# 项目所需的所有目标。一个例子可以是

    <Target
        Name="Build"
        Condition=" '$(_InvalidConfigurationWarning)' != 'true' "
        DependsOnTargets="BeforeBuild"
        Outputs="$(TargetPath)">
        <Exec Command="nmake" />
    </Target>
    

    【讨论】:

    • 我很困惑。我如何重新定义它以使其做一些不同的事情?
    【解决方案6】:

    我发现一个同方向的问题here,建议编辑注册表。我很确定没有其他方法可以更改 Visual Studio 使用的编译器,因为在任何解决方案、配置、csproj 文件或其他任何文件中,以及 Program Files 中的 Visual Studio 9.0 文件夹/子文件夹中都没有 csc.exe 的痕迹目录。

    可以在以下位置找到注册表位置:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\74ACAA9F1F0087E4882A06A5E18D7D32
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\9055DA7481CC1024CB23A6109FD8FC9B
    

    但这些密钥可能会因您的安装而异。结论:更改 VS 使用的编译器几乎是不可能的。

    补充:以下MSDN article 处理自定义 C++ 编译器的相同问题,Ed Dore 的回答似乎证实了我的理论,即无法选择自定义编译器用于 VS。

    【讨论】:

    • 啊,非常简洁的信息,和我要找的很接近,但不完全是——我并不是真的想替换编译器;而是告诉 MSVC 不要使用它(如果有意义的话)
    • 阅读您对 Achilles 帖子的评论我了解您希望在单击 VS 中的构建选项时调用 Scons。我怀疑除了用注册表中的外部命令替换 csc.exe 之外,您是否可以这样做。因此,您的评论对我来说没有多大意义;)。
    【解决方案7】:

    您无需维护不同的项目文件即可使用外部工具进行构建。 MSBuild 旨在使用 Visual Studio 使用的相同项目文件进行构建。

    这是一篇描述它的文章。

    Customize Your Builds in Visual Studio Using the Standalone MSBuild Tool

    它适用于 VS2005,但也应该适用于 VS2008。

    【讨论】:

      【解决方案8】:

      在“工具”>“外部工具”下,您应该能够定义一个外部工具来为您执行活动。命令应该是外部工具的可执行文件的路径。

      希望这会有所帮助。

      【讨论】:

      • 这不能很好地与其他系统集成,例如调试器。
      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2018-11-04
      • 1970-01-01
      • 1970-01-01
      • 2017-09-10
      • 2019-07-14
      • 2011-08-01
      • 2014-08-21
      相关资源
      最近更新 更多