問題タブ [assemblies]

プロジェクトの参照に使用する構造のタイプを知りたいと思いましたか?

私が働いている開発者には、AssemblyCache (\\MACHINENAME\AssemblyCache) という共有フォルダーがあり、Windows 2008 AD の GPO 経由で R:\ にマップされます (Developers AD グループに関連付けられています)。

共有コンポーネントには、次のようなものにコピーするビルド後のイベントがあります。

R:\.Net %VERSION%\Project\%SOMETHING%

プロジェクトに共通の場合は「共通」、または特定の場合は、後に「共通」が続くことがあります。.Net バージョン フォルダーの下には、共有アイテム用の共通ディレクトリもあります。

これは、複数のソリューションにまたがる大規模なプロジェクトで、共通の場所からアセンブリを参照できるためです。

ビルド マシンには、開発者が S: にマップした同じ共有名の共有ドライブもあります。これにより、必要に応じて最新の作業ビルドを取得できます。

これはすべて、誰かが新しい PC に乗り、さまざまな場所への参照をコピーすることなくプロジェクトを開くことができるようにするためであり、dev a が dev b と同じ場所からアセンブリを参照していることを確認するためです。

このソリューションは私たちにとってはうまく機能するので、すべての開発者が同じパスからアセンブリを参照できるようにするために、どのようなソリューションを用意しているのでしょうか?

According to this article rebasing is not necessary for .NET assemblies due to JIT compilation of the code. The article states:

"JIT-compiled code does not have a rebasing problem since the addresses are generated at run time based on where the code is placed in memory. Also, MSIL is rarely affected by base address misses since MSIL references are token-based, rather than address-based. Thus when the JIT compiler is used, the system is resilient to base address collisions."

However, I have noticed that VS2008 assigns the default 0x0400000 base address to all assemblies (project properties > build > advanced) and if I do a listdlls /r for my process all my .NET assemblies are in fact rebased per default.

If I assign addresses myself, no rebasing is done.

My question is: What is rebased in this case and why?

EDIT: I should add that I am not talking about NGen'ed assemblies.

次の構造を持つソリューションがあるとします。

• Project.DAL - データ アクセス レイヤーは、下位​​レベルのライブラリに依存します。たとえば、Oracle.DataAccess w/copy local = true
• Project.BLL - ビジネス ロジック層、Project.DAL をプロジェクトとして参照
• Project.UI - UI レイヤー、実行可能ファイルにコンパイル、Project.BLL を参照、既定のプロジェクト

Project.UI がコンパイルされると、VS は Project.DAL.dll を出力ディレクトリにコピーするほどスマートですが、クライアントに配布するために Oracle.DataAccess を出力ディレクトリにもコピーする必要があることを理解するほどスマートではありません。 .

なぜそうなのか、誰か説明できますか？それは、GAC で Oracle.DataAccess を認識し、クライアントが GAC にもそれを持っていると想定しているためですか?

それほど大したことではありませんが、新しいアセンブリ参照を追加するたびに、それをローカルにコピーするように設定し、それをビルド スクリプトにもコピーするための項目を追加する必要があるのはちょっと面倒です。

元のタイトル: .NET アプリからネイティブ dll が読み込まれないようにするにはどうすればよいですか?

バックグラウンド：

私の C# アプリケーションには、プラグイン フレームワークと汎用プラグイン ローダーが含まれています。

プラグイン ローダーは、プラグイン dll を識別するためにアプリケーション ディレクトリを列挙します (基本的に、この時点で *.dll を検索します)。

同じアプリケーション ディレクトリ内には、プラグイン dll の 1 つが間接的に依存するネイティブ (Windows、非 .net) dll があります。

プラグイン ローダーは、単純にファイル拡張子のみをチェックするため、native.dll が .NET アセンブリ dll であると盲目的に想定します。ネイティブ dll をロードしようとすると、例外がスローされます。

「ファイルまたはアセンブリ 'native.dll' またはその依存関係の 1 つを読み込めませんでした。モジュールにはアセンブリ マニフェストが含まれている必要がありました。」

基本的に、プラグインの読み込みに失敗した場合は診断レポートを作成するので、このログがネイティブ dll を読み込めないというメッセージでいっぱいになるのを避けようとしています (これは試したくありません)。

質問：

バイナリがたまたま .NET アセンブリであるかどうかを判断するために使用できる .NET API 呼び出しがあり、ネイティブ dll をまったくロードしようとしませんか?

おそらく長期的には、プラグインをサブディレクトリに移動する予定ですが、今のところは、プラグイン ローダー内に「native.dll」名をハードコーディングする必要のない回避策が必要です。

私は見落としていたある種の静的な Assembly.IsManaged() API 呼び出しを探していると思います....おそらくそのような API は存在しませんか?

