問題タブ [internalsvisibleto]

InternalsVisibleToを使用して、別の Test アセンブリからユーティリティ/ヘルパー メソッドをテストできるようにしようとしています。動的パラメーターを使用して内部メソッドを呼び出そうとすると、 「 RuntimeBinderException was unhandled ... is inaccessible due to its protection level.」というエラーが表示されます。

動的パラメーターを使用しない他の内部メソッドをテストできるので、InternalsVisibleTo属性を正しく使用していると思います。次のコードは、以下に示すようにTestInternalMethodWithDynamicテストのみが失敗するシナリオを示しています。静的メソッドの代わりにインスタンス メソッドを使用してテストを繰り返しましたが、違いはありませんでした。

.NET テクノロジは Silverlight 5 であり、Silverlight 単体テスト フレームワークを使用してテストを実行しています。プロジェクトの Excel 自動化要件により、動的パラメーターを使用する必要があります。

編集: .NET 4 クラス ライブラリ アセンブリを使用して同じ呼び出しをテストしましたが、成功したため、問題はSilverlightに固有のようです。

ユーティリティ クラスの例...

そしてテストクラス...

属性を使用InternalsVisibleToして、一部の内部クラスを単体テスト スイートから見えるようにしています。

内部クラスのインスタンスを作成することはできますが、内部クラスから継承するクラスを作成することはできません。

この動作は予期されたものですか? もしそうなら、私が望むものを達成するための他の方法はありますか?

編集: @Grant Thomas が指摘したように、私は自分の言いたいことを言いませんでした。私が欲しいのは、抽象内部クラスのインスタンスを作成することです。私がテストしているクラスではありませんが、私がテストしているクラスには依存関係があります。

次の行を挿入します。

[assembly: InternalsVisibleTo("MyTests")]

test( Properties/AssemblyInfo.cs)の下のプロジェクト内で、MyTestsは単体テスト プロジェクトの名前です。しかし、何らかの理由で、単体テスト プロジェクトから内部メソッドにアクセスできません。

私が間違っていることについてのアイデアはありますか?

InternalsVisibleTo内部クラスを単体テスト アセンブリに表示するために使用することで、内部クラスを含む多くのアセンブリがあります。

これは問題なく動作しますが、問題は、 を使用するとすぐにInternalsVisibleTo、コード分析 CA1812 警告 (インスタンス化されていない内部クラスを回避する) が妨げられることです。

また、CA1811: "呼び出されていないプライベート コードを回避する" も防止します。

いくつかの調査を行ったところ、このために警告されていなかった未使用の内部クラスがかなり多く見つかりました。

当面の私の解決策は、各アセンブリの「AssemblyInfo.cs」ファイルを手動で編集して一時的にコメントアウトし、InternalsVisibleToそのプロジェクトだけをコンパイルして未使用の内部クラスを発見できるようにすることです。

これは非常に手間がかかります。もちろん、そのようなことが自動的に行われなければ、まったく行われないこともよくあります。

InternalsVisibleTo解決策は、属性を無視するようにコード分析に指示できるようにすることです。

そのような可能性が存在するかどうかは誰にもわかりませんか？

私は Visual Studio 2012 でプログラムを書いており、2 つの別々のプロジェクトに 1 組のクラスがあります。

プロジェクトA:

プロジェクトB:

AssemblyInfo.csProjectB には、次のものもあります。

これは、CodeContract 静的分析をオンにするまで問題なくコンパイルされます。この時点で、 ccrewrite: からエラーが発生しますMember 'Test.B.X' has less visibility than the enclosing method Test.A.#ctor(Test.B)。

問題を引き起こしている可能性があると私が考えることができる唯一のことは、 CodeContracts が ProjectA が ProjectB の内部を参照できることを認識していないためB、このコンテキストではクラスの可視性が本質的にないと考えていることです。アサーションを に変更すればb != null問題ないようですが、この議論は筋が通らないかもしれません。

誰でもこのアサーションを確認したり、正しい説明をしたりできRequiresますBか?

MainとSubという 2 つのアセンブリがあり、SubはMainに依存しています。Mainは、 Subでオーバーライドしたいメンバーを持ついくつかのクラスを定義します。これらのメンバーを としてオーバーライドします。protected internal virtualprotected override

Mainには無関係なクラスがあり、それをMain.Sharedと呼びます。これをSubで使用したいのですが、他のアセンブリにそれを見せたくありません。状況は次のとおりです。

InternalsVisibleToそのため、通常どおり属性を使用しました。ただし、 Mainをこの属性で装飾した後、コードはコンパイルを拒否します。エラー メッセージには、おそらくMainとSubが同じアセンブリであると考えられるため、 DoStuffasをオーバーライドする必要があることが示されています (?)protected internal override

すべてのオーバーライドを手動で保護された内部に変更する必要があり、それらの多くがあるため、これは大きな問題です。さらに、後で属性を削除したい場合があり、すべてを元に戻す必要があります。

これを避ける方法はありますか？(コードベースの完全な再設計に加えて...)

また、なぜこれが起こるのかについても興味があります。この動作は単なる盲点ですか、それともこのように機能するはずですか?