問題タブ [internalsvisibleto]

既存のクラスライブラリをSilverlightに移植しています。ラムダ式のコンパイルを頻繁に使用しましたが、そのためにセキュリティの問題が発生しています。

特に、クライアントSLアプリの匿名クラスがラムダ式に参加している場合、それをコンパイルできません。MethodAccessException次のスタックトレースでを取得します。

クライアントSLアプリで匿名クラスをクラスライブラリに公開しようとしInternalsVisibleToましたが、役に立ちませんでした。実際には役立つはずですが、なぜ役に立たないのか理解できません。

何か案は？

更新：
問題はラムダ式ではなく、動的なジェネリックメソッドの呼び出しにあることがわかりました：

クラスライブラリに次のコードがある場合：

そして、次のようにアプリからStaticReceiveメソッドを呼び出します。

正常に動作しますが、を使用するDynamicReceiveと失敗します。CLRは、メソッドx内のパラメーターをジェネリックではなくタイプと見なしているようです。また、ライブラリからアクセスできないため、その呼び出しを禁止しています。ProcessInternalClassTInternalClass

バグのようですね。

MSBuild Community Tasks を使用して、Subversion リポジトリ タグに従ってアセンブリのバージョン番号を自動的に更新しています。プロジェクト ファイルに以下を追加しました。

これにより、新しい AssemblyInfo.cs ファイルが作成されます。残念ながら、MStest を正しく動作させるには、次のファイルを追加する必要があります。

[アセンブリ: System.Runtime.CompilerServices.InternalsVisibleTo("XLComponentsUnitTests")]

しかし、これを行う方法がわかりません。たとえば、MSBuild Community Tasks を使用する方法はないようです。誰でもこれに関するガイダンスを提供できますか?

InternalVisibleTo属性は、内部アクセス修飾子を持つタイプとメソッドを指定されたアセンブリに公開するために使用されることを理解しています。私はこれまで、一連の単体テストを含む別のアセンブリに内部メソッドを公開するためにこれを使用したことがあります。

これを使用する必要がある場合、別のシナリオを考えるのに苦労しています。この属性は、単体テストを支援するために特別に導入されたのですか、それとも別の理由がありましたか？

先に進む前に、この InternalsVisibleTo属性を確認しましたが、機能していません。

したがって、タイトル

さて、私は次のようなものを使用していた私のプロジェクトの作業バージョンを持っていました。

アクセスしたい内部のものを含むProperties/AssemblyInfo.csファイル。チェックインする前にそれは働いていました。しかし、Team Foundation IDK WTFでのマージは間違っていますが、AssemblyInfo.csのように属性は表示されませんが、ファイルに何も変更されていないことを確認しましたが、それでも"innaccessable due to its protection level."エラーが発生します。（Gama Radiation？Sunspot？バグをtweek動作するコードから動作しないコードにトレーニングする小さな邪悪なノーム笑）

リフレクションを使用して個々のインスタンスを追加してみました...

私がこれを試みるとき、私は得ます'Stuff.Internal.AssemblyWithIdentifer' is inaccessible due to protection level.

そうでなければ、私が内部のものに関係していることをコメントアウトすると、私のプロジェクトはうまくコンパイルされます。

RedGatesReflectorで「PublicKey」を再確認しました

また、privateObjectsを使用してその方法でメソッドにアクセスしようとしましたが、どのように試しても、内部で何もインスタンス化できません。

また、新しいプロジェクトを追加し、参照をコンパイルして実際に機能するようにしましたが、その後、新しいプロジェクトを作成し、「Stuff.Test.Support」プロジェクトにすべてのものを追加して、参照などを含めようとしました。アクセスしたいプロジェクト内のAssemblyInfo.csに追加しますが、コンパイルしようとすると同じエラーが発生します"innaccessable due to its protection level."

編集：assembly: InternalsVisibleToアセンブリをグローバルに管理し、この質問の冒頭で示した属性 の例と同様の方法でいくつかの属性が設定されているsharedAssembly.csを使用していることを忘れました。私の例では目立たないものである場合は、StrongNamedアセンブリも使用しています。

フレンド アセンブリに InternalsVisibleTo 属性を設定しました。コントローラーでは、内部クラスにアクセスできますが、aspx/ascx ファイルで同じことをしようとすると、「保護レベルが原因でクラスにアクセスできません」.

これを修正する方法はありますか？

編集

もっと明確にして、デザイナー クラス Internal を生成したリソース ファイルの属性であることを指定する必要がありました。resx ファイルを編集するときにアクセス修飾子を変更できることがわかりました。

