【问题标题】:Compatibility between VS, TFS and TeamBuild template versions?VS、TFS 和 TeamBuild 模板版本之间的兼容性?
【发布时间】:2014-08-04 19:22:56
【问题描述】:

免责声明:

我不是 TeamBuild 方面的专家。我知道我问的问题可能很愚蠢。

我目前拥有的

我有一个带有 10 多个控制台应用程序和 3 个 ASP.NET Web 应用程序项目的 VS2010 解决方案。 我使用以下选项在我们的 TFS2013.2 服务器上设置了 TeamBuild:

  • TeamBuild 模板是默认的 TFS2010 DefaultTemplate.xaml
  • 它以解决方案文件为目标

以 drop 文件夹结尾的文件是:

  • 控制台应用程序的所有 exe 和配置文件
  • 一个 _PublishedWebsites 文件夹,每个 Web 应用程序项目包含一个文件夹。请注意,web.config XML 转换完成

我想要什么

我希望构建给我:

  • 每个控制台应用程序一个文件夹
  • web.config XML 转换

我的想法是使用默认的 TFS2013 构建模板 TfvcTemplate.12.xaml 设置一个新构建,因为我看到有一个选项指定输出应该基于 PerProject。 由于 MSBuild 未能构建 Web 项目,构建失败,并出现与 WebDeploy 相关的错误:

C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets (3009): Web deployment task failed. (Unknown ProviderOption:DefiningProjectFullPath. Known ProviderOptions:.)

我的问题

  • 使用 TFS2013 构建模板构建 VS2010 解决方案失败是否正常?
  • WebDeploy 似乎根本不涉及 TFS2010 默认构建模板但它涉及 TFS2013 构建模板是否正常?
  • 如果没有,是否可以在 .csproj 文件中进行一些调整以使它们由 TFS2013 构建模板构建?
  • 是否必须将目标文件更新到 V12 版本,因为它是构建它的 TFS2013?

我的潜在答案

  • 我的构建服务器上安装了 WebDeploy 3.5,并且已经开始工作了。
  • 所有目标文件都已就位

谢谢 ;-)

【问题讨论】:

    标签: .net visual-studio tfs tfsbuild alm


    【解决方案1】:

    对于第一个问题(将每个项目的输出分离到单独的文件夹中),最好的方法是使用 TFS 2013 默认模板,它有一个标志,可以将每个内置的 解决方案一个单独的文件夹。然后,为每个单独的应用程序制定解决方案。假设一个解决方案由一个应用程序及其所有依赖项组成,而不是多个应用程序。 “黄金法则”是:每个解决方案一个应用程序。

    对于您在使用 TFS2013 构建过程模板时遇到的构建失败问题,请确保在该服务器上安装了 VS2013 Update 2 -- 我对该主题的研究表明这是一个问题。

    对于第二个问题,您可能不想使用 web.config 转换。理想情况下,您只需要构建一次二进制文件,然后就可以将它们部署到多个环境——唯一的区别因素是您的配置文件。如果您使用 web.config 转换,您获得的配置文件取决于您正在构建的平台。为每个环境构建都有一些问题:

    1. 它会消耗更多时间——如果您的构建需要 10 分钟才能运行,并且您必须为 4 个环境中的每一个运行一次,那么您就是在浪费 30 分钟来获得一个不同的配置文件。
    2. 它引入了风险——如果构建服务器上的某些内容发生了变化,或者源代码控制中的某些内容发生了变化,该怎么办?突然,您发布的二进制文件与您一直在测试的不同。
    3. 更难维护。你必须有一堆不同的构建定义,以及一堆不同的解决方案平台。您需要维护的东西越多,出现问题的可能性就越大。

    最好的办法是对 web.config 文件的多个版本进行源代码控制,每个环境一个版本,然后在部署时选择适当的配置文件。

    另一种方法是使用支持配置文件标记化的工具——这样,您就拥有一个只包含标记的配置文件,这些标记可以在发布时替换为适当的值。但这需要您可能不感兴趣的其他工具和配置。

    【讨论】:

    • 感谢@Daniel Mann 的回复。关于每个项目,好的,明白了。一种解决方案是引用所有 .csproj 而不是一个 .sln。 VS2013.2 安装在构建服务器上。我也看到了你提到的错误,但我认为这是不同的。您发现的这些特定错误与 .targets 文件的 v12 有关。我明天再挖一点。至于 web.config XML 转换,我听到了你的观点,但我唯一希望完成的是将应用程序部署到我们的集成机器时。
    【解决方案2】:

    感谢 Sayed Ibrahim Hashimi 的 blog post,我今天弄明白了。
    基本上,它解释了当您使用 VS2012 或 VS2013 打开 VS2010 解决方案时对 .csproj 所做的修改。指向 .targets 文件的链接,在这种情况下,Microsoft.WebApplication.targets 与用于打开解决方案的 VS 版本相关。

    由于我正在研究的解决方案仅适用于 VS2010,因此我指向的 .targets 文件是 VS2010 特定版本,位于
    C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets

    我手动编辑了我的 3 个 Web 应用程序项目的 .csproj 文件以包含 Sayed 的修改,然后基于 TFS2013 默认构建模板的构建就像一个魅力。

    我的猜测:TFBuild2013 正在将参数传递给 VS2010 版本的 .targets 文件无法理解的一些 WebDeploy MSBuild 任务。

    感谢@Daniel Mann 的回复!

    【讨论】:

      猜你喜欢
      • 2019-08-27
      • 2011-11-22
      • 2019-04-29
      • 1970-01-01
      • 2016-05-11
      • 1970-01-01
      • 2012-03-03
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多