问题标签 [xamlbuild]

我正在更新我的 XAML 构建工作流和与之配套的自定义程序集。我在带有测试构建代理的机器上有一个测试构建控制器。

我还想在我的实时构建机器上为这个控制器部署一个测试代理（这是更快的硬件）。

在 Visual Studio 中，如果我转到 Manage Build Controllers 对话框，我可以通过为其提供新版本自定义程序集的路径来配置我的测试控制器。

我的测试控制器和实时控制器具有不同版本的自定义程序集。

我认为构建代理运行的构建服务是一个进程，因此我不确定一个进程是否可以加载自定义程序集的两个不同版本（因为此自定义程序集的实时和测试版本具有相同的名称）。

我可以像这样混合和匹配...在一台机器上构建代理，这些代理注册了不同的控制器，这些控制器本身具有不同版本的自定义程序集？

更新

我找到了这个页面...

http://mohamedradwan.com/2013/01/15/understanding-build-controller-and-build-agent-for-tfs-team-foundation-server/

...它的图表似乎显示了一台机器上的两个代理，这些代理注册了不同的控制器。我仍然不确定它是如何工作的，因为我不确定单个服务是否可以加载自定义程序集的两个不同版本。

更新 2

也许应用程序域允许这个工作？

https://msdn.microsoft.com/en-us/library/2bh4z9hs(v=vs.110).aspx

我想以与构建文件相同的结构来组织我的文件：

• 解决方案1
  • 项目1
  • 项目2

目前我处理每个项目的输出路径（..\bin\NameProject）有这个：

• 解决方案1
  • 项目1
  • 项目2

但是在每个项目中（所以在 project1 和 project2 中），我找到了所有项目中的所有 DLL/可执行文件。我希望 project1 的输出只接收来自 project1 的 DLL/可执行文件，对于 project2 也是如此。

然后，我想用构建过程模板（https://msdn.microsoft.com/en-us/library/dd647551(v=vs.120).aspx）来解决这个问题，所以我有这个结构：

• *构建过程模板

  • -BuildProcessSource

    • 模板（里面有我的 CustomTemplate.xaml）

• 解决方案1

  • -项目1

  • -项目2

但我不知道这一步如何帮助我。也许这不是好方法。你有想法吗？

感谢你们对我的帮助！

编辑

我想要的输出正是例如：

我试图弄清楚为什么我的构建失败了，所以在我添加的构建调用的 .proj 中：

现在在执行此操作时，我假设 $(SourceDir) 将解析为 C:\Builds\$(BuildDefinitionId)，因为这是我在代理的工作目录设置中所拥有的。我还在 MSBuild 参数中设置了一个变量：

但是当 .proj 运行时，这是我的输出：

所以似乎只有 $(SystemDrive) 在构建过程中持续存在。而且我在 MSBuild args 中设置的参数似乎甚至没有正确设置（SrcDir）。如何在构建过程中访问这些变量，以便知道我的文件在哪里？我需要调用一些其他程序（即 attrib）并传入我的文件的位置，但似乎没有任何东西会持续存在。

根据这篇文章，我确信 TF_BUILDDIRECTORY 可以工作，但它没有。

然后我尝试使用这篇文章说这应该有效：

虽然 TeamProject 有效，但 BuildDirectory 却没有。所以我明白了：

我正在尝试使用 MTM 运行编码的 ui 测试用例。我使用 XAML 构建在代理机器中运行测试用例从本地机器触发测试用例时一切正常。但是，当我在代理机器中从 MTM 运行测试用例时，我收到以下错误消息

有人可以帮忙吗？

注意：我在不同的解决方案（具有不同的 XAML 构建）中确实有一些其他测试用例，它们工作正常。

我正在使用 Visual Studio 2015。

我们安装了应该运行 xaml 构建的最新 TFS 服务器（TFS 2018 Update 2）。更新后，我们启动了我们的代理，但是我们的 xaml-controller 仍然离线，我不知道我如何再次启动它..

