🤰🏽 👍🏾 👨‍👨‍👧 ソースタイプのアセンブリを参照しない.Netバイナリシリアル化、またはBinaryFormatterとの交渉方法 ◀️ 🈹 🕺🏾

この記事では、相互に参照せずに、アセンブリ間でバイナリ型のシリアル化の経験を共有します。判明したように、データが宣言されているアセンブリへのリンクを持たずにデータを逆シリアル化する必要がある場合、実際の「正当な」ケースがあります。記事では、それが必要とされたシナリオについて説明し、解決方法を説明し、検索中に行われた中間エラーについても説明します。

はじめに問題の声明

地質学の分野で働く大企業と協力しています。歴史的に、企業は、さまざまなタイプの機器+データ分析+予測からのデータを処理するための非常に異なるソフトウェアを作成してきました。残念ながら、このソフトウェアはすべて互いに常に「友好的」とはほど遠く、まったく友好的ではありません。何らかの方法で情報を統合するために、さまざまなプログラムがデータをxml形式でアップロードするWebポータルが作成されています。そして、ポータルはプラスマイナス完全なビューを作成しようとしています。重要なニュアンス：ポータルの開発者は各アプリケーションのサブジェクト領域に精通していないため、各チームはXMLからポータルデータ構造へのパーサー/データコンバーターモジュールを提供しました。

私はアプリケーションの1つを開発するチームで働いており、データのエクスポートメカニズムを非常に簡単に記述しました。しかし、ここで、ビジネスアナリストは、中央ポータルでプログラムが作成するレポートの1つが必要であると判断しました。これが最初の問題が発生した場所です。レポートは毎回作成され、結果はどこにも保存されません。

「保存してください！」読者はおそらく考えるでしょう。私もそう思っていましたが、ダウンロードしたデータのレポートをすでに作成する必要があることに真剣に失望しました。何もする必要はありません-ロジックを転送する必要があります。

ステージ0。リファクタリング。トラブルの前兆はない

レポートを構築するロジック（実際、これは4列のラベルですが、ロジックはキャリッジと大きなカートです）を別のクラスに分離し、パーサーアセンブリ内の参照によってこのクラスのファイルを含めることが決定されました。これにより：

直接コピーを避ける
バージョンの不一致から保護する

ロジックを別のクラスに分離するのは難しい作業ではありません。しかし、すべてがそれほどバラ色ではありませんでした。アルゴリズムはビジネスオブジェクトに基づいており、その転送は概念に適合しませんでした。メソッドを書き換えて、単純な型のみを受け入れて操作するようにしました。それは必ずしも単純ではなく、場所によっては決定が必要であり、その美しさは問題のままでしたが、一般に、信頼できる解決策は明らかな松葉杖なしで得られました。

ご存じのように、悪魔の居心地の良い隠れ家として役立つことがある詳細が1つありました。レポートを作成するために必要なデータの一部がバイナリシリアル化された.Netオブジェクトとしてデータベースに保存される、前世代の開発者から奇妙なアプローチを継承しました（「なぜ？」、「kaaak？」などの質問は、宛先が不足しているため未回答のままになります）。そして、計算の入力では、もちろん、それらを逆シリアル化する必要があります。

これらのタイプは、取り除くことは不可能でしたが、特に複雑ではないため、「参照による」ことも含めました。

ステージ1.デシリアライゼーション。完全なタイプ名を覚えておいてください

上記の操作を行ってテストを実行した後、予期せずランタイムエラーが発生しました。

[A] Namespace.TypeAは[B] Namespace.TypeAにキャストできません。タイプAは、「Assembley.Application、Version = 1.0.0.0、Culture = neutral、PublicKeyToken = null」に由来し、コンテキスト「Default」の場所「...」にあります。タイプBは、場所 ''のコンテキスト 'Default'の 'Assmbley.Portal、Version = 1.0.0.0、Culture = neutral、PublicKeyToken = null'から発生します。

最初のGoogleリンクから、BinaryFormatterがデータだけでなく、論理的な出力ストリームに型情報も書き込むという事実があることがわかりました。そして、型のフルネームが宣言されたアセンブリを含むことを考えると、1つの型をデシリアライズしようとしたものの絵は、.Netの観点とはまったく異なります

私は頭の後ろをひっかいたので、たまたま、デシリアライズ中に特定のTypeAタイプをdynamicに置き換えるという明らかな、しかし残念な悪意のある決定を下しました。すべてがうまくいきました。レポートの結果は次々と収束し、ビルドサーバーでのテストに合格しました。達成感を持って、タスクをテスターに送ります。

