如何将基于Exchange EWS的日历同步工具迁移至Outlook Calendar REST API？

首先，先给你明确两个核心信息：

• 官方的Microsoft.Exchange.WebServices NuGet包已经处于维护模式，不会再更新新功能，微软也明确停止支持该包的基本身份验证方式。
• 如果你不想从零开发，有社区维护的过渡方案可以快速解决认证问题，而长远来看，迁移到Microsoft Graph是官方推荐的最终方向。

1. 短期过渡：升级认证逻辑（几乎不用改业务代码） #

社区维护的Exchange.WebServices.Managed.Api NuGet包是官方EWS API的分支，它支持.NET Core/.NET 5+，并且完美兼容OAuth2现代身份验证，刚好适配Office 365的新要求。

你只需要做两步：

• 卸载旧的Microsoft.Exchange.WebServices包，安装Exchange.WebServices.Managed.Api（当前最新版本已原生支持OAuth）
• 修改认证部分代码，替换原来的基本认证为OAuth2令牌认证：

  // 旧的基本认证写法
  // service.Credentials = new NetworkCredential("username", "password");
  
  // 新的OAuth2认证写法
  string accessToken = "从Azure AD获取的OAuth2访问令牌";
  service.Credentials = new OAuthCredentials(accessToken);
  

  这里的令牌需要通过Azure AD应用注册获取，根据你的应用类型（后台服务/用户交互类应用）选择客户端凭证流或授权码流即可。

这种方式几乎不用改动你的日历同步业务逻辑，就能快速解决基本认证停用的问题，给你足够时间做长远的迁移规划。

2. 长远最佳方案：迁移到Microsoft Graph #

微软已经明确将Microsoft Graph作为所有Office 365服务的统一API入口，EWS最终会被逐步淘汰，所以迁移到Graph是长期稳定的选择。你可以增量迁移，完全不用从零开发：

迁移步骤： #

• 第一步：Azure AD应用注册：在Azure门户创建应用，配置日历相关权限（比如Calendars.ReadWrite，根据同步需求选择应用权限或委派权限）
• 第二步：逐步替换API调用：
  • 把EWS中创建/更新/查询日历项的代码，替换为Graph对应的/me/calendar/events或/users/{id}/calendar/events端点
  • 利用Graph的Delta查询优化同步效率，它能跟踪日历项的增量变化，避免全量同步的性能损耗
  • 举个获取日历增量变化的Graph代码示例：

    var deltaLink = string.Empty;
    do
    {
      var events = await graphClient.Me.Calendar.Events
        .Delta()
        .Request()
        .GetAsync();
      // 处理获取到的日历变更项
      deltaLink = events.AdditionalData["@odata.deltaLink"]?.ToString();
    } while (!string.IsNullOrEmpty(deltaLink));
    

• 第三步：测试与过渡：先在测试环境替换部分同步逻辑，验证功能正常后，再逐步替换全部代码，实现平滑过渡。

常见疑问解答 #

• Q：原来的EWS业务逻辑能不能直接复用？
  A：大部分日历操作都有对应的Graph API，核心逻辑可以完全复用，只是API调用方式不同。比如EWS的FindItems对应Graph的List events，CreateItem对应Create event。
• Q：Graph的同步效率比EWS高吗？
  A：是的，Graph的Delta查询是专门为同步场景设计的，比EWS的SyncFolderItems更高效，还支持更多灵活的筛选条件。

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