しかし、説明してくれたダリン・ディミトロフに感謝します。

同じソリューション内の特定のアセンブリを指すInternalsVisibleToAttributeを設定したアセンブリがたくさんあります。残念ながら、指しているアセンブリにはストング名が付いているため、常に同じ公開キー トークンを AssemblyInfo.cs ファイルに何度も挿入する必要があります。C# にはプリコンパイラがないため、理想的にはこの冗長性を排除するにはどうすればよいでしょうか。

[assembly:InternalsVisibleTo("GuiAssembly")] を他のアセンブリに設定していますが、他のアセンブリに存在するクラスで wpf バインディングが発生すると、そのクラスのプロパティが内部であるため例外がスローされます。

これが他のアプリケーションで機能することはわかっていますが、この特定の WPF アプリで機能しない理由はわかりません。

状況は次のとおりです。

1. 完全なソースをクラスライブラリにリリースしたい
2. 公開したくないキーファイルを使用して、署名したバイナリもリリースしたい
3. バッチファイルとビルド前のステップを提供します。これにより、存在しない場合はローカルで新しいキーファイルが作成され、誰でもすぐにソースコードの使用を開始できるようになります。
4. テストプロジェクトでは、メインプロジェクトの内部クラスを参照する必要があります
5. 内部クラスにアクセスするには[assembly: InternalsVisibleTo("...")]、メインプロジェクトのAssemblyInfo.csファイルに属性を追加する必要があります
6. プロジェクト出力に署名しているので、その属性のPublicKey部分を指定する必要があります
7. これは、公開したくないキーファイルにバインドされます

では、どうすればこれを解決できますか？

テストライブラリではなくメインプロジェクトの出力に署名し、InternalsVisibleTo属性にアセンブリ名のみを指定すると、次のコンパイル時エラーが発生します。

エラー1フレンドアセンブリ参照'Mercurial.Net.Tests'が無効です。厳密な名前で署名されたアセンブリは、InternalsVisibleTo宣言で公開鍵を指定する必要があります。C：\ Dev \ VS.NET \ Mercurial.Net \ Mercurial.Net \ Properties \ AssemblyInfo.cs 22 31 Mercurial.Net

したがって、明らかに、テストプロジェクトの出力に署名しないだけでは十分ではありません。

プロジェクトに署名する設定を削除し、バイナリビルドスクリプトの一部としてプロジェクトファイルを変更する唯一のオプションはありますか？すなわち。<SignAssembly>false</SignAssembly>ビルドする前に、プロジェクトファイルの要素を探して変更しますか？

動的コード生成を使用してプロキシ クラスを作成するプロジェクトがあります。このプロキシ クラスはプロジェクトの内部クラスを使用するため (実装の詳細が公開されないようにするため)、動的に生成されたアセンブリの名前で InternalsVisibleTo を使用します。私のクライアントが出荷されたすべてのアセンブリに厳密な名前を付けるという要件を課した最近まで、これはうまく機能していました。

この問題が発生するのは、厳密な名前のアセンブリで InternalsVisibleTo を使用するには、それが参照するアセンブリも厳密な名前である必要があり、公開キーを提供する必要があるためです。私が立ち往生しているのは、動的に生成されたアセンブリに厳密な名前を付ける方法です。これが私がこれまでに行ったことです：

1. .snk を製品と共に出荷できるように、動的アセンブリ用の新しいキー ペアを作成しました (明らかに、プロジェクト アセンブリの残りの署名に使用される .snk を出荷したくありません)。
2. PublicKey を抽出し、動的に参照されるアセンブリに新しい動的 PublicKey を使用するように InternalsVisibleTo を更新しました。

3. 次のように、動的に生成されたアセンブリに署名しようとしました。

   /li>

残念ながら、これは機能しておらず、これがどのように機能するかについてのドキュメントを見つけるのに非常に苦労しています。InternalsVisibleTo 経由でアクセスできるように、動的に生成されたアセンブリに署名する方法を知っている人はいますか? 必要なクラスを公開することはできますが、カプセル化したままにしておくほうがよい実装の詳細が漏れてしまいます。

内部コンストラクターを持つクラスがあり、Unity（2.0）から解決したいと思います。

それから私はやっています

そうすると例外があります

IServiceが登録されており、唯一の問題はコンストラクターが内部にあることです。このクラスを公開したいのですが、ファクトリ（実際に呼び出しているcontainer.Resolve<MyClass>()）を介してのみ作成できるようにしたいと思います。

Unityにその内部コンストラクターを認識させる方法はありますか？InternalsVisibleToか何かのように？