次の方法で共有

.NET アプリケーションを構成して簡単に展開する

  • [アーティクル]

 

Stephen Scott
StreamByte Limited

2000 年 2 月

概要：Microsoft .NET Frameworkに表示されるアプリケーション展開オプションを計画および設計する方法。 (11ページ印刷)

目標

  • アセンブリが配置にどのように影響するかを理解する
  • 一意の名前空間の重要性を理解する
  • クラスで属性を適切に使用することの利点を認識する
  • アプリケーション ドメインの優れた使用の利点を認識する

前提条件

  • Microsoft® .NET の開発を十分に理解している
  • アセンブリの基本的な理解がある
  • 名前空間の基本的な理解がある

内容

配置の理念
.NET 展開の基礎
名前空間
属性
アプリケーション ドメイン
.NET と Visual Basic 6.0 の展開の違い
まとめ

配置の理念

.NET Frameworkのメイン利点の 1 つは、アプリケーションのデプロイに対する新しいアプローチです。 Microsoft は、以前の展開手法よりもはるかにシンプルで柔軟性の高いシステムを開発しました。

この新しいデプロイ方法では、アプリケーションの設計時に最適なオプションがいくつかあります。 このドキュメントでは、アプリケーション設計の観点から展開方法について説明します。

.NET 展開の基礎

すべての Microsoft .NET アプリケーションは、1 つ以上のアセンブリの形式で展開されます。 アセンブリは、1 つ以上のファイルで構成される機能の論理単位です。 これらのファイルの 1 つにアセンブリのマニフェストが含まれます。 マニフェストは、アセンブリの ID、パブリックにエクスポートされた型、ファイル、依存関係を記述するメタデータです。

アセンブリ

アセンブリはプライベートまたは共有として展開でき、1 つのファイルまたは複数のファイルで構成できます。 特定の方法でアセンブリを配置する際の反響を理解すると、アプリケーションを異なるアセンブリに分割する方法と、それらのアセンブリを展開する方法を決定できます。

メモこのドキュメントで詳しく説明するすべての展開オプションは、ターゲット コンピューターに.NET Frameworkがインストールされていることを前提としています。

単一ファイルの展開

Microsoft .NET を使用すると、1 つの.exe ファイルで構成される 1 つのアセンブリとしてアプリケーションを展開できます。 この方法により、アプリケーションのデプロイは非常に簡単になりますが、すべてのアプリケーションがこの設計に適しているわけではありません。

アプリケーションで .NET Framework クラスのみを使用する場合、アプリケーションが非常に小さい可能性が高く、アプリケーション全体とは別にアプリケーションの個々の側面をデプロイする可能性が低いので、.exe ファイルの展開方法が適している可能性があります。

単一の.exe展開に適した、以下に示す簡単なプログラムを見てみましょう。 この Microsoft Visual Basic® .NET Windows フォーム プロジェクトは、Microsoft Visual Studio® .NET を使用して作成されました。 これには、ボタン、テキスト ボックス、およびリスト ボックスを含む 1 つのフォームがあります。 プロジェクトは、約 10 KB の 1 つの.exe ファイル アセンブリにコンパイルされます。

図 1. 1 つの 10 KB アセンブリにコンパイルされる小さなサンプル プログラム

.exe アセンブリ ファイルは、.NET Frameworkがインストールされている任意のコンピューターにコピーでき、追加の構成なしで実行されます。 必要なファイルをターゲット コンピューターに単純にコピーするこの方法は、XCOPY デプロイと呼ばれます。

プライベート アセンブリ

.NET Frameworkはすべてクラスに関するものであり、その設計では、クラスに基づいてアプリケーションを記述することをお勧めします。 クラスを記述するときは、関連するクラスをクラス ライブラリに配置することをお勧めします。 これらのクラス ライブラリを Visual Studio .NET でビルドすると、最終的に.dllの形式でアセンブリが作成されます。 ライブラリ内のクラスのいずれかを使用する必要があるプログラムには、.dll アセンブリへのアクセスが必要です。 アプリケーションと同じディレクトリに配置されたアセンブリは、 プライベート アセンブリと呼ばれます。

ここで見たプログラムListBoxAdd.exe、LBClasses.dllという新しいクラス ライブラリに存在するクラスへのアクセスが必要であるとします。 アプリケーションが正常に動作するには、ListBoxAdd.exeとLBCLasses.dllの 2 つのファイルをデプロイする必要があります。 前と同様に、これらの 2 つのファイルをターゲット コンピューター上のディレクトリにコピーするだけです。

