フィールドやカスタムクラスなどのデータをシリアル化して、バイナリデータ（バイト配列）を作成しています。
Deserialize次に、バイナリデータからフィールドとクラスに戻したいと思います。
しかし、例外があります。これらの2つの方法が同じアセンブリで発生する場合は、すべて正常に機能しますが、そうではありません。
あるアセンブリでシリアル化を行い、別のアセンブリで逆シリアル化を行います。そして、これも言い訳です：
Unable to find assembly 'MyAssamblyName, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.
注1：フィールドを元に戻すことに問題はありません。クラスのみがフィールドを引き起こします。
注2：両方のアセンブリに同じクラスがあります。
注2：両方のアセンブリに同じクラスがあります
いいえ、しません。少なくとも、ランタイムに関する限りではありません。同じ名前の2つの異なるタイプがあります。タイプは、そのアセンブリによって定義されます。したがって、同じソースファイルからコンパイルされた場合でも、SomeType「inAssemblyA」は「inAssemblyB」とは完全に異なります。SomeType
BinaryFormatterは型情報を処理するため、これは機能しません。1つのオプションは、他の両方のプロジェクトが参照するライブラリdllに型を移動することです。これにより、定義は1回だけになり、問題ありません。
もう1つのオプションは、（タイプベースのシリアライザーではなく）コントラクトベースのシリアライザーを使用することです。これは、たとえそれらが異なるアセンブリにある場合でも（そして、それが「十分に類似している」限り、おそらく異なるソースを持っている場合でも）、「十分に類似しているように見えるクラス」は問題ないことを意味します。これに適したシリアライザーの例には、（および他のいくつかの）XmlSerializer、DataContractSerializer（ただし、NetDataContractSerializerは除く）、JavaScriptSerializer、または高密度のrawバイナリが必要な場合はprotobuf-netが含まれます。
デシリアライズするオブジェクトのクラス階層内のクラスを含むすべてのアセンブリは、このデシリアライズを実行するアプリケーションに存在する必要があります。これらは、明示的に参照するか（これらのクラスでコンパイル時の安全性が必要な場合）bin、実行時に解決できるようにアプリケーションのフォルダーにのみ配置することができます。それらが明示的に参照されていない場合は、逆シリアル化されたインスタンスから値を読み取るためにリフレクションを使用する必要があります。