問題タブ [internalsvisibleto]

当店では、Cruise ControlとMSBuildを使用して、継続的インテグレーションの一環として製品のビルドを自動化しています。

ビルドの一部は、アセンブリに署名して、強い名前を付けることです。

ローカルで開発する場合のプロジェクトファイルでは、署名が指定されていません。これは、MSBuildスクリプトによってオーバーライドされるためです。

InternalsVisibleTo属性を使用する必要がある単体テストを導入することを決定するまで、これはすべて問題ありません。また、この手法を使用する単体テストを備えた優れたオープンソースライブラリの使用も開始しました。

これは、私のマシンではAssemblyInfo.cs、次のステートメントを使用するように更新できることを意味します。

そして、すべてが順調です。

ただし、ビルドマシンがアセンブリに署名するため、これをチェックインするとビルドが中断されます。代わりに、その行を次のように更新する必要があります。

私は、議会に署名せず、それを1日と呼ぶことに半信半疑です。ただし、「アセンブリに署名することはベストプラクティスです」（このマントラを3回繰り返す）。これを行うことで利益が得られる場合は、リモートにしたくありません。

GACにはインストールしません。改ざんについては特に心配していません。ライブラリを使用するサードパーティについて心配する必要はありません。アプリを更新するときに、すべてのファイルを一度に更新します。最も識別可能な利点は、サポートの誰かがアセンブリのランダムなバージョンをランタイムフォルダにコピーできず、しばらくの間動作しているように見えることです。

署名を有効にするために約100個のプロジェクトファイルを手動で変更して、関連する作業の缶を開けたくありません。また、内部にあるべきものをパブリックとしてマークすることによって物事をハックしたくない、バインディングリダイレクトに入りたくない、そして単体テストを削除したくない。

強い名前を持たないことの簡単さと、強い名前を持つことのすべての利点（ある場合）が欲しいのですが、それを行うために多くの余分な作業を作成したくありません。質問するのは多すぎますか？

この投稿では、問題と解決策について詳しく説明していますが、私はそれを利用するMSBuildスクリプトの専門家ではありません。

http://social.msdn.microsoft.com/forums/en-US/msbuild/thread/02df643c-956a-48bd-ac01-4a1016d91032/

この問題の適切な解決策は何ですか？

任意の入力と議論のポイントは大歓迎です。

単体テスト用のモッキング フレームワークとして Rhino Mocks を使用しています。

テストしたいクラスである Subject というクラスがあります。IStore に依存しています。

IStore は次のように定義されます。

Subject クラスは次のように定義されます。

RhinoMocks を使用した私のテスト クラスは次のとおりです。

私の設定では、インターフェイスは internal として定義されており、Subject クラスと StoreTests クラスの両方に InternalsVisible が設定されています。ただし、テスト ケースが実行されると、var mockStore = MockRepository.GenerateMock(); で例外がスローされます。IStore は公開されていないため、モックを生成できませんでした。

これは、IStore が公開されていないためだと思います。しかし、IStore dll に InternalsVisibleTo を設定したので、StoreTests がそのクラスのモックを作成するには十分ではないでしょうか?

この問題は、IStore インターフェイスを公開することで解決できるのではないかと考えています。ただし、これは私にとっては選択肢ではないため、 IStore のモックを作成できる他の方法はありますか?

厳密な名前のアセンブリでInternalsVisibleTo属性を使用することにセキュリティ上の懸念はありますか？この方法で情報を受信するアセンブリには、メッセージを復号化するための秘密鍵が必要であり、InternalsVisibleTo属性内で公開鍵をクリアテキストで指定する必要があることを理解しています。誰かがInternalsVisibleTo属性のアセンブリdllと公開鍵を変更して、本来は共有することを意図していないアセンブリと内部関数を共有することは可能でしょうか？

以下を使用して、いくつかの内部を単体テスト プロジェクトに公開しようとしています。

しかし、私はエラーが発生しています:

エラー 1 フレンド アセンブリ参照 MyTest' が無効です。厳密な名前で署名されたアセンブリは、InternalsVisibleTo 宣言で公開キーを指定する必要があります。.../MyClass.cs...

PublicTokenKey を手動で割り当てる場合:

ソリューションはエラーなしでビルドされます。

1. 公開鍵トークンを含める必要があるのはなぜですか?
2. 公開鍵トークンを含めることで本番環境で何かが壊れるかどうかはわかりません。

では、テスト プロジェクトに公開鍵を割り当てる最も安全な方法は何ですか?

パブリックとして公開したくない機能を備えたアセンブリがありますが、他のアセンブリからは引き続きアクセスできます。これは、InternalsVisibleToAttribute を使用して、内部を可視にする各アセンブリを指定することで実行できます。

すべての参照アセンブリを指定する必要がなく、代わりにアセンブリが同じ snk によって署名されなければならないという規則を適用して、内部を表示できるようにする方法があるかどうか疑問に思っていました。

この機能は存在しますか? もしそうなら、誰かが私を正しい方向に向けることができますか?

moq-silverlight 4.0.10827.0 を使用して、Silverlight 4 の内部インターフェイスをモックしようとしています。

「アクセスできないタイプのプロキシを作成できません」というエラーが表示されます。Castle.DynamicProxy.Generators.GeneratorException で。

テストしたアセンブリの assemblyInfo に [assembly: InternalsVisibleTo("DynamicProxyGenAssembly2")] があります。署名済みのアセンブリはありません。

これに関する明確なステートメントはMSDNで見つかりませんでした。他にない強い名前の例がいくつかあります。私にとっては、なくても機能するはずですが、機能しないようです。

ありがとうございました

「C# in Depth 2nd Edition」、Jon Skeet の本 (パート 2 の最後まで読んだばかり) では、7.7.3 で言及されてInternalsVisibleToおり、署名付きアセンブリでも使用できます。現時点では、署名はまったく使用していません。リリースされたバイナリのセキュリティの問題は実際には非常に重要であるため、プリプロセッサ変数テストを使用してリリース アセンブリの属性を完全に削除する予定です。

興味深いことに、署名されたアセンブリと を使用するのはどのように実用的でしょうInternalsVisibleToか? InternalsVisibleTo署名済みのフレンド アセンブリを指定するために使用するには、その公開キーを指定する必要があります。テスト中のアセンブリに依存するフレンド アセンブリをコンパイルした後にのみ、それを取得します (アセンブリの動的な読み込みとリフレクションは別として、コーディングと読みやすさを肥大化させるもの)。これは、アセンブリのブートストラップをテストする必要がある鶏卵問題のように聞こえます。これを自動化するために、MSBuild とスクリプトを使用したいくつかのトリックを想像できます。これを行うより実用的な方法はありますか？

面倒な作業が続く場合は、リリース ビルドのユニット テストを中止するという最初のアイデアに固執します (微妙なタイミングの問題がテストされないままになる可能性があるため、これはやや不満です...)。

重複の可能性:
[アセンブリ: InternalsVisibleTo()] はいつ使用する必要がありますか?
dll メソッドへのアクセス

A.dll と B.dll の 2 つのアセンブリがあります。A.dll にはいくつかの共通機能があり、B.dll はそれを使用します。最終的には、A.dll と B.dll を他のユーザーに配布する必要があります。

ただし、A.dll には (B.dll で使用するために) public としてマークしたメソッドがいくつかありますが、他のユーザーに使用してほしくありません。

これを達成する良い方法はありますか？InternalsVisibleToAttributeこれを達成するための良い習慣の使用はありますか?