アプリケーションが実行時にアセンブリを参照しようとすると、既定では、アプリケーションと同じディレクトリでそのアセンブリが検索されます。 そのため、この場合、ListBoxAdd.exeが新しいクラス ライブラリ内の任意のクラスを参照しようとするとすぐに、.NET Framework共通言語ランタイムは、アプリケーションと同じディレクトリ内のLBClasses.dllを検索します。

LBClasses.dllは、ListBoxAdd.exeまたは同じディレクトリ内の他のアプリケーションでのみ使用できます。 別のディレクトリにある別のアプリケーションでLBClasses.dllを使用する必要がある場合は、そのアプリケーションのディレクトリにLBClasses.dllをデプロイします。 ([共有アセンブリ] セクションでアセンブリを共有する方法について説明します)。

アプリケーションで多数のアセンブリが必要な場合は、単にアプリケーション ディレクトリに配置するよりも、より整理された方法で配置することができます。 共通言語ランタイムを使用すると、適切な名前のサブディレクトリ、またはアプリケーション構成ファイルによって参照されるカスタムの名前付きディレクトリにアセンブリをデプロイでき、プライベート アセンブリの原則は維持されます。 これらの両方の手法を見てみましょう。

ディレクトリの使用

共通言語ランタイムが必要なアセンブリを検索するために使用するプロセスは、プローブと呼ばれます。 ランタイムがアプリケーション ディレクトリにアセンブリを見つけることができない場合は、探しているアセンブリと同じ名前のサブディレクトリをプローブします。 ファイル拡張子はアセンブリ名の一部とは見なされません。

図 2. アセンブリがアセンブリと同じ名前のサブディレクトリに配置されている場合、アセンブリが見つかります

そのため、図 2 のようにアプリケーション ディレクトリ構造を再構築し、LBClasses.dllを LBClasses サブディレクトリにコピーできます。 アプリケーションは、追加の構成なしで実行されます。

アプリケーション構成ファイル

アプリケーションと同じディレクトリ内の構成ファイルを使用して、アプリケーションを構成できます。 この構成ファイルの名前は、アプリケーション名に拡張子 .config を付けた名前になります。 そのため、ListBoxAdd アプリケーションの構成ファイルは ListBoxAdd.exe.config と呼ばれます。

図 3: アプリケーション構成ファイルはアプリケーションと同じディレクトリに保存され、メイン アプリケーション アセンブリと同じ名前を持ち、その後に .config

アプリケーション構成ファイルには、個々のアプリケーションに固有の設定が含まれています。 これらの設定には、アセンブリのプローブ方法を定義するアセンブリ バインド ポリシーが含まれます。

プローブが、アプリケーション ディレクトリまたはアセンブリと同じ名前のサブディレクトリでアセンブリを見つけることができない場合は、次にアプリケーション構成ファイル (存在する場合) でプローブ手順を探します。

アプリケーション構成ファイルの例を次に示します。

<configuration>
<runtime>
  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
     <probing privatePath="AssemblyDir1;AssemblyDir2"/>
  </assemblyBinding>
</runtime>
</configuration>

このアプリケーション構成ファイルでは、プローブ タグを使用して、プローブするプライベート パスを設定し、AssemblyDir1 と AssemblyDir2 という 2 つのディレクトリを含めます。 これらのディレクトリはサブディレクトリと見なされ、アプリケーション ディレクトリの下に存在します。

プライベート アセンブリの合計

プライベート アセンブリを使用すると、メンテナンスのためにアプリケーションを複数のアセンブリに分割する利点があります。任意のアセンブリをいつでも交換でき、アプリケーションにのみ影響します。 また、複数のプログラムで使用されるアセンブリを複数回デプロイする必要があるという欠点もあります。 プライベート アセンブリにはバージョン管理機能が用意されていないため (次の「共有アセンブリ」セクションで説明します)。そのため、配置されたアセンブリが他のアセンブリの要件と互換性があることを確認するのはユーザー次第です。

共有アセンブリ

多くの場合、アセンブリは、複数のアプリケーション、または不明なアプリケーションのホストによって必要になります。 この場合、アセンブリをすべてのアプリケーションでプライベートに展開するのではなく、必要なアプリケーションでアセンブリを使用できるようにすることをお勧めします。 .NET Frameworkを使用すると、共有アセンブリを使用してこれを実現できます。

グローバル アセンブリ キャッシュ

