Azure事件中心发布了一个用于读取和写入事件中心的现代客户端库(Azure.Messaging.EventHubs(。新库应该取代旧库(Microsoft.Azure.EventHubs(，所以我想知道当前使用旧库的现有应用程序的升级路径应该是什么。
更具体地说，切换到新库是否意味着应用程序必须失去旧版本的检查点？虽然迁移指南清楚地解释了升级的好处以及代码示例，但我找不到任何关于数据丢失的内容。
事实证明，新SDK使用的检查点文件格式与旧版本不同，转换到新库意味着旧版本的检查点将不受尊重。新版本将从事件中心开始读取(根据指定的保留时间(。
两个版本的库都使用Azure blob存储来处理检查点和租约。然而，虽然旧库每个分区使用一个文件，但它包含JSON格式的检查点和所有者信息。例如，对于分区0，名为0的文件具有以下内容：
{"Offset":"0","SequenceNumber":0,"PartitionId":"0","Owner":"host-x","Token":<guid>","Epoch":62}
新库为每个分区使用两个文件，每个文件都在一个单独的文件夹中。文件夹名为ownership和checkpoint，每个分区id包含文件。所有权文件夹中的文件没有内容，所有者id在blob的元数据中说明。类似地，检查点文件夹中的文件没有内容，进度数据存储在元数据中的两个不同字段中：offset和sequencenumber。
此外，新库具有更复杂的文件夹结构：/EventHubsNamespace/EventHubs Name/CustomerGroupName/，而不是旧库中的旧/CustomerGroup Name/结构。
可以编写一个脚本将检查点文件迁移到新的格式，因为似乎所有需要的信息都可用，但我还没有测试过。
您的观察结果是正确的。这是一个不幸的决定，尽管是有意的，但不支持新客户端中的遗留检查点数据。为了实现为新的一组事件中心库设置的跨语言统一检查点数据的目标，并改进用于管理分区所有权的算法，有必要进行突破性的更改。
您完全正确，因为我们应该在迁移指南中强调这一点，提供有关如何迁移检查点数据的指导，理想情况下，提供一个帮助迁移的实用程序。这是最近引起我们注意的一个疏忽，我们正在跟踪一些工作来解决这个问题(参见：#1173，#1174(
短期内最好的解决方案是处理EventProcessorClient.PartitionInitializingAsync事件，并将接收到的参数中的PartitionInitializingEventArgs.DefaultStartingPosition值设置为记录在遗留检查点中的位置。这仅在第一次运行时是必要的，直到使用EventProcessorClient记录了新的检查点，但需要读取和解析遗留检查点blob以确定位置。此示例说明了该方法。