4

最近、Windows アプリケーション内で .Net ライブラリをマージできるツールをいくつか見つけました。

本当の問題は、ライブラリの動作がどのように変化するかです。

  1. 内部クラスはライブラリの内部のままですか? それとも、マージされたアプリケーションの内部になりますか?
  2. ライブラリが誤動作する可能性はありますか?

拡張質問:

  1. 内部のアセンブリをマージするときは、それらがマージされるアプリケーションで使用できないようにプライベートにする方がよいのではないでしょうか?
4

4 に答える 4

6

ネストされていない限り、クラスをプライベートにすることはできません。

ただし、次のことを考慮してください。アセンブリ A と B をマージする場合は、マージする前にそれらをコンパイルしておく必要があります。それらがコンパイルされたとき、それぞれの内部メソッドは互いにアクセスできませんでした。したがって、マージされたコードには、他のアセンブリの内部メソッドを呼び出すメソッドが存在しない可能性があります。

内部のアセンブリをマージするときに、それらがマージされるアプリケーションで使用できないように、プライベートにする方がよいのではないでしょうか?

それはどのように機能しますか？最上位の型が非公開の場合、他の型からはまったくアクセスできません。 そのため、プライベート タイプを定義することはできません (別のタイプにネストされている場合を除く)。

アセンブリ A にクラス C と D があり、C が内部であり、D がクラス C から何らかのメソッドを呼び出すとします。クラス C が非公開になると (これが可能な CTS の仮想バージョンで)、クラス D が壊れます。

于 2012-12-26T14:30:42.683 に答える
2

他の型にネストされていない最上位の型は、内部またはパブリックのアクセシビリティのみを持つことができます。これらの型の既定のアクセシビリティは internal です。

MSDNリンクから

1 内部クラスはライブラリの内部のままですか? または、マージされたアプリケーションの内部になりますか?

アプリケーションの内部に残ります。

2 ライブラリが誤動作する可能性はありますか?

技術的には可能です。クラス A が App の内部であり、lib の 1 つ (同じ名前空間を持つ) であるとします。合併前は問題ありません。マージ後、あいまいな参照を解決することが問題になります。

アプリケーション (SmartAssemply/ILMerger) がこれらをどのように処理するかは、別の問題です (私は認識していません)。エラー情報を提供することを選択する場合もあれば、提供しない場合もあります。彼らは改宗することを選択するかもしれませんし、しないかもしれません。

内部のアセンブリをマージするときに、それらがマージされるアプリケーションで使用できないようにプライベートにする方がよいでしょうか?

指定された最上位の型は非公開/保護することはできません。

于 2012-12-26T14:50:49.447 に答える
0

ライブラリが適切に設計されていない場合にのみ発生しますが、ILMerge はライブラリを破損する可能性があります。

破損は関係ありませんinternal。ただし、リフレクションを使用して、何かが読み込まれるアセンブリをテストしたり、特定のアセンブリ内の型を検索したりすると、結果が変わります。

コード アクセス セキュリティ属性に対するマージの影響については、internal. ただし、基本的には、異なるレベルの信頼で実行する必要があるアセンブリをマージしないでください。

于 2012-12-26T15:03:15.917 に答える
0

MSDN is quite clear on this:

Internal types or members are accessible only within files in the same assembly...

Since you merged them into a single assembly, the internal classes are accessible to all files within the merged assembly.

于 2012-12-26T14:31:48.083 に答える