TFS2017 vNext Build GetSources任务无法拉取受限权限LicenseManager代码

刚好碰到过类似的TFS vNext Build权限适配问题，先帮你梳理下核心矛盾，再给你几个靠谱的解决方向：

问题核心原因 #

你遇到的问题本质是vNext Build默认的身份验证逻辑和原XAML Build的权限模型不匹配：

• 原XAML Build直接用代理服务运行账户的身份拉取源码，这个账户刚好在LicenseManager文件夹的权限列表里
• 但vNext Build的GetSources任务默认会使用/loginType:OAuth参数，也就是用TFS构建服务的OAuth令牌做身份验证——这个OAuth身份并没有被授权访问受限的LicenseMgr\dev\main文件夹，哪怕代理服务账户有权限也没用，因为GetSources根本没用到这个账户的身份

这也解释了两个反常现象：在VS里用工作区执行「Get Latest」正常，以及用不带OAuth参数的tf get命令能成功——这两种方式都是用代理服务账户的身份在操作，而非OAuth令牌。

可行解决方案 #

方案1：修改GetSources任务的身份验证模式（推荐） #

直接在LicenseManager的构建定义里调整GetSources任务的身份验证方式：

1. 打开目标构建定义，找到GetSources步骤
2. 将身份验证选项从默认的「OAuth」改为「集成」
3. 保存并重新运行构建

这样GetSources任务就会使用代理服务运行账户的身份拉取源码，和原XAML Build的逻辑完全一致，自然就能访问受限文件夹了。

方案2：替换GetSources为自定义脚本 #

如果因为某些原因需要保留OAuth验证，也可以移除默认的GetSources任务，改用自定义脚本完成源码拉取：

• 添加一个「PowerShell脚本」或「批处理脚本」任务到构建流程最开头
• 在脚本里调用tf get命令，不要添加/loginType:OAuth参数，确保用代理服务账户的身份执行
• 用这个脚本替代原来的GetSources任务即可

方案3：调整权限（不推荐） #

把TFS构建服务的OAuth身份添加到LicenseManager源码文件夹的权限组里，但这种方式会打破你原本的权限管控边界，扩大可访问该文件夹的身份范围，所以除非万不得已，不建议这么做。

内容的提问来源于stack exchange，提问作者PainElemental