6

ILMerge を使用して、いくつかのサード パーティ アセンブリを含むいくつかの .NET アセンブリをマージしています。そうして以来、いくつかのエラーが発生しましたが、それらはすべて、型定義がそれらが定義されているアセンブリに関連付けられているという事実に帰着します。

簡単な例は、私の App.config の log4net config セクション定義です。マージされたアセンブリにマージされると log4net アセンブリが存在しないため、 type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" を使用します。大したことではありませんが、アセンブリ名をマージされたアセンブリに変更すると、正常に動作します。

もう少し複雑な例は、バイナリのシリアル化された型です。私のシステムでは、バイナリ シリアル化を使用してプロセス間で特定のオブジェクトを送信しています。シリアル化可能なオブジェクトはすべて、他のすべてのプロジェクトが参照する共通のアセンブリで定義されます。デフォルトのバイナリ シリアル化を使用していましたが、オブジェクトをシリアル化したマージされたアセンブリが見つからないというエラーでオブジェクトを逆シリアル化するときに失敗し始めました。繰り返しますが、大したことではありませんが、指定されたアセンブリだけでなく、読み込まれたアセンブリの型を検索するカスタム SerializationBinder を実装しました。

シリアル化された型が他のシリアル化可能な型を参照する場合、前の例はより複雑になります。私はますます対処が難しくなっている問題に遭遇し続けてきました。

ここで私が理解しようとしている点は、.NET 型システムと ILMerge がうまく連携していないように見えるということです。この問題をどのように解決したかについて、経験のある人はいますか? .NET ランタイムに、型がどのアセンブリにあるべきかを気にせず、どこかを探すだけでよいと伝えることはできますか?

注: アセンブリをマージする理由を尋ねる返信はしないでください。それはこの質問のポイントではありません。

4

3 に答える 3

4

はい、この問題には解決策があります: アセンブリの代わりにモジュールをビルドしてください!

.net のコンパイラには、アセンブリの代わりにモジュールをビルドするオプション (C# および VB の場合は /target:module) があります。その後、複数のモジュールをコンパイラに渡して、最終的なアセンブリをビルドするために使用できます。

もちろん、これはすべて、これらのサード パーティ アセンブリのソースがあることを前提としています。それを入手できない場合は、サード パーティ製アセンブリの .netmodule バージョンをサード パーティから入手できますか?

それがうまくいかない場合でも、最後のオプションが 1 つあります。明らかに、サードパーティのアセンブリを既に IL に分解しています。その IL ファイルからアセンブリ情報を取り除き、「ilasm /dll」を使用して .netmodule を構築します。これで、他の .netmodule と同じように使用できるようになります!

アセンブリの代わりにモジュールを使用することで、アセンブリ ベースの問題が発生しなくなります。

確かに、ILMerge を使用しないことで ILMerge に関する問題を解決しましたが、それが本当に最善の解決策ではないでしょうか?

うまくいくといいのですが、便利なリンケージがあります: .netmodule を使用した ILASM
のアセンブリの代わりに

(そしてここで、.netmodules に関する私の経験は誰の役にも立たないだろうと考えていました!)

于 2010-03-12T20:12:09.697 に答える
-2

コード内の文字列と（物理的な場所の）文字列の危険へようこそ。

この種のすべてのツールには同様の問題があり、バインディングやシリアル化などのランタイム機能の多くの開発者や設計者は実際には想定していなかったため、よりスマートである必要がありますが、ILMergeを「スマート」ツールとして確実に推進しました。それはとても賢いので、タイプを整理することさえできません。

ここではバージョニングも関係していることに注意してください。構成、。*とスター・イン・ザ・アイ、およびレドモンドからのバージョンの独立性も役に立ちません。

あなたは確かにサードパーティのビットでトラブルを起こし続けるでしょう。そして、私を信じてください。いくつかの哀れな少数のタイプは、MS JITが大きなアプリを開始するのに時間がかかる可能性があるため、マージが必要です（いいえ、以前よりもさらに遅いNGENまたは最適化された3.5SP1の読み込みは必要ありません） System.Coreまたは天国のために-WPFの肥大化を禁止します）。

最良の選択肢は、少なくとも大規模では、これをスキャンして処理するまともな商用ツールを入手することです（つまり、既存の苦痛と難読化の経験から）。長期的には、ソースがない場合、既存のILコードをインストルメント化することになる可能性があります。

[次に、地球温暖化の問題を解決するINotifyPropertyChanged文字列の発明がありました-Casio-CalcInventorsによって設計されました]

于 2009-11-05T18:27:35.180 に答える