VS、TFS和TeamBuild模板版本之间的兼容性？

Question

免责声明：

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

我现在拥有的

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

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

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

• 控制台应用程序的所有exes和配置文件
• 包含每个web应用程序项目一个文件夹的_PublishedWebsites文件夹。注意，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:.)

我的问题

• VS2010解决方案在由TFS2013构建模板生成时失败是正常的吗？
• WebDeploy似乎完全不涉及TFS2010默认构建模板，而与TFS2013构建模板有关，这是正常的吗？
• 如果没有，是否可以对.csproj文件进行一些调整，以使其由TFS2013构建模板生成？
• 我是否必须将目标文件更新为V12版本，因为构建目标文件的是TFS2013？

我的潜在答案

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

谢谢;-)

Answer 1

今天，多亏了赛义德·易卜拉欣·哈希米( Sayed Ibrahim Hashimi )的博客帖子，我才明白了这一点。

基本上，它解释了在用.csproj或VS2013打开VS2010解决方案时对VS2012所做的修改。指向.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向WebDeploy MSBuild任务传递参数，而VS2010版本的.targets文件并不理解这些参数。

谢谢你的回复，丹尼尔·曼！

Answer 2

对于第一个问题(将每个项目的输出分离到单独的文件夹)，最好的方法是使用TFS 2013默认模板，该模板有一个标志，使其将构建的每个解决方案都放在一个单独的文件夹中。然后，为每个单独的应用程序制定解决方案。假设一个解决方案由一个应用程序及其所有依赖项组成，而不是多个应用程序。“金科玉律”是:每个解决方案一个应用程序。

对于在使用TFS2013构建过程模板时生成失败所遇到的问题，请确保在该服务器上安装了VS2013更新2 --我对该主题的研究指出了这是一个问题。

对于第二个问题，您可能不想使用web.config转换。理想情况下，您只需要构建一次二进制文件，然后就可以将它们部署到多个环境中--唯一不同的因素是配置文件。如果您使用的是web.config转换，那么您得到的配置文件取决于您构建的平台。每个环境的构建都有以下几个问题：

1. 它占用了更多的时间--如果您的构建需要10分钟才能运行，并且您必须为4种环境中的每种环境运行一次，那么您将浪费30分钟来获得一个不同的配置文件。
2. 它引入了风险--如果构建服务器上的某些内容发生了更改，或者源代码管理中的某些内容发生了更改，怎么办？突然之间，您正在发布的二进制文件与您所测试的不一样。
3. 这很难维持。您必须有一堆不同的构建定义，以及一堆不同的解决方案平台。你要维持的东西越多，事情搞砸的几率就越高。

这里最好的方法是对web.config文件的多个版本进行源代码管理，每个环境都有一个版本，然后在部署时选择合适的配置文件。

另一种方法是使用一个支持配置文件标记化的工具--这样，您就有一个配置文件，它只包含一个标记，在发布时可以用适当的值替换。但这将需要额外的工具和配置，您可能不感兴趣。