共有アセンブリは、通常、グローバル アセンブリ キャッシュ (GAC) にインストールされます。 GAC は、アセンブリのマシン全体のストアです。

GAC に格納されているアセンブリはパブリックであるため、アセンブリの実際の名前、バージョン (次のセクションで説明)、カルチャ、および公開/秘密キーペアで構成される 厳密な名前と呼ばれる名前が必要です。 GAC へのアセンブリのインストールに関連するプロセス全体は、このドキュメントの範囲を超えていますが、その影響はありません。

キーを生成してインストール ユーティリティを実行する必要が生じ、プライベート アセンブリに対する XCOPY の直接の展開シナリオがなくなりました。 GAC へのアセンブリのインストールは、以前の COM 登録よりもはるかに面倒ではありませんが、それでもアクションが必要です。 また、アプリケーションと共にインストールされた共有アセンブリもアンインストールする必要があるため、アプリケーションのアンインストールはより複雑になります。 これらの制限により、XCOPY デプロイを必要とするアプリケーションは、引き続き共有アセンブリをアプリケーションと同じディレクトリにコピーできます。 ディレクトリとサブディレクトリを削除すると、プライベート アセンブリのみを使用するアプリケーションが意図的にアンインストールされたり、誤ってアンインストールされたりする可能性があります。

一般に、アプリケーション展開シナリオを設計するときは、可能な限りプライベート アセンブリの使用を試みる必要があります。 アセンブリは、複数のアプリケーションで必要であり、その共有デプロイが複数のプライベート デプロイよりも簡単であると見なされる場合にのみ共有する必要があります。

共有アセンブリが必要な場合の良い例は、.NET Framework自体です (図 4 を参照)。 デプロイするすべてのアプリケーションはフレームワークのアセンブリを使用する必要があり、すべてのアプリケーションでフレームワーク全体をプライベート アセンブリのセットとしてデプロイする必要はありません。

図 4: .NET Frameworkは、一連の共有アセンブリとして展開されます

アセンブリのバージョン管理

従来の Windows アプリケーションでは、共有ライブラリは標準の Windows .dll として展開され、多くの場合、%System% ディレクトリに配置されます。 この問題は、2 つのベンダーがアプリケーションと同じライブラリ .dllを試して展開できることです。 ディレクトリに存在できる.dllのコピーは 1 つだけであるため、あるベンダーが別のベンダーのライブラリのインストールを上書きできます。 両方のインストールで同じバージョンのライブラリが使用されている場合、問題は発生しません。 ただし、あるベンダーが新しいバージョンのライブラリをインストールした場合、古いバージョンを使用しているアプリケーションが動作しなくなる可能性があります。 つまり、ベンダーはライブラリのすべてのコピーを下位互換性のあるものにする必要がありました (多くの場合、失敗しました)。 この状況は、アプリケーションがベンダー ライブラリを古いバージョンで盲目的に上書きした場合にも発生する可能性があります。 このような状況の混乱は、一般に "DLL HELL" と呼ばれます。

Microsoft .NET では、同じアセンブリの異なるバージョンを GAC に同時に存在できるだけでなく、同時に読み込むこともできます。

図 5 では、GAC の LBClasses アセンブリの 3 つのコピーを確認できます。

図 5: GAC を使用すると、同じアセンブリの複数のバージョンを同時にインストールして読み込むことができます

[バージョン] 列を見ると、LBClasses の各コピーのバージョン番号が異なることがわかります。 これらの 4 部構成のバージョン番号は、次のように構成されます。

MajorVersion.MinorVersion.BuildNumber.Revision

一般に、リビジョンとビルドの変更は互換性があり、マイナー バージョンまたはメジャー バージョンの変更には互換性がないものとします。

次のいずれかのコード サンプルにコードを追加することで、バージョン番号がアセンブリに追加されました。 最初のサンプルは Visual Basic .NET コード、2 つ目は C# コードです。

Imports System.Reflection

<Assembly: AssemblyVersion("1.0.0.0")> 
<Assembly: AssemblyKeyFile("C:\originator.key")>
using System.Reflection;

[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyKeyFile("C:\\orginator.key")]

(上記のサンプルのように) アセンブリのバージョン番号を完全に修飾する場合は、変更するバージョン番号の一部を更新する必要があります。 バージョン番号を 1.0.0.* として宣言することで、アセンブリをビルドするたびに Visual Studio .NET でリビジョンが自動的に更新されるようにすることができます。 リビジョンとビルド番号の両方を自動的に更新する場合は、バージョン番号として 1.0.* を宣言します。 アセンブリをビルドするときに、Visual Studio .NET はビルドごとにバージョン番号を更新します。