任何想法我们可以做什么？

有没有办法在 TFS 构建运行时检查构建目录中是否存在特定的 .xml 文件？

我正在尝试根据找到/未找到的结果来获得布尔结果真/假

我尝试创建一个变量来存储这个结果（我猜这就是这样做的方法）。但是，在尝试使用它时出现错误。

以前，XAML 门控构建用于仅使用一个门控构建定义签入属于不同解决方案的 TFS 中的多个工作区的文件。

我的意思是，就像开发人员过去只使用一个门控构建定义来检查 TFS 中的多个文件，即使这些文件的工作空间没有映射到旧的 XAML 门控构建定义中。

但是在迁移到 TFS 2017 更新 3 之后，情况就不一样了，我们必须为 TFS 中不同路径上的每个解决方案创建单独的门控构建定义。（虽然我会说这是一个很好的做法，并且可以防止在 TFS 中检查任何损坏的代码，但它的缺点是为我们签入的每个解决方案和文件更改创建了多个更改集）

为避免出现多个变更集问题，一种选择是创建一个门控构建定义，该定义将为我们拥有并将构建的所有 8 个解决方案映射工作区，并允许开发人员使用一个门控构建定义签入多个文件，但它也有它的缺点构建时间将无缘无故地增加，即使您签入一个文件，它也会构建其他解决方案。

那么是否有任何其他选项可以解决这个问题，即允许开发人员通过一个门控构建本身签入多个文件并同时维护代码完整性检查？

我的问题是关于 vNext/Octopus 进程与基于 XAML 的进程的可维护性。或者更确切地说，因为不可能保持他们的理智让我相信我们正在做一些非常错误的事情。

鉴于：

• 微软推动逐步淘汰其 TFS XAML 构建以支持 vNext 构建
• Octopus Deploy 是一个流行的部署自动化框架
• 我们有许多基于 XAML 的构建，但开始移植到 vNext
• 使用 Octopus Deploy 自动部署

具体来说，我们在 QA 中进行了三种构建：

• 旧的基于 XAML 的编译生成生成要部署的工件
  • 最终只是构建代码，将其压缩并放置在众所周知的位置
• 新的 vNext 编译构建生成要部署的工件
  • 和上面一样
• 部署构建
  1. 每个部署环境的基于 XAML 的构建定义。这是特定部署的真实来源，包含所有配置 URL、连接字符串、证书指纹等。构建定义有 100 多个构建参数。每次设置新环境时，我们都会克隆现有的 XAML 构建定义并更改参数。
     • 此构建解压构建工件，根据配置参数生成所有 web/app 配置文件，并使用 octo.exe 启动带有大量参数的 Octopus Deploy 并等待结束
  2. 八达通部署流程
     • 从先前由 XAML 构建解包的构建工件创建 3 个包，以匹配三个部署区域 - Web 场、后台作业引擎集群和数据库
     • 将相关包裹递送至相关触手。
     • 触手解包并设置它们各自的包

因此，如果我们有 50 个部署环境，那么我们就有 50 个 XAML 部署构建，每个构建都捕获各自环境的上下文。但是 XAML 部署构建将部署工作委托给 Octopus，在这里我们被迫拥有 50 个 Octopus 项目 - 每个部署一个。

为什么会这样？我们研究了仅拥有一个 Octopus 项目的选项，但该项目的发布版本是什么？为了让我们能够在海量版本中导航，发布版本必须包括：

• 已部署代码的构建版本，例如55.0.18709.3
• 部署环境的名称，例如atwfm

使用上面的例子，这给了我们55.0.18709.3-atwfm，但有时我们想在同一个部署环境中部署相同的构建工件两次。但是唯一的 Octopus 项目已经有 release 了55.0.18709.3-atwfm，那么如何在不删除已经存在的 release 的情况下再次部署55.0.18709.3呢atwfm？

