コンパイル済みの DLL (C# .NET で記述) をターゲット マシンに登録する必要がありますか。
ターゲット マシンには .NET がインストールされますが、単に DLL をターゲット マシンにドロップするだけで十分ですか?
コンパイル済みの DLL (C# .NET で記述) をターゲット マシンに登録する必要がありますか。
ターゲット マシンには .NET がインストールされますが、単に DLL をターゲット マシンにドロップするだけで十分ですか?
あなたは物事を少し混乱させていると思います。dll を使用するために dll を登録する必要はありません。
dll を使用するには、それをロードし (既知の場所が指定されている場合、またはライブラリがシステム パスにある場合)、使用する関数のアドレスを取得するだけで済みます。
dll の登録は、Windows レジストリに特定のエントリを追加する必要がある COM または ActiveX オブジェクトを配布するときに使用されました。(たとえば) COM サービスを使用するには、サービスを実装する (またはサービスへのアクセスを提供する) dll へのハンドルを取得できる GUID (一意の識別子) を参照する必要があります。完全修飾名を参照しても、同じ結果が得られる場合があります。
これらすべてを機能させるには、dll を登録する必要がありました。この「登録」プロセスは、レジストリにいくつかのエントリを作成するだけですが、主に次の 2 つです。フルネームを GUID に関連付けます。ただし、これは COM または ActiveX オブジェクトのみを対象としています。
.NET でアプリケーションを開発する場合、プロジェクトで参照されるライブラリは、必要なときに自動的に読み込まれます。ライブラリの検索や読み込みについて心配する必要はありません。そのために、フレームワークは参照されるライブラリの 2 つの場所をチェックします。
GAC (グローバル アセンブリ キャッシュ) を使用すると、システム全体で使用される dll を効果的に登録でき、古い登録メカニズムの進化形として機能します。
したがって、基本的には、アプリケーションの同じフォルダーに dll を配置するだけで済みます。
それを必要とするアプリケーションがそれを見つけるディレクトリに「ドロップ」する必要があります。
複数のアプリケーションがある場合、またはアプリケーション ディレクトリ以外の場所にファイルを "ドロップ" する場合は、通常、PATH 変数を調整するか、グローバル アセンブリ キャッシュ (GAC) にアセンブリを登録する必要があります。
com+を介してアセンブリにアクセスする場合。例としては、VB6winformsアプリなどの非.NETアプリケーションからの.NETアセンブリで定義された型を使用する場合があります。
別の.NETアプリケーションからアセンブリにアクセスする場合は、何もする必要はありません。アセンブリに強い名前が付いている場合は、GACにドロップすることをお勧めします。それ以外の場合は、それを参照するアプリケーションのディレクトリにドロップするだけです。
通常は、ターゲット マシン上のアプリのフォルダーに dll をドロップするだけで十分です。
dll を他のアプリケーションで使用できるようにする必要がある場合は、GACを検討することをお勧めします。
Windows プラットフォーム用の .NET が登場したときの大きなセールス ポイントの 1 つは、既定では、.NET アセンブリ DLL を登録する必要がなく、同じディレクトリに配置するだけで、アプリケーションによって非公開で使用できることです。フォルダを EXE ファイルとして保存します。開発者が DLL/COM 地獄の争いを回避できるようになったため、これは大きな前進でした。
共有 DLL/COM モジュールは、ユーザーがインストールしたアプリケーションの不安定性につながるため、Windows の最大の設計ミスの 1 つであることが判明しました。新しいアプリをインストールすると、正常に動作していたアプリが台無しになる可能性があります。これは、新しいアプリが新しいバージョンの共有 DLL/COM モジュールを導入したためです。(実際には、開発者が細かいバージョンの依存関係を適切に管理するのは負担が大きすぎることが証明されています。)
Maven のようなビルド リポジトリ システムを使用してモジュールのバージョンを管理することは、1 つのことです。Mavenは、それが行うことを非常にうまく機能させます。
ただし、何百万人ものユーザーにまたがるエンドユーザーのランタイム環境でその問題に対処することは、まったく別の問題です。
.NET GAC は、この古くからある Windows の問題に対する十分なソリューションではありません。
個人的に消費される DLL アセンブリは、引き続き無限に好まれます。最近はディスクスペースが非常に安いので、簡単な方法です (最近の Fry's では、テラバイトのドライブで 100 ドルまで可能です)。アセンブリを他の製品と共有することで得られるものは何もありませんが、貧弱なユーザーにとって物事がうまくいかない場合、会社の評判は失われます。
実際には、ターゲット マシンの .NET に dll を登録する必要はありません。
アプリケーションで .dll を参照する場合は、プロジェクトの参照の下で参照されている .dll をクリックし、プロパティを見て、Isolated を TRUE に設定します。
これにより、この .dll が自動的にプロジェクトに組み込まれ、アプリケーションはプロジェクトに含まれる .dll のコピーを使用し、ターゲット システムに登録する必要がなくなります。
この外観の実際の例を見るには、次のようにします。
http://code.msdn.microsoft.com/SEHE
問題の .dll は、これが正しく機能するために、アプリケーションをビルドするシステムに登録する必要があります。ただし、プロジェクトをビルドしたら、アプリケーションまたはプログラムを展開するシステムに問題の .dll を登録する必要はありません。
この方法を使用するもう 1 つの利点は、将来、別の .dll が問題のターゲット システムに同じ名前で登録された場合でも、プロジェクトはデプロイした .dll を引き続き使用できることです。これは、.dll に多くのバージョンがあり、テストしたものを使用するなど、ある程度の安定性を維持したい場合に非常に便利ですが、他のすべてのアプリケーションは、isolated = true メソッドも使用しない限り、登録された .dll を使用します。
上記の例はそのようなケースの 1 つです。Skype API .dll である Skype4COM には多くのバージョンがあり、頻繁に変更される可能性があります。
この方法により、上記の例では、プロジェクトがテストされた API .dll を使用できます。ユーザーが新しいバージョンの Skype をインストールするたびに、この .dll の変更されたバージョンがインストールされる可能性があります。
また、この .dll をインストールしない Skype クライアントもあります。たとえば、ビジネス バージョンの Skype クライアントはサイズが小さく、この .dll が含まれていないため、この場合、プロジェクトはその .dll で失敗しません。 isolated = true としてプロジェクトに含まれているため、欠落しており、登録されていません。
アプリケーションは、.NET dll をアプリケーションと同じフォルダーに置くだけで使用できます。
ただし、他のサードパーティ製アプリケーションで DLL を見つけて使用する場合は、配布物に含める必要があります。これは望ましくない場合があります。
別の方法は、DLL を GAC (グローバル アセンブリ キャッシュ) に登録することです。