怪异的BinaryFormatter deseralization错误

我在我的应用程序的一个遇到一个非常奇怪的异常（后来被引用为ApplicationB）怪异的BinaryFormatter deseralization错误

`Unable to find assembly 'MsgPack, Version=0.5.0.0, Culture=neutral, PublicKeyToken=a2625990d5dc0167'.`

这里是我的方案，我ApplicationA我有一个序列化的对象使用MsgPack并使用SE.Redis将其存储到Redis中。稍后，我查询这个对象并反序列化它（当然仍然使用MsgPack）。完成此操作后，我通过TCP/Componennt发送此对象，该对象使用BinaryFormatter对该同一对象进行序列化。另一方面，即在应用程序B，一旦数据包到达，它使用BinaryFormatter反序列化，这是我得到例外。

我对TCP/Component及其使用的序列化程序没有任何控制权。

那么，为什么我会得到这个错误应用程序B应该知道关于MsgPack的任何事情？

只是一个我想分享的想法，似乎MsgPack实时创建DataContract，并且在反序列化时，它可能会在与BinaryFormatter冲突的对象上应用一些属性。当然，我不确定这一点。

但有没有人遇到过这个问题？

干杯。

编辑：我注意到，对于类型对象的成员，MsgPack添加了很多用于在对象成员中定义类型存储的成员（如IsDictionary，IsList等）。它会影响BinaryFormatter吗？

来源

2015-04-30 Pascal B.

这是一个简单的“文件未找到”错误。最明显的原因是MsgPack.dll不在ApplicationB的探测路径中。或者它有错误的版本。使用Fuslogvw.exe解决程序集解析问题。 –

我不需要** ApplicationB **上的MsgPack.dll，它甚至不应该知道MsgPack。 –

嗯，当然你有。它大声地对你大喊。 –

使用二进制序列化时，只有完全限定类型名称及其数据被序列化为字节数组。另一方的序列化器想要反序列化其数据。它首先从字节数组中读取类型名称，并尝试查找并实例化该类型。该类型必须位于DLL中的某个位置。所以它寻找给定的DLL（在你的案例MsgPack），但它不能被发现。因此：确保DLL MsgPack位于两侧。

如果无法将DLL放在另一边，您可以尝试序列化DLL本身并将其发送到另一端。首先反序列化DLL，将其放入bin文件夹或将其加载到内存中，然后使用其数据反序列化该类型。但是，如果你想这样做，你必须真的确实确定。我不会。

你有没有考虑过在AppA和AppB之间使用WCF进行通信？

来源

2015-04-30 12:28:49

怪异的BinaryFormatter deseralization错误

回答

相关问题