問題タブ [signed-assembly]

今週、説明できない奇妙な問題に遭遇しました。サードパーティのアセンブリ (Xceed Grid およびその他のコンポーネントの一部) の署名済みバージョンを使用するようにアプリケーションを切り替えたところ、アプリケーションの開始時間がトイレに入ってしまいました。アプリケーションが署名付きアセンブリを読み込むたびに、読み込みに 30 秒かかりました。アプリケーションの起動が 5 秒から 90 秒以上になりました。ここで一体何が起こっているのですか？

その他の情報:

• これは、.NET 3.5 SP1 で実行される WinForms アプリです。
• コンピューターにはインターネット接続がありませんでした (意図的に、セキュリティのために)。

ひどいタイトルでごめんなさい。

Executable.exe などの別のアセンブリの依存関係である署名済みアセンブリ 'Signed.dll' があります。

Signed.dll は COM DLL を参照し、この COM DLL の型の 1 つ「ComPublicT」を公開します。

Executable.exe は、元の COM DLL への参照を追加するのではなく、Signed プロジェクトから自動的に生成された Interop.COM.dll を参照する必要があります。

エラーは、2 つの異なる COM 相互運用アセンブリの 2 つの異なる ComPublicT 型の間で型が一致しないことです。

これは、Signed.dll が署名されている場合にのみ必要です。

ComPublicT を模倣する型を作成する以外に、Executable が Signed の COM 相互運用アセンブリではなく COM DLL を参照できるようにするにはどうすればよいですか?

なぜこれが起こるのですか？

編集、これは多少異なる内訳です：

署名されたプロジェクトは COM.dll を参照し、COM.dll から型をパブリックに公開します。この参照を Visual Studio に追加すると、自動的に Interop.COM.dll が作成されます。

実行可能参照と署名済みプロジェクトに依存 通常、COM.dll への参照を追加でき、すべて問題ありません。

Signed は署名されているため、Signed から公開されている Interop.COM.dll の型は、コンパイラからは Executable の Interop.COM.dll から公開されている型と同じには見えません。

実行可能ファイルは、脆弱に感じられる Signed の Interop.COM.dll を手動で参照する必要があります。

さまざまな理由から、プロジェクトで強力な名前の付いた（署名された）アセンブリを使用したくありません。ただし、プロジェクトの1つは、SharePoint Webパーツによって参照されているため、署名する必要があります。

このアセンブリに署名することは可能ですが、他のプロジェクトから参照する場合は、強力でない参照を使用して署名してください。これにより、コードの残りの部分で署名されていないアセンブリを使用できるという利点が得られますが、SharePointでロードすることもできます。

私は、Visual Studio 2008 で次の 2 種類の Web プロジェクトを認識しています。

• ウェブサイト プロジェクト
• Web アプリケーション プロジェクト

Web アプリケーション プロジェクトは、Web アプリケーションのアセンブリも同じキーで署名されている限り、署名されたアセンブリを参照できます。ただし、アセンブリに署名する場所がないため、これは Web サイト プロジェクトでは機能しません。これは、アセンブリがサーバー上で動的にコンパイルされるためだと思いますか?

とにかく、この署名されたアセンブリで Web サイト プロジェクトを動作させることは可能ですか? または、この Web サイト プロジェクトを Web アプリケーション プロジェクトに変換する必要がありますか?

編集：

以下の状況により、この件について説明を求める必要がありました。

Visual Studio のソリューションで、他のいくつかのプロジェクトから参照されているクラス ライブラリがあります。プロジェクトの 1 つは、特定の外部ユーザーに展開される Windows アプリケーションです。アプリケーションが正しいアセンブリを使用していることを確認し、他のユーザーがアセンブリを使用できないようにするために (有効性に関する制限があることは承知しています)、すべてのアセンブリが署名され、ライブラリ内のすべてのクラスが宣言されています。フレンド (内部) として。

Web サイト プロジェクトにはアセンブリに署名する方法がないようで、ライブラリから何かを使用しようとすると、次のメッセージが表示されます。期待される。

次の属性は、クラス ライブラリ プロジェクトの AssemblyInfo.vb ファイル内にあります。

私の結論：

これを行う最もクリーンな方法は、Web サイトを Web アプリケーションに変換することのように見えますが、私たちのサイトはすでにかなり肉付けされており、他の議論で指摘されているように、これを行うには少し時間がかかります。行う。今後は、最初に Web アプリケーションを作成する方がより良いアイデアであり、将来の開発に対してはるかに柔軟だったと思います。

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

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

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

VS 2010 Win7 x64 で .Net 4.0 をターゲットとする WCF プロジェクトがあります。これは署名付きアセンブリであることに注意してください。Box.V2 SDK は NuGet を介してインストールされており、使用しているバージョンは 1.0.5 です。

ソリューションを構築しようとすると、悪いことが起こり始めました。最初の問題は、次のエラーのために先に進むことができなかった Box.V2 dll 自体にありました。

「アセンブリの生成に失敗しました -- 参照されたアセンブリ 'Box.V2' には厳密な名前がありません」.

「Brutal Developer .NET Assembly Strong-Name Signer (1.3.0.0)」を使用してアセンブリに署名することで、この問題を克服することができました。

正常にビルドされた後、BoxClient を作成すると次のメッセージで例外がスローされるという 2 番目の問題に遭遇しました。

「ファイルまたはアセンブリ 'Nito.AsyncEx, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' またはその依存関係の 1 つを読み込めませんでした。厳密な名前のアセンブリが必要です。(HRESULT からの例外: 0x80131044)」.

次のコードを使用して、クライアントをインスタンス化しました。

ここで、clientId、clinetSecret、redirectUri はメソッドのパラメーターです。

問題を解決するために実行した手順:

1. Nito.AsyncEx.dll は、前述の同じツールを使用して署名されました - 同じ例外です。
2. Nito.AsyncEx アセンブリは最新バージョン (2.1.3.0) にアップグレードされました。実際、彼らはそれを微調整し、アセンブリに厳密な名前を使用しましたが、まだうまくいきません。
3. ここに提出された問題の 1 つ ( https://github.com/box/box-windows-sdk-v2/issues/3 ) にも同様の問題があり、提案されたシナリオに従おうとしましたが、あまり役に立ちませんでした。
4. アセンブリにまったく署名しないようにしましたが、同じ例外がスローされたため、再び無駄になりました。
5. また、ここで説明されているように、Box.V2.dll を微調整して署名しようとしましたが、これらのエラーがスローされたため、後でビルドすることさえできませんでした。

タイプ「Box.V2.BoxClient」によって参照されるアセンブリ「System.Runtime、Version=2.6.3.0、Culture=neutral、PublicKeyToken=b03f5f7f11d50a3a」の基本クラスまたはインターフェイス「System.Object」を解決できませんでした

タイプ「Box.V2.Config.BoxConfig」によって参照されるアセンブリ「System.Runtime、Version=2.6.3.0、Culture=neutral、PublicKeyToken=b03f5f7f11d50a3a」の基本クラスまたはインターフェイス「System.Object」を解決できませんでした

そのため、現在、製品に Box API をデプロイするのに行き詰まっており、かなりイライラしています。

どんな助けでも大歓迎です。

署名済みアセンブリの内部にアクセスするために使用できる署名付きバージョンの LinqPad はありますか?