我们找不到解决方法，因此，我们每个部署都有 Octopus 项目。

这太疯狂了，因为 Octopus 项目更新起来很痛苦。假设我们需要添加一个步骤——在 50 个项目中进行。互联网上有很多建议使用自动化来编辑多个项目。一点都不理想。

vNext，顺便说一句，也有同样的问题。如果我要将现有的 XAML 构建移植到 vNext，我最终会得到 50 个 vNext 部署构建。如果我决定添加一个步骤，我需要在所有 50 个构建中都这样做！！！！

请注意，XAML 构建没有这个问题（尽管它们还有很多其他问题），因为它们的过程与参数是分开的。我可以修改一次工作流，所有 XAML 构建现在都使用新的流程更改进行更新。

我的问题是——人们如何使用 vNext 和 Octopus，因为我们的流程让我发疯。一定会有更好的办法。

编辑 1

我想澄清一下。我们有时想要两次部署相同的构建工件。我们不会重新编译它们并重用相同的版本。不。我们已经有了方便的构建工件，构建版本在工件内部烘焙。我们可能希望第二次将其部署到同一环境中，因为例如，该环境中的某些数据库配置错误，现在已修复，我们需要重新部署。这并不意味着我们可以重新运行已经存在的 Octopus 版本，因为修复可能涉及调整相应 XAML 部署构建定义的部署参数。因此，我们可能会被迫重新启动 XAML 部署构建，它永远不会编译代码。

编辑 2

首先，为什么我们从 TFS XAML 构建而不是从 Octopus 驱动部署？历史原因。起初我们没有八达通。部署是由我们的临时代码完成的。当我们介绍 Octopus 时，我们决定保留 XAML deploymenet 构建有两个原因：

1. 为了节省将具有所有大量部署参数的所有 XAML 部署构建迁移到 Octopus 的成本。也许这是一个错误的决定，也许我们可以自动化迁移。
2. 因为 TFS 有更好的工具来显示测试结果。部署可能以部署冒烟测试结束，其结果必须在某处发布。我们看不到 Octopus 如何帮助我们发布结果，TFS 可以。

为什么要重新部署？例如，部署参数之一是证书指纹。更新证书时，必须更改此参数（我们确实可以自动更新 XAML 构建参数）。但我们经常发现它已经使用错误的指纹进行部署。因此，我们修复了部署并重新部署。或者，我们发现已部署应用程序的一些奇怪行为，并希望重新部署一些额外的跟踪/调试功能。

我们已经升级了 TFS 服务器 Azure DevOps Server 2019。我在将 2015 XAML 构建服务器连接到新 URL 时遇到了一些问题。我需要完全卸载 2015 XAML 构建服务器，以便在我重新启动安装时不会留下任何设置并预先填充。从控制面板卸载 Team Foundation Server 似乎没有这样做。卸载后我还需要清除什么？

我们最近从 TFS 2013 迁移到 Azure Devops 2019（本地）我们有两台服务器，TFS 服务器正在运行 Azure DevOps 2019，构建控制器正在 TFS 2010 上运行。因此，较旧的 XAML 构建运行良好。

我们最近将应用服务器上的 .net 框架从早期的 v 4.5 升级到了 4.8

我们想使用最新的 C# 功能，但无法在构建服务器上构建这些功能。

为此，我们要使用支持 C#-6 语言功能的 tfvctemplate.12.xaml 构建模板。

但是在将 default.xaml 构建模板更改为上述构建 tfvctemplate.12.xaml 模板之后，并且在对构建进行排队之后出现错误。

TF900558：此构建过程模板无法在构建服务器默认控制器 - TFSBUILDSVR3 上运行。将此构建服务器升级到更新的版本。

我们在构建控制器上安装了 Azure Devops 2019，但无法像为 TFS 2010 那样配置构建控制器。

任何帮助表示赞赏！