アセンブリが変更されて再構築されると、GAC に再インストールされます。これにより、この新しいバージョンが追加され、古いバージョンも保持されます。

GAC にアセンブリのバージョンが 2 つあるので、ListBoxAdd で使用するものを知る必要があります。 幸いなことに、これは非常に簡単です。

存在する場合、アプリケーションはビルドされたアセンブリのバージョンを使用します。 アプリケーションが別のバージョンにアクセスしようとすると、アプリケーションの構成ファイルで別のバージョンを使用するように指定しない限り、エラーが発生します。 アプリケーション構成ファイルを使用して別のバージョンのアセンブリを読み込む例を次に示します。

<configuration>   
    <runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
            
          <dependentAssembly>
            <assemblyIdentity name="LBClasses" 
                              
                 publicKeyToken="a9f5e3774993ed86"
                 culture="" />
            <bindingRedirect oldVersion="1.0.599.29986"
                               
                             newVersion="1.0.599.30067"/>
            </dependentAssembly>

        </assemblyBinding>
    </runtime>
</configuration>

バージョン管理により、下位互換性を必要とせずに共有ライブラリを更新できるようになりました。つまり、新しいバージョンのアプリケーションを、古いバージョンを気にせずに再構築できます。

マルチファイル アセンブリ

マルチファイル アセンブリは、複数のファイルから作成されたアセンブリです。 コンポーネントには、.dll ファイルまたはリソース ファイル.exe ファイルを指定できます。 コンポーネントは一緒にアセンブリの論理概念を構成します。 1 つのコンポーネントには、アセンブリ内のすべてのファイルを記述するマニフェストが含まれています。

マルチファイル アセンブリを使用するタイミング

マルチファイル アセンブリは、マルチ開発者プロジェクトに大きな利点があります。 多くの場合、1 つのエンティティとして最もよく見られる論理的な作業がありますが、開発目的では、より小さな作業単位ほど適しています。 マルチファイル アセンブリを使用すると、開発者は、アプリケーションによって 1 つのエンティティとして論理的に表示される一連のコンポーネント (.dlls や .exes など) を生成できます。

例を見てみましょう。たとえば、10 人の開発者がそれぞれ 1 つのコンポーネントを生成します。 その後、コーディネーターは、アセンブリ全体 (またはファイルのコレクション) のマニフェストを含む 11 番目のコンポーネントを生成できます。 これらの 11 個のファイルは、1 つのアセンブリであるかのように展開されます。 最初にこのアセンブリを使用するアプリケーションは、マニフェストを含むコンポーネントのみを読み込みます。 アプリケーションによって異なるクラスまたはメソッドが作成または呼び出されると、適切なコンポーネントが読み込まれます。 つまり、アプリケーションが実際に実行するコンポーネントを読み込むだけで済みます。

この例をさらに詳しく見るために、コードの変更が必要な場合は、変更されたコンポーネントと、更新されたマニフェストを含むコンポーネントのみを再デプロイする必要があります。

マルチファイル アセンブリは、保守可能な小さなパーツの機能を現実的に論理的にグループ化します。 これらはダウンロード用にコードを最適化する優れた方法であり、さまざまな言語で記述されたコードで構成されるアセンブリを構築する場合に便利です。

マルチファイル アセンブリのビルド

現在、Visual Studio .NET では、既定で 1 つのファイル アセンブリが作成されます。 コマンド ライン コンパイラで /addModule 入力パラメーターを使用して、マルチファイル アセンブリを作成できます。 マルチファイル アセンブリを作成する最も簡単な方法は、メイクファイルを使用することです。 ただし、メイクファイルとコマンド ライン コンパイラの使用は、このドキュメントの範囲外です。 マルチファイル アセンブリのビルドの詳細については、「.NET Framework開発者ガイド」の「マルチファイル アセンブリの例」を参照してください。

アセンブリの合計

ご覧のように、アプリケーションをアセンブリに分割する方法を決定すると、それらのアセンブリを配置する方法に影響します。 アプリケーションに固有のクラスとコードは、プライベート アセンブリとして最適にデプロイされます。 アプリケーション間で共有されるアセンブリであっても、GAC のインストールとバージョン管理の問題を回避するために、プライベート アセンブリとして複数回配置するのが最適な場合があります。 ただし、アセンブリ のバージョンは、プライベート アセンブリとして展開されている場合でも確認されます。

