0

さまざまなアプリケーションで何度も何度も使用しているコードがかなりあります。私は最近、時間をかけてすべてを1つの場所に整理し、どのソリューションからでも参照できるようにすることにしました。私はクラスライブラリプロジェクトから始めて、使用するさまざまな関数といくつかの派生コントロールを追加しました。一部の関数は、派生コントロールによって使用されるだけでなく、アプリケーションから直接呼び出されます。プロジェクトをビルドし、プロジェクトでDLLの使用を開始しました。

このカスタムDLLに関していくつか質問があります（私はVisual C＃2010 Expressを使用しています）：

  1. 私が最初に気付いたのは、それが標準のMicrosoftライブラリのようには機能していないように見えることです。たとえば、「usingSystem.Windows.Controls;」を使用できます。プログラム内ですが、カスタムライブラリの名前空間を参照できるのはusingディレクティブのみです。理にかなっているのであれば、同じようにクラスを編成するとよいでしょう。Microsoftのようにクラスをネストすることは可能ですか？

編集：たとえば...アプリケーションコードの先頭に「Systemを使用して」と入力すると、選択できるサブ名前空間がたくさん表示されます。「Windows」と入力し続けると、さらに多くのサブカテゴリが表示されます。MyCustom.dllへの参照を追加し、「using MyCustom。」と入力し始めると、クラスまたはサブクラスが表示されません。クラスライブラリ内で物事を整理して、ストックライブラリのように動作させる方法を尋ねています。

  1. 再利用可能なすべてのコードを使用して1つの大きなDLLファイルを作成することをお勧めしますか？現時点では大量のコードはありませんが、拡張の余地を残したいと思います。このためのベストプラクティスは何ですか？

  2. アプリケーションのインストーラーを作成するときにDLLをどのように処理しますか？私は通常、InnoSetupを使用してインストーラーを作成します。

  3. これが私の主な関心事です...Application1でカスタムDLLの関数を使用し、誰かがそれをインストールしたとします。後でいくつかの機能を追加するか、構築しているApplication2のその機能に変更を加えます。新機能がApplication1を壊したり、望ましくない方法で何かを変更したりした場合、ユーザーがApplication2をインストールするとどうなりますか？カスタムDLLはアプリケーション間で共有されますか、それとも各アプリケーションに独自のバージョンのDLLがありますか？明らかに、新しいバージョンのApplication1をビルドして、新しいDLLで動作するようにしますが、ユーザーがそれを更新するという保証はありません。

ありがとう！

4

3 に答える 3

1

1）クラスファイルの名前空間をSomeNamespaceからSomeNamespace.SubNamespaceに変更することで、コードをいわば独自のサブ名前空間にネストさせることができます。ちなみに、Visual Studioのソリューションエクスプローラーでプロジェクトに[追加]->[新規]->[フォルダー]を実行すると、[追加]->[新規]->[クラス]を実行すると、VSは自動的に「ネストされた」名前空間を使用します。追加したフォルダーの名前。したがって、元の名前空間がMyDLLProjectで、プロジェクトにHelpfulStuffという名前のフォルダーを追加した場合、そのフォルダーに新しいクラスファイルを追加すると、名前空間が「MyDLLProject.HelpfulStuff」になり、その結果、完全に指定するか、「using MyDLLProject.HelpfulStuff」を含めることにより、コード内でそのように参照する必要があります。

2）すべての再利用可能なコードをDLLにラップすることは、他のプロジェクトで簡単に使用できるため、確かに良い習慣です。変更が必要な場合は、プロジェクトの数に関係なく、一度だけ変更する必要があります。これを使って。ただし、他の場所でコードを使用することは絶対にないと確信できる場合は、時間と労力を費やす価値がない可能性があります。

3）InnoSetupには、プロジェクトによって参照されるすべてのアセンブリ（.NET DLL）が自動的に含まれる必要があります。VSのソリューションエクスプローラーで、参照されているDLLを確認し、プロジェクトツリーの[参照]ノードから参照を追加できます。これは、DLLを作成することを選択した場合に、独自のDLLへの参照を追加する必要がある場所です。

