【问题标题】:Is it worth learning to use MSBuild?使用 MSBuild 值得学习吗?
【发布时间】:2008-09-06 22:26:48
【问题描述】:

我只是想知道人们是否认为值得学习使用 MSBuild 语法来自定义 .net 项目的构建过程,或者考虑到使用它构建项目很容易,是否真的不值得学习视觉工作室。

我正在考虑夜间构建等,但是我不能使用使用 VS 内置的命令行构建选项的预定事件吗?有没有更好的工具?

【问题讨论】:

    标签: .net msbuild


    【解决方案1】:

    @kronoz
    我会说是的。
    MSBuild 的巧妙之处在于,如果您修改 csproj 文件以包含自定义构建步骤,那么这些步骤将在 VS 或 MSBuild 中发生。此外,如果您有构建服务器,则无需安装完整的 VS,只需安装 SDK 即可构建您的项目。

    【讨论】:

      【解决方案2】:

      MSBuild 绝对值得花时间学习。在最初的学习曲线(实际上可能非常陡峭)之后,执行最常见的构建自动化步骤变得相当容易。

      • 在 RELEASE 模式下构建程序集
      • 使用强名称为程序集签名
      • 运行单元测试
      • 即时修改 xml 文件/Web.config-s
      • 修改程序集的版本号
      • 正在验证 FxCop / StyleCop 等...
      • 自动部署 - 创建 SQL 数据库、IIS 网站、Windows 服务等...

      【讨论】:

        【解决方案3】:

        MSBuild 绝对值得每个编写 .NET 软件的人学习。 .NET 应用程序的构建服务器不再需要安装 Visual Studio 的原因(如 Andrew Burns 所述)是因为 MSBuild 现在是 .NET Framework 的一部分。

        了解 MSBuild 将使您在选择用于实施持续集成的技术方面具有极大的灵活性。因为我花时间学习了 MSBuild,所以我能够毫不费力地将我们团队使用的 CI 系统从 CruiseControl.NET 更改为 TeamCity。那些 CI 服务器,或类似 FinalBuilder(我不熟悉)的东西,是执行夜间构建的更好选择,而不是计划任务。学习如何实现自定义 MSBuild 任务将使您在实现自定义构建方面更加灵活。 Jivko Petiov 列出了 MSBuild 简化的许多任务。在数据库部署和配置的情况下,我已经在 MSBuild 中编写了执行此操作的脚本,它使开发和测试过程变得更加容易。

        如果 Visual Studio Team System 在您的未来,使用 MSBuild 构建的应用程序将比通过其他方式构建的应用程序更容易迁移到该环境。

        有很多资源可帮助您开始使用 MSBuild。我将从Inside the Microsoft Build Engine 开始。其中一位合著者在网上也有很多东西,包括this siteproject on CodePlex

        【讨论】:

          【解决方案4】:

          听起来您是在自己的网站上工作的单一开发人员。如果是这种情况,则完全没有必要,但作为专业经验的一部分,学习对您来说仍然是一个好主意。

          随着从事项目的开发人员数量的增加,项目的自动化构建变得更加必要。两个开发人员很容易编写不兼容的代码,这些代码在组合时会中断(想象我正在调用一个函数 foo(int x),而您将签名更改为 foo(int x, int y):当我们结合我们的代码库,代码就会中断。

          随着集成构建之间的时间长短,这些类型的错误会增加复杂性和麻烦。通过设置夜间构建,甚至是每次签入时发生的构建,这些问题都大大减少了。这种做法在涉及多个开发人员的项目中几乎是行业标准。

          现在,回答您的问题:这是一项跨越项目和公司的技能。您应该学习它以拓宽您作为开发人员的知识和技能,并在您的简历中添加重要的一行。

          【讨论】:

            【解决方案5】:

            嗯,MSBuild 是内置的,所以如果你做一些简单的事情,那么是的,推荐它。

            但对于夜间构建,我建议FinalBuilder

            看到这个question on Build/Configuration Management Tools.

            【讨论】:

              【解决方案6】:

              MSBuild 使用起来非常简单,您可以使用 VS 管理项目和解决方案文件,只需将 SLN 传递给 MSBuild。

              【讨论】:

                【解决方案7】:

                在像您这样的场景中,您还没有构建系统,那么是的,MSBuild 绝对值得。您不仅可以将它用于各种预构建和构建后任务(请参阅 Jicko Petiov 的回答),还可以将它很好地集成到持续集成环境中(例如 CruiseControl)。

                当您已经有一个自动化/脚本化的构建系统时,可能不值得这样做。例如,我自己并没有花时间使用 MSBuild,因为在 MSBuild 存在之前我就一直在使用 NAnt 来完成这项任务......

                【讨论】:

                  【解决方案8】:

                  使用 MSBuild 从命令行构建相对容易学习。首先打开 Visual Studio 命令提示符,然后运行 ​​msbuild /?。只需通读一次帮助,稍后再决定是否要了解更多详细信息。

                  编写项目文件有点复杂。大多数人不需要学习它,因为您可以在 Visual Studio 中完成大多数事情。但是,对于某些问题,它也非常强大。

                  我过去曾使用 MSBuild 作为脚本语言,并结合了许多自定义任务。 MSBuild 具有出色的日志记录支持 + 内置的依赖管理。然而,这不是一门容易学习的语言。 PowerShell 是一个更好的选择。

                  【讨论】:

                    【解决方案9】:

                    如果您在 .net 工作坊中开发,它确实值得学习。
                    我已经将我们的构建过程与 Jenkins 集成 - 最初是 Hudson。 如上所述,MSbuild 有陡峭的学习曲线。但是一旦 您掌握了基础知识,就可以开始自定义构建。 到目前为止我的印象 - 可能很天真,大部分脚本由

                    <PropertyGroup>
                       <PropertyKey>value</PropertyKey>
                    </PropertyGroup>
                    <ItemGroup>
                       <ItemListKey>List values<ItemListKey>
                    </ItemGroup>
                    <Task Source="" Target="" />
                    
                    除了用于构建之外,我还成功地使用 MSBuild 创建了一个管理模块 配置文件,例如 web.config 和 foo.exe.config 文件。 它是一个混合模块,由 .net 控制台应用程序、MSBuild 脚本和批处理文件组成。 这个模块的作用是在项目升级期间,它将创建一个 XML 转换 带有来自旧配置的连接字符串、端点和 appSettings 的模板 文件。 项目升级后,模块将转换新部署 配置 文件而不影响任何新条目。如果你有几十个配置文件 非常有效。

                    【讨论】:

                      【解决方案10】:

                      @kronoz 我会说是的。整洁的 关于 MSBuild 的事情是,如果你 修改您的 csproj 文件以包含 自定义构建步骤然后这些步骤 将发生在VS内部或从 微软构建。另外,如果您有构建 您不需要安装的服务器 完整的 VS,只有 SDK 来构建你的 项目。

                      ==> 这并不完全正确。例如,在构建服务器上构建安装项目将需要安装 Visual Studio!

                      【讨论】:

                        猜你喜欢
                        • 2010-10-07
                        • 1970-01-01
                        • 1970-01-01
                        • 1970-01-01
                        • 2011-02-27
                        • 2011-01-22
                        • 2010-11-14
                        • 2011-01-05
                        • 1970-01-01
                        相关资源
                        最近更新 更多