多くのアセンブリまたは少数のマルチファイル アセンブリを使用することを選択すると、アプリケーションの配置と保守の方法にも影響します。

共有する必要があるアセンブリは、GAC にインストールできます。 これにより、インストール (およびアンインストール) ルーチンが複雑になりますが、アセンブリの一般公開が可能になり、パフォーマンスの向上などの他の利点が得られます。

これらすべてのオプションを使用すると、アプリケーション開発者は、アプリケーションのさまざまな側面を最適な方法でデプロイできます。 しかし、これを可能にするには、アプリケーションの構造をデプロイする方法に照らして慎重に検討する必要があります。

名前空間

独自のクラス ライブラリを記述するときは、名前空間の名前を付ける方法をメモしておく必要があります。 名前空間は、オブジェクトの分離に役立つよう発明されました。 class1 と呼ばれる 2 つのクラスを使用して、異なる名前空間に存在するようにすることができます。 この方法は、名前空間に一意の名前が付けられていることを確認する場合にのみ機能します。

たとえば、グラフィックス クラスのライブラリを作成した場合、グラフィックス ライブラリの他のプロデューサーが同じように行う可能性があるため、"graphics" と呼ばれる名前空間にすべてのクラスを配置するのは賢明ではありません。 これにより、両方のライブラリが同じコンピューターに配置された場合に、名前空間の競合が発生する可能性があります。

メモ ランタイムでは、異なるアセンブリ内にある同じ名前 (名前空間を含む) を持つ 2 つの型が完全に異なるため、実行時に競合が発生することはありません。

名前空間の分離を保証する一般的に受け入れられる方法は、名前空間の名前に会社またはアプリケーション名 (または類似の識別子) を含める方法です。 グラフィックス ライブラリでは、次に示すように、名前空間 YourCompanyName.Graphics を使用する場合があります。

using System;

namespace YourCompanyName.Graphics
{
   public class WidgitClass1
   {
      public WidgitClass1()
      {
         // Code
      }
   }
}

属性

メタデータは、Microsoft .NET 哲学の最も顕著な資産の 1 つです。 メタデータは、アプリケーション自体に関するデータです。 特定のクラス、プロパティ、メソッド、イベントに関する情報を提供できます。 属性は、多くの場合、クラス、プロパティ、メソッド、およびイベントにメタデータを追加するために使用されます。

Microsoft .NET でクラスを開発するときに、readOnly、Public、Private など、.NET Frameworkで使用できる定義済みの属性の一部を使用した可能性があります。独自のカスタム属性を作成することもできます。

カスタム属性

カスタム属性はクラスとして実装されます。 カスタム属性クラスを開発すると、System.Attribute から継承されます。 カスタム属性の位置指定パラメーターはクラスのコンストラクターに実装され、その名前付きパラメーターはプロパティとして実装されます。 また、使用できる要素の型をコンパイラに通知する属性も含める必要があります。

カスタム属性の作成に関する詳細については、このドキュメントの範囲を超えています。

カスタム属性の使用

クラスでカスタム属性を使用することは、主にクラスを使用する他の開発者にとって有益です。 作成者、バグ修正番号、導入されたバージョン コードを示すステートメントなどの情報を使用してクラスにコメントを付けるのは、ソース コードにアクセスできる開発者にとって最適です。 ただし、場合によっては、ソース コードにアクセスできないクラスのユーザーが見ることができる情報をクラスに埋め込むのが最適な場合があります。 カスタム属性 (すべての属性など) は、リフレクションと呼ばれる手法を使用して クラスを使用する開発者が使用できます。 カスタム属性の形式でクラスに情報を入れることで、クラスの使用に役立つこの情報を使用できるようになります。

.NET Frameworkに付属する ILDasm ツールを使用して、クラスのカスタム属性 (クラスの組み込み属性と共に) を表示できます。 クラスのカスタム属性を表示するための使いやすいインターフェイスを提供する場合は、System.Reflection アセンブリを使用してクラスを調べる独自のアプリケーションを開発できます。 Microsoft .NET でのリフレクションの使用に関する情報は、Microsoft .NET 開発者ガイドを参照してください。

アプリケーション ドメイン

Microsoft .NET のアプリケーションは、プロセス内で実行されます。 プロセスは 1 つ以上のアプリケーション ドメインに分離されます。 すべてのプロセスには少なくとも 1 つのアプリケーション ドメイン (既定) がありますが、作成するときに追加のアプリケーション ドメインを持つことができます。