ステージ2。メイン。アセンブリ間のシリアル化

計算はテスターによって登録されたバグの形ですぐに起こりました。これは、アセンブリAssembley.Application（アプリケーションからのアセンブリ）を読み込むことができないという例外を除いて、ポータル側のパーサーが落ちたと述べました。最初に考えた-私は参照をきれいにしませんでした。しかし-いいえ、すべてがうまくいき、誰も言及しません。サンドボックスでもう一度実行してみます-すべてが機能します。ビルドエラーが疑われるようになりましたが、ここで私を喜ばせないアイデアが浮かびました。パーサーの出力パスを、アプリケーションの共有binディレクトリではなく、別のフォルダーに変更します。そして出来上がり-私は説明された例外を取得します。 Stectrace分析は曖昧な推測を確認します-デシリアライゼーションは低下しています。

特定の型を動的に置き換えても何も変わりませんでした。BinaryFormatterは外部アセンブリから型を作成しました。型を持つアセンブリが近くにあり、ランタイムが自然にロードし、アセンブリがなくなった場合のみです。エラーが発生します。

悲しい理由がありました。しかし、グーグルはSerializationBinderクラスの形で希望を与えました。判明したように、データを逆シリアル化するタイプを決定できます。これを行うには、相続人を作成し、次のメソッドを定義します。

public abstract Type BindToType(String assemblyName, String typeName);

特定の条件に対して任意の型を返すことができます。

BinaryFormatterクラスには、実装を挿入できるBinderプロパティがあります。

問題ないと思われます。しかし、ここでも詳細は残っています（上記参照）。

まず、 すべてのタイプ（および標準）のリクエストを処理する必要があります。

ここで興味深い実装オプションがインターネット上で見つかりましたが、彼らはBinaryFormatterからデフォルトのバインダーを構築の形で使用しようとしています
 var defaultBinder = new BinaryFormatter().Binder
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     
しかし、実際には、バインダープロパティはデフォルトでnullです。ソースコードの分析により、BinaryFormatter内では、Binderがチェックされるかどうか、チェックされる場合、そのメソッドが呼び出され、チェックされない場合、内部ロジックが使用され、最終的には
  var assembly = Assembly.Load(assemblyName); return FormatterServices.GetTypeFromAssembly(assembly, typeName);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さらに苦労せずに、私は自分自身で同じ論理を繰り返しました。

これが最初の実装で起こったことです

 public class MyBinder : SerializationBinder { public override Type BindToType(string assemblyName, string typeName) { if (assemblyName.Contains("<ObligatoryPartOfNamespace>") ) { var bindToType = Type.GetType(typeName); return bindToType; } else { var bindToType = LoadTypeFromAssembly(assemblyName, typeName); return bindToType; } } private Type LoadTypeFromAssembly(string assemblyName, string typeName) { if (string.IsNullOrEmpty(assemblyName) || string.IsNullOrEmpty(typeName)) return null; var assembly = Assembly.Load(assemblyName); return FormatterServices.GetTypeFromAssembly(assembly, typeName); } }

つまり名前空間がプロジェクトに属しているかどうかが確認されます-現在のドメインから型を返し、システムの型であれば、対応するアセンブリから読み込みます

論理的に見えます。私たちはテストを開始します：私たちのタイプが来る-私たちは置き換え、それが作成されます。やった！文字列が来る-アセンブリからロードしながらブランチに沿って進みます。うまくいく！バーチャルシャンパンを開く...

しかし、ここに...辞書にはユーザータイプの要素が含まれています：これはシステムタイプなので、...明らかに、アセンブリからロードしようとしていますが、要素は私たちのタイプであり、完全修飾（アセンブリ、バージョン、キー）、それから再び落ちます。（悲しい笑顔があるはずです）。

