32位C# ExcelDNA插件反序列化64位BinaryFormatter时出现类型转换错误

这个问题我之前帮不少开发者排查过，核心原因是BinaryFormatter的序列化机制高度依赖CLR的类型元数据和程序集标识，32位与64位环境下，哪怕类型的代码定义完全一致，CLR也可能因为程序集加载上下文、位数相关的元数据差异，将它们判定为完全不同的类型，最终抛出你看到的强制转换异常。

下面是几种可行的解决方案，按推荐优先级排序：

1. 替换BinaryFormatter为跨位数兼容的序列化库 #

BinaryFormatter已经被微软标记为不安全（存在远程代码执行风险），而且天生对跨环境兼容性支持很差，最彻底的解决方式是用更现代的序列化库替代，比如：

• System.Text.Json（.NET Core/.NET 5+原生支持）
• Newtonsoft.Json（Json.NET，兼容所有.NET版本）
• Protobuf（Google的二进制序列化库，性能高、体积小）

这些库基于数据结构而非CLR类型元数据进行序列化，完全不受32/64位环境差异的影响。举个Newtonsoft.Json的替换示例：

64位应用端（序列化） #

// 替换原来的BinaryFormatter序列化代码
var data = Tuple.Create(yourStringIntDict, yourStringPropertyNamesDict, yourDataOutput);
// 如果有复杂类型继承，开启TypeNameHandling保留类型信息
var jsonSettings = new JsonSerializerSettings { TypeNameHandling = TypeNameHandling.All };
string jsonData = JsonConvert.SerializeObject(data, jsonSettings);
File.WriteAllText("serialized_data.json", jsonData);

32位ExcelDNA插件端（反序列化） #

// 反序列化代码
string jsonData = File.ReadAllText("serialized_data.json");
var jsonSettings = new JsonSerializerSettings { TypeNameHandling = TypeNameHandling.All };
var deserializedData = JsonConvert.DeserializeObject<Tuple<Dictionary<string, int>, Dictionary<string, MyPropertyNames>, DataOutput>>(jsonData, jsonSettings);

2. 若必须保留BinaryFormatter，确保共享类型来自同一强名称程序集 #

如果因为历史原因必须使用BinaryFormatter，要解决类型标识不一致的问题，关键是让32位插件和64位应用使用完全相同的类型定义，且来自同一个强名称程序集：

• 提取共享类型到独立类库：把Tuple中涉及的所有自定义类型（比如MyPropertyNames、DataOutput）以及需要共享的泛型类型依赖，提取到一个单独的类库项目中。
• 给类库添加强签名：在类库项目的属性中生成强名称密钥对，确保程序集有唯一的标识（名称、版本、公钥令牌）。
• 统一引用类库：64位应用和32位ExcelDNA插件都直接引用这个强名称类库的同一个版本，绝对不能在两边各自复制类型定义（哪怕代码完全一样，CLR也会视为不同类型）。
• 检查程序集加载：用dnSpy等工具确认插件加载的类库版本与64位应用使用的完全一致，避免因为绑定重定向、本地复制等问题加载了不同版本的程序集。

3. 额外排查要点 #

• 确认两边的类型定义完全一致：包括命名空间、类名、所有字段/属性的名称、类型（包括私有成员，因为BinaryFormatter会序列化私有成员）。
• 检查泛型参数的匹配：错误信息中的Tuple泛型参数要完全对应，比如64位端的MyApplication.DataOutput要和插件端引用的同一个类型完全匹配，不能是插件自己定义的同名类型。

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