問題タブ [assemblies]

他のアセンブリのものを使用するクラス ライブラリを作成する場合、それらの他のアセンブリをある種のリソースとしてクラス ライブラリ内に埋め込むことは可能ですか?

つまり、 MyAssembly.dll 、SomeAssembly1.dll、SomeAssembly2.dllをファイル システムに配置する代わりに、他の 2 つのファイルがMyAssembly.dllにバンドルされ、そのコードで使用できるようになります。

また、.NET アセンブリが.dllファイルである理由についても少し混乱しています。この形式は .NET より前に存在しませんでしたか? すべての .NET アセンブリは DLL ですが、すべての DLL が .NET アセンブリであるとは限りませんか? 同じファイル形式やファイル拡張子を使用するのはなぜですか?

A がアセンブリ B 1.1 と C を参照し、C が B 1.2 を参照している場合、アセンブリの競合をどのように回避しますか?

私は、C の参照がカプセル化され、問題が発生しないと思っていましたが、すべての dll が問題が発生するビンにコピーされているようです。

これを回避する2つの方法は、GACまたはアセンブリバインディングを使用することだと理解していますか? GAC は私にとって最善のアプローチとは思えません。dll がそこにあると仮定するのは好きではないため、ソリューションの lib ディレクトリから dll を参照することを好みます。

アセンブリ バインディングは堅牢ではないように思えますが、アセンブリの 1 つのバージョンが他のバージョンにはない機能を持っている場合、問題は発生しませんか?

私の場合、サードパーティのdllを使用しているため、自分で使用しているよりも古いバージョンのnHibernateを使用しています。

クライアントのシステム内の環境と地域にまたがってデプロイされた .NET アプリケーションに関する情報を報告するツールを作成しています。

これらのアセンブリのアセンブリ属性の値を読みたいと思います。

これは を使用して実現できますがAssembly.ReflectionOnlyLoad、この方法でもアセンブリがロードされたままになります。ここでの問題は、異なるパスから同じ名前を持つ 2 つのアセンブリを読み込むことができないため、異なるシステムにデプロイされた同じアプリケーションを当然比較することができないことです。

この時点で、ソリューションには一時的なAppDomains の使用が含まれると想定しています。

アセンブリを別のAppDomainにロードし、そこから属性を読み取ってからアンロードする方法を誰かが詳しく説明できますかAppDomain?

これは、URL アドレスにあるアセンブリだけでなく、ファイル システム上のアセンブリにも機能する必要があります。

いくつかのメソッドを COM で表示する .NET DLL を作成しました。

1つの方法が問題です。次のようになります。

メソッドを呼び出そうとすると、VB6 でコンパイル エラーが発生します。

関数またはインターフェイスが制限付きとしてマークされているか、関数が Visual Basic でサポートされていないオートメーションの型を使用しています。

配列パラメーターは参照渡しする必要があると読んだので、署名の最初のパラメーターを変更しました。

VB6 でも同じコンパイル エラーが発生します。

署名を変更して VB6 と互換性を持たせるにはどうすればよいですか?

アセンブリ dll にあるUserControl の子孫を作成しました。

コントロールをフォームにドロップするにはどうすればよいですか?

ソリューション エクスプローラーの [参照]ノードの下にアセンブリへの参照を追加しましたが、ツールボックスに新しいコントロールが表示されません。

ツールボックスにコントロールを表示してフォームにドロップできるようにするにはどうすればよいですか?

更新 1 :

Visual Studioオプションでアセンブリをビルドしようとしました:

ツール-->オプション... --> Windows フォーム デザイナー--> AutoToolboxPopulate = true

新しいソリューションのツールボックスにコントロールが表示されませんでした。

注：どういうわけか誤って「...それはアセンブリdllにありません...」と書きました。特にアセンブリdllにある場合、どうやってそれを書くことができたのかわかりません。コントロールは、同じプロジェクトにあるときに魔法のように表示されますが、別のプロジェクト/ソリューションになった今では表示されません。

更新 2: 回答

1. ツールボックスを右クリック
2. [項目を選択...] を選択します。
3. .NET Framework コンポーネントタブ
4. [参照... ] を選択します。

5. コントロールを含むアセンブリ dllファイルを参照し、 [開く] を選択します。

   注: アセンブリ内のコントロールは、.NET Framework コンポーネントのリストにサイレントに追加されます。

