ModelContextProtocol C SDK中的JSON反序列化问题解析

在ModelContextProtocol C# SDK的开发过程中，开发人员遇到了一个关于ElicitRequestParams类反序列化的技术问题。这个问题涉及到JSON序列化/反序列化过程中的类型处理机制，值得深入探讨。

问题背景

ElicitRequestParams类中的RequestSchema属性包含两个接口类型的成员：

1. Required属性（IList类型）
2. Properties属性（IDictionary<string, PrimitiveSchemaDefinition>类型）

当尝试从JSON反序列化包含非空Schema的ElicitRequestParams对象时，系统会抛出NotSupportedException异常，提示"Deserialization of interface or abstract types is not supported"。

技术分析

这个问题源于System.Text.Json在.NET中的设计限制。JSON反序列化器需要知道具体的实现类型来创建实例，而接口或抽象类无法直接实例化。具体来说：

1. 接口类型问题：IList和IDictionary<string, PrimitiveSchemaDefinition>都是接口，反序列化器无法确定应该使用哪个具体实现类（如List或Dictionary<string, PrimitiveSchemaDefinition>）。

2. 抽象类问题：PrimitiveSchemaDefinition可能是一个抽象类或接口，同样无法直接实例化。

3. 解决方案对比：

   • 指定具体实现类型（如改为List和Dictionary<string, PrimitiveSchemaDefinition>）
   • 为接口类型注册自定义转换器（JsonConverter）
   • 使用支持多态序列化的特性（如[JsonDerivedType]）

实际影响

这个问题会导致以下场景失败：

1. 当Schema不为空时（所有测试用例都使用空的ElicitRequestParams）
2. 从服务器向客户端发送请求时
3. 客户端尝试反序列化请求参数时

解决方案演进

开发团队采用了以下修复方案：

1. 将接口类型改为具体实现类型
2. 确保所有抽象类型都有具体实现
3. 发布了包含修复的新版本NuGet包（0.3.0-preview.2）

最佳实践建议

在处理类似问题时，建议：

1. 在DTO类中优先使用具体类型而非接口
2. 对于必须使用接口的场景，提前规划好转换器
3. 编写包含各种数据情况的测试用例，而不仅仅是默认值测试
4. 考虑使用Newtonsoft.Json（如果项目允许）作为替代方案，它在处理多态类型时更灵活

总结

这个案例展示了在C#中使用System.Text.Json进行序列化时需要注意的类型系统约束。通过将接口改为具体实现类，开发团队解决了反序列化问题，确保了ModelContextProtocol SDK在复杂场景下的可靠性。这也提醒我们在设计可序列化类型时，需要仔细考虑类型层次结构和反序列化需求。