4）DLLをGAC（グローバルアセンブリキャッシュ）に登録して共有コンポーネントにするという問題を実際に経験しない限り、これについて心配する必要はありません。アプリケーションは、使用するDLLの独自のコピーを常に持っており、想像している方法でお互いに足を踏み入れることはありません。

于 2012-09-18T03:10:19.360 に答える
1

DLLはあなたがやろうとしていることに最適です。

1）「System.Windows.Controlsを使用する」ことができます。プログラム内ですが、カスタムライブラリの名前空間を参照できるのはusingディレクティブのみです。

これは、MSがDLL内の複数のインターフェイスを公開しているためです。これを行うには、通常、DLLに複数のコンポーネントを登録して、コードを使用してクラスをクライアントにエクスポートする必要があります。

2）すべての再利用可能なコードで1つの大きなDLLファイルを作成するのは良い考えですか？

DLLは通常、デプロイメントレイアウトです。したがって、コードのサブセットのみに関心がある可能性のあるクライアントがある場合は、コードをより小さなDLLに分割しますが、必要がない限り、その必要はありません。他の開発チームに必要に応じて特定のAPIコンポーネントを提供することも可能です。そのため、必要な場合にのみ、より小さな粒度のコンポーネントを出荷し、DLLを大きくし、クライアントを増やすと、より多くの変更がそれらに影響を与えます。

3）アプリケーションのインストーラーを作成するときにDLLをどのように処理しますか？私は通常、InnoSetupを使用してインストーラーを作成します。

Windows用の最新のインストーラーにはすべて、DLLを配布し、WindowsレジストリーのDLL内にコンポーネントを登録する機能が含まれています。

4）これが私の主な関心事です...（デプロイメント間で同じdllの複数のバージョン）

昔、人々がDLLをWindowsシステムフォルダに展開したとき、これは大きな問題でした。これは、適切に展開されたWindowsアプリケーションには当てはまりません。WindowsはDLLをインストールアプリケーションのローカルに自動的にサンドボックス化するため、system32へのインストールまたはそこからのロードを考えているアプリでさえ実際にはそうではありません。DLLの展開のルールに従い、アプリと一緒にDLLを出荷し、システムディレクトリに強制的に入れようとしない限り、競合について心配する必要はありません（Windowsでは許可されない可能性があります）。

お役に立てば幸い

于 2012-09-18T02:49:41.063 に答える
1
  1. 私はあなたの問題を理解していません。言い換えてください。
  2. 異なります。通常、再利用可能なライブラリはソリューションに固有です（共通のタイプを含む共有ライブラリenumやデータベースモデルなど）。さまざまなプロジェクトで再利用するコードスニペットがある場合は、ソースファイルをプロジェクトにコピーするか、コピーを作成せずにソースファイルを参照する（VSではこれを実行できます）ことをお勧めします。ソース管理を使用する場合は注意してください。
  3. 心配することは何もありません。DLLはアプリケーションのもう1つの依存関係です。binVSは（デフォルトで）DLLをアプリケーションプロジェクトの出力ディレクトリにコピーするため、フォルダー内のすべてのファイル（XMLドキュメントファイルを除く）を含めるようにインストーラーを構成する必要があります。
  4. DLLをファイルシステムで共有するために多くの問題を起こさない限り（これは、HDDスペースが限られていた1990年代に一般的に行われたことでした。例については、「MicrosoftShared」フォルダを参照してください）。アプリケーションの各ディストリビューションには、共有DLLの独自のコピーがあります（「共有」は実行時ではなくコンパイル時に行われます）。.NET CLRは、アプリケーションがコンパイル対象のDLLファイルと互換性のないDLLファイルを使用して起動しようとすると、エラーをスローします（厳密な名前のアセンブリを使用すると、これをさらに強制できます）。
于 2012-09-18T02:49:55.837 に答える