アプリケーション ドメインは、プロセス内のプロセスのように動作するオブジェクトです。 アプリケーション ドメインで実行されるすべてのものは、同じプロセス内の他のアプリケーション ドメインから分離されます。つまり、あるアプリケーション ドメインがクラッシュしても、他のアプリケーション ドメインには影響しません。 プロセス内の個々のアプリケーション ドメインは、個別に開始および停止できます。

アプリケーション ドメインの使用

ほとんどのアプリケーションでは、既定のアプリケーション ドメインのみが必要です。 特定のコードをアンロードする必要がプログラム全体を停止しないように、コードを分離する場合は、追加のアプリケーション ドメインを作成することもできます。 たとえば、サードパーティ製プラグインをサポートするアプリケーションを作成した場合などです。各プラグインを個別のアプリケーション ドメインに読み込んで、各プラグインをメイン プログラムと相互に分離することができます。

アプリケーション ドメインには異なるセキュリティ環境を設定することもできます。これにより、さまざまなセキュリティ制約の下でプログラムのさまざまな部分を実行できます。

アプリケーション ドメインの作成

アプリケーション ドメインは、AppDomain クラスによってカプセル化されます。 このクラスの静的 CreateDomain メソッドを呼び出すことによって、新しいドメインが作成されます。

AppDomain MyAppDomain = 
   AppDomain.CreateDomain("Some Friendly Name",null,null);

アプリケーション ドメインを作成したら、AppDomain オブジェクトの CreateInstance メソッドを使用して、そのドメイン上にオブジェクトのインスタンスを作成できます。

アプリケーション ドメインのコーディングの詳細については、このドキュメントの範囲外です。

.NET と Visual Basic 6.0 の展開の違い

これまでに説明した内容とは、Visual Basic .NET アプリケーションの展開は、Visual Basic 6.0 で記述されたアプリケーションを展開する場合とは異なっていることは明らかです。

  Visual Basic 6.0 Visual Basic .NET
ランタイム Visual Basic 6.0 では、特定の Visual Basic 6.0 ランタイム ファイルをデプロイする必要があります。 Visual Basic .NET アプリケーションでは、アプリケーションの開発に使用される言語に関係なく、.NET Frameworkを展開する必要があります。
Components 標準の Visual Basic コントロール以外の Microsoft ActiveX® コントロールを使用する Visual Basic 6.0 アプリケーションでは、必要な .dll をデプロイする必要があります。

各 ActiveX .dllまたは OCX は、RegSvr32.exeを使用して登録する必要があります。

 標準以外のコンポーネントまたはオブジェクトを使用する Visual Basic .NET アプリケーション.NET Framework、正しいアセンブリを展開する必要があります。

これらのアセンブリは、共有しない限り、フォームの登録を必要としない場合があります。その場合は、アセンブリを GAC にインストールする必要があります。

まとめ

アプリケーションの設計方法は、アプリケーションのデプロイ、更新、および使用方法に影響を与える可能性があります。 Microsoft .NET では、展開オプションに多くの柔軟性がありますが、実際には、アプリケーションの設計を開始するときに使用する方法を計画している場合にのみ役立ちます。

クラス ライブラリとアセンブリのアーキテクチャは、デプロイとアップグレードをシンプルに保つための鍵です。 適切な名前の名前空間を使用すると、多くの問題が発生する可能性があります。また、属性を慎重に計画することは、自分とクラスの他のユーザーの両方にとって有益な可能性があります。

著者について

Steve Scott は、イギリスのグロスターシャーに拠点を置く StreamByte Limited を運営しています。 1987年にソフトウェア業界に入社して以来、彼は思い出すよりも多くのプラットフォームで多数のプログラミング言語とデータベースを使用して、多くの業界で働いてきた。 近年では、英国諸島、ヨーロッパ、米国で開発者、トレーナー、コンサルタントとして Web 開発に特化しています。 スティーブは、彼が持っている小さな空き時間を過ごす小さな子供の多くの父親です。

情報伝達グループについて

情報通信グループ(www.informant.com)は、情報技術分野を中心とした多様なメディア企業です。 ソフトウェア開発出版物、カンファレンス、カタログ発行、Webサイトを専門とするICGは、1990年に設立されました。 米国と英国にオフィスを構え、ICGは、質の高い技術情報に対するITプロフェッショナルの意欲を満たし、尊敬されるメディアおよびマーケティングコンテンツインテグレーターを務めてきました。

Copyright © 2002 Informant Communications Group and Microsoft Corporation

技術編集:株式会社PDSA、KNGコンサルティング