明らかに、型の入力名を変更して、目的のアセンブリへのリンクを置き換える必要があります。型名には、 AssemblyNameクラスの類似物があることを本当に望みましたが、類似するものは見つかりませんでした。置換を伴うユニバーサルパーサーの作成は簡単な作業ではありません。一連の実験の後、次の解決策に行きました：静的コンストラクターで、置き換える型を減算し、作成された型の名前を持つ行で名前を探し、見つかったらアセンブリ名を置き換えます

  /// <summary> /// The types that may be changed to local /// </summary> protected static IEnumerable<Type> _changedTypes; static MyBinder() { var executingAssembly = Assembly.GetCallingAssembly(); var name = executingAssembly.GetName().Name; _changedTypes = executingAssembly.GetTypes().Where(t => t.Namespace != null && !t.Namespace.Contains(name) && !t.Name.StartsWith("<")); //!t.Namespace.Contains(name) - .     ,         // "<'      -     } private static string CorrectTypeName(string name) { foreach (var changedType in _changedTypes) { var ind = name.IndexOf(changedType.FullName); if (ind != -1) { var endIndex = name.IndexOf("PublicKeyToken", ind) ; if (endIndex != -1) { endIndex += +"PublicKeyToken".Length + 1; while (char.IsLetterOrDigit(name[endIndex++])) { } var sb = new StringBuilder(); sb.Append(name.Substring(0, ind)); sb.Append(changedType.AssemblyQualifiedName); sb.Append(name.Substring(endIndex-1)); name = sb.ToString(); } } } return name; } /// <summary> /// look up the type locally if the assembly-name is "NA" /// </summary> /// <param name="assemblyName"></param> /// <param name="typeName"></param> /// <returns></returns> public override Type BindToType(string assemblyName, string typeName) { typeName = CorrectTypeName(typeName); if (assemblyName.Contains("<ObligatoryPartOfNamespace>") || assemblyName.Equals("NA")) { var bindToType = Type.GetType(typeName); return bindToType; } else { var bindToType = LoadTypeFromAssembly(assemblyName, typeName); return bindToType; } }

ご覧のとおり、PublicKeyTokenが型の説明の最後であるという事実から始めました。おそらくこれは100％信頼できるものではありませんが、私のテストでは、そうでない場合は見つかりませんでした。

したがって、次の形式の行

"System.Collections.Generic.Dictionary`2 [[SomeNamespace.CustomType、Assembley.Application、Version = 1.0.0.0、Culture = neutral、PublicKeyToken = null]、[System.Byte []、mscorlib、Version = 4.0.0.0、カルチャー=ニュートラル、PublicKeyToken = b77a5c561934e089]]»

になります

"System.Collections.Generic.Dictionary`2 [[SomeNamespace.CustomType、Assembley.Portal、Version = 1.0.0.0、Culture = neutral、PublicKeyToken = null]、[System.Byte []、mscorlib、Version = 4.0.0.0、カルチャー=ニュートラル、PublicKeyToken = b77a5c561934e089]]»

今ではすべてが「時計のように」最終的に機能しました。技術的な微妙な微妙な点が残っています。覚えているなら、私たちが含めたファイルはメインアプリケーションからのリンクに含まれていました。しかし、メインアプリケーションでは、これらすべてのダンスは必要ありません。したがって、次の形式の条件付きコンパイルメカニズム

 BinaryFormatter binForm = new BinaryFormatter(); #if EXTERNAL_LIB binForm.Binder = new MyBinder(); #endif

したがって、ポータルアセンブリではマクロEXTERNAL_LIBを定義しますが、メインアプリケーションでは-いいえ

「非叙情的な余談」

実際、コーディングの過程で、解決策をすばやく確認するために、1つの計算ミスをしました。これにより、おそらく一定数の神経細胞が犠牲になりました。まず、Dicitionaryの型置換をハードコーディングしました。その結果、逆シリアル化の後、空のディクショナリが得られました。このディクショナリは、いくつかの操作を実行しようとすると「クラッシュ」しました。 BinaryFormatterを欺くことはできないと既に考え始めていたので、辞書の相続人を書く試みで必死の実験を始めました。幸いなことに、私はほぼ定刻に停止し、普遍的な代替メカニズムの作成に戻り、それを実装して、辞書を作成するだけではその型を再定義するだけでは不十分であることに気付きました。バインダー

これらはバイナリシリアル化の冒険です。フィードバックに感謝します。

ソースタイプのアセンブリを参照しない.Netバイナリシリアル化、またはBinaryFormatterとの交渉方法

はじめに 問題の声明

ステージ0。リファクタリング。 トラブルの前兆はない

ステージ1.デシリアライゼーション。 完全なタイプ名を覚えておいてください

ステージ2。メイン。 アセンブリ間のシリアル化

「非叙情的な余談」

More articles:

はじめに問題の声明

ステージ0。リファクタリング。トラブルの前兆はない

ステージ1.デシリアライゼーション。完全なタイプ名を覚えておいてください

ステージ2。メイン。アセンブリ間のシリアル化