TFS2018迁移至Azure DevOps：全局列表操作替代方案咨询

我来帮你梳理下针对这个全局列表迁移的解决方案——witadmin确实是一个选项，但绝对不是唯一的，还有几个更适合代码集成、且能兼容本地TFS和未来Azure DevOps迁移的方案：

1. 原生witadmin命令行工具（最直接的本地兼容方案） #

witadmin是微软官方提供的针对TFS/Azure DevOps Server的工作项管理工具，完全支持本地TFS 2018，操作全局列表的命令非常成熟：

• 导出全局列表：

  witadmin exportgloballist /collection:http://your-tfs-server:8080/tfs/DefaultCollection /f:C:\temp\globalLists.xml
  

• 导入全局列表：

  witadmin importgloballist /collection:http://your-tfs-server:8080/tfs/DefaultCollection /f:C:\temp\globalLists.xml
  

优势：无需额外开发，原生支持所有本地TFS版本，导出的XML格式和原ExtendedClient的输出完全兼容，迁移成本极低。
劣势：需要处理命令行调用逻辑，如果是在自定义应用中集成，可能需要封装脚本或进程调用代码。

2. REST API（本地TFS也支持！） #

你提到REST API似乎不适用于本地环境，其实是找对端点和API版本就可以正常使用：

• 本地TFS 2018的REST API端点格式为：http://your-tfs-server:8080/tfs/DefaultCollection/_apis/wit/globallists
• 必须指定API版本：TFS 2018对应api-version=4.1
• 核心操作示例：
  • 获取所有全局列表（GET请求）：

    curl -u your-username:your-password "http://your-tfs-server:8080/tfs/DefaultCollection/_apis/wit/globallists?api-version=4.1"
    

  • 创建/更新全局列表（POST/PUT请求）：提交包含name和values字段的JSON即可
    优势：API格式和云端Azure DevOps服务完全一致，后续迁移到云端时几乎不需要修改代码；可以通过HTTP请求直接集成到自定义应用中。
    劣势：没有现成的导出XML方法，需要自己将返回的JSON数据序列化为XML格式（如果需要和原系统兼容）。

3. 新的Azure DevOps Server SDK（代码集成首选） #

微软现在推荐使用Microsoft.TeamFoundationServer.Client和Microsoft.VisualStudio.Services.Client这两个NuGet包替代旧的ExtendedClient，虽然没有直接的ExportGlobalLists/ImportGlobalLists方法，但可以通过WorkItemTrackingHttpClient实现相同功能：

using Microsoft.VisualStudio.Services.Client;
using Microsoft.VisualStudio.Services.WorkItemTracking.WebApi;
using Microsoft.VisualStudio.Services.WorkItemTracking.WebApi.Models;
using System.Collections.Generic;
using System.Threading.Tasks;

public async Task ManageGlobalLists()
{
    // 建立与TFS服务器的连接
    var tfsUri = new Uri("http://your-tfs-server:8080/tfs/DefaultCollection");
    var connection = new VssConnection(tfsUri, new VssCredentials());
    
    // 获取工作项跟踪客户端
    var witClient = connection.GetClient<WorkItemTrackingHttpClient>();
    
    // 1. 获取所有全局列表（模拟Export功能）
    var globalLists = await witClient.GetGlobalListsAsync();
    // 这里可以自己将globalLists序列化为XML，和原ExtendedClient的输出格式对齐
    
    // 2. 导入/更新全局列表（模拟Import功能）
    var newGlobalList = new GlobalList
    {
        Name = "MyCustomGlobalList",
        Values = new List<string> { "Option1", "Option2", "Option3" }
    };
    await witClient.CreateOrUpdateGlobalListAsync(newGlobalList);
}

优势：纯代码集成，完全兼容本地TFS 2018和云端Azure DevOps服务，后续迁移到云端时代码改动极小；类型安全，适合自定义应用集成。
劣势：需要自行实现XML导出的序列化逻辑，没有现成的一键导出方法。

总结选择建议 #

• 如果只是临时迁移或简单操作，优先用witadmin，成本最低；
• 如果需要在自定义应用中集成，且考虑未来迁移到云端，优先用新SDK或REST API，这两种方案的兼容性最好。

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