MSDN の適切な記事、厳密な名前のアセンブリ、および関連するスタック オーバーフローの質問、Checking an assembly for a strong name を読んでいます。

1. 改ざんを避けるために、厳密な名前のアセンブリをどの程度まで検証できますか?
2. 厳密な名前付けを使用してアセンブリの作成者を確認することはできますか?

最初の質問は、CSharp411 の記事.NET Assembly FAQ – Part 3 – Strong Names and Signingを読んだ後に発生します。この記事では、厳密な名前を使用することの他の問題の中で、これについて言及しています。

「完全な置換を止めることはできません。厳密な名前は、ハッカーが厳密な名前の署名を削除し、アセンブリを悪意を持って変更し、独自のキーで再署名し、アセンブリを自分のものとして偽装することを防ぐことはできません。」

2 番目の質問は、厳密な名前付けと、たとえばAuthenticodeなどの他の署名スキームとの違いを見つけることを目的としています。同じ MSDN の記事で、初期状態について言及されています。

"ただし、厳密な名前自体は、たとえばデジタル署名やサポート証明書によって提供されるような信頼レベルを意味するものではないことに注意してください。 "

作成された目的よりもはるかに多くの目的で厳密な命名を使用しようとしていますか? 厳密な名前付けは、名前の衝突や新しい種類の「GAC DLL 地獄」を回避するためだけに作成されたものですか?

.NET 3.5 を対象とするアセンブリがあります。

.NET 2.0 を対象とするアプリケーションがあり、2.0 アプリケーションから 3.5 アセンブリを参照する際に問題が発生するかどうか疑問に思っています。

ILはおそらく同じであることを理解していますので、うまくいくと思いますが、これを試した他の人からの経験を聞きたいです.

ランタイム環境には、2.0 と 3.5 の両方がインストールされます。

私は、メイン アプリが新しい AppDomain の実行時にアセンブリ Addin1.dll と Addin2.dll をロードするアドイン システムを実行しています。

ただし、Addin1.dll が私のキーで署名され (厳密な名前)、Addin2.dll が署名されていない場合、Addin1.dll のみをロードして Addin2.dll を拒否できるようにしたいと考えています。

AppDomainSetup でいくつかのパラメーターを設定して行う必要があると思われますか?

.net Windows クライアント アプリケーションをデプロイするには、いくつかの方法があることを知っています。

Windows Installer、Click Once、簡単なダウンロードと実行、および Internet Explorer での Windows フォーム / WCF アプリケーションのロードがあります (後者を WCF/E - Silverlight RIA アプリケーションと混同しないでください) 。

それで...本当のWindowsクライアントアプリケーションについて考えてみてください-本当に明確にするために:ファイルシステム内の.exeで構成されるもの--インターネットからその依存関係の一部またはすべてをロードすることは良い考えですか?

明らかにいくつかの重大な欠点があります:ロード時間は言うまでもなく、常に接続されている必要があり、クライアントのCAS構成 (インターネットの依存関係はInternet_Zone コード グループにあります)。

しかし、いくつかの利点も考えられます。

問題は何ですか？誰かが実際のプロジェクトでこれを使用しましたか?

誰か説明してくれませんか？私はインターネット上で何も見つけることができませんでした.すべてが何らかの方法でそれを行う方法について語っていますが、それが何であるかを正確に述べているものは何もありません.

また、完全に信頼されたアセンブリとは何ですか? また、それらは互いにどのように異なるのでしょうか?

私は MS 認定試験を受けていますが、これは私が理解できない唯一のトピックです。

編集：ありがとう。これで、.NET のセキュリティについて理解が深まりました。認定試験に合格することができました。

次の解決策を想像してみてください。

• WebサイトABC.com（Webアプリケーションではない）
• BLL（個別のアセンブリのビジネスロジック層）
• DTO（独自のアセンブリ内のdtoオブジェクト）

• DAL（独自のアセンブリ内のデータアクセス層も同様）。

  1. BLLにはDALへの参照があります。
  2. BLLにはDTOレイヤーへの参照があります。
  3. WebサイトプロジェクトはBLLを参照します。

Webサイトプロジェクトをコンパイルすると、次のDLLがBINディレクトリに表示され ます
。BLL.dllDTO.dll
DAL.dll

サイトをプレビューしようとすると、必要なアセンブリ参照がないというエラーが発生します...ここで、Webサイトプロジェクトの[参照の追加]を右クリックし、不足しているアセンブリへの参照を明示的に追加すると、正常に機能します。

ASP.NETは、Webサイトで追加/参照されている参照アセンブリの参照アセンブリをプルしているように見えます。

参照の参照に明示的な参照を追加する必要があるのはなぜですか...？私がこれを正しく表現していないか、混乱している場合は申し訳ありません。