6. ツールボックスに表示する各コントロールにチェックを入れます
7. [ OK] を選択

.NET アセンブリが完全に信頼された呼び出し元以外のものを許可するには、アセンブリに署名し、AllowPartiallyTrustedCallersで属性を付ける必要があります。

しかし、これを行っても、(幸いにも) CLR はコードの権限をチェックして、部分的に信頼された呼び出し元が目的のコードを実行できることを確認します。

私の質問は、すべてのアセンブリで AllowPartiallyTrustedCallers 属性が想定されていないのはなぜですか? 逆に、部分的に信頼された呼び出し元を本当に望んでいない人は、DenyPartiallyTrustedCallers などの属性を使用する必要があるのではないでしょうか?

しばらく前に、ここで Stack Overflow、 Assembly Names and Versionsについて次の質問をしました。

サードパーティの依存関係の1つが厳密な名前のアセンブリではないため、厳密な名前でアセンブリに署名できないため、署名できないことに気づきました。

アセンブリ ファイル名 MyAssembly.dll を MyAssembly.v.1.1.dll に単純に変更しようとしましたが、これを実行して名前を変更したアセンブリを参照すると、残りの参照のようにコピーされません。ファイル名とアセンブリの Identity 属性が一致していないことが原因のようです。

プロジェクト C の依存関係であるプロジェクト A と B があります。プロジェクト A は MyAssembly.dll v.1.0 を参照する必要があり、プロジェクト B は MyAssembly.dll v.2.0 を参照する必要があるため、両方をプロジェクト C の bin/ に配置できる必要があります。フォルダを解放します。

何をする必要がありますか？どうすればこれを修正できますか?

型への参照があり、それが配置されているアセンブリのバージョン番号を取得したいと考えています。

これを行う最善の方法は何ですか？

パブリック メソッドとその戻り値のベスト プラクティスは何だろうと思っています。参照されたアセンブリから型を返すことは問題ありませんか、それともすべてのパラメーターと戻り値がすべて同じアセンブリ内からのものであることを確認する必要がありますか?

私が尋ねる理由は、アセンブリをILMergeとマージしている最中であり、メインアセンブリを除くすべてのアセンブリを内部化したいのですが、メインアセンブリにパラメーターを持つパブリックメソッドがある場合、それは不可能なようですまたは、内部化されたアセンブリにある型の値を返します。

私が話していることを明確にするために、CommonUtils プロジェクトから Oracle.DataAccess を参照しており、Oracle.DataAccess で定義されている OracleParameter タイプを作成するための DbUtils を持っています。これは、内部化したいができないアセンブリです。

誰かが私のためにこれを明確にすることができますか?

依存関係に関連して他のプロジェクトに含まれるライブラリのリリースを作成するときのヒューリスティックとは何か、それらを含める必要があるかどうか疑問に思っています。

私の問題は次のとおりです。

名前が示すように、複数の場所で使用できる一連のユーティリティを提供する CommonUtilities ライブラリがあります。CommonUtilities の依存関係には、log4net.dll (ロギング フレームワーク) と Oracle.DataAccess.dll (データベース ドライバ) が含まれます。

CommonUtilities を含めたい MyProject という別のプロジェクトがあります。MyProject も Oracle.DataAccess に依存しています。

ILMerge を使用して CommonUtilities を単一のアセンブリ CommonUtilities.dll にマージし、それを MyProject から参照すると、すべてがコンパイルされますが、MyProject から Oracle.DataAccess を明示的に参照する必要があります。これは依存関係であり、CU にマージされたアセンブリを使用しないためです。Oracle.DataAccess への参照を追加すると、2 つの Oracle.DataAccess アセンブリが参照されるため、using ステートメントがあいまいになります。

私の場合、 ILMerge /Internalize を使用すると、内部化された Oracle.DataAccess アセンブリの型が CommonUtilities から返され、内部 MyProject としてマークされているため、返された型が認識されないため、コンパイル エラーが発生します。

これを機能させる唯一の方法は、この特定のアセンブリ (Oracle.DataAccess) を CommonUtilities にマージせず、MyProject からのみ参照することです。これにより、次のような新しい問題が発生します。どの Oracle.DataAccess.dll を参照する必要がありますか? CommonUtils で配布される依存関係ですか?

このすべてについて他の方法はありますか？