エクスポート (0) 印刷
すべて展開
C#
展開 最小化

Microsoft .NET Framework FAQ

.NET Framework 1.1

Microsoft Corporation

2000 年 12 月

概要:本稿は、Microsoft .NET と Microsoft .NET Framework についてよく聞かれる質問をまとめたものです(15 ページ)。

目次

概念的な質問
ランタイムに関する技術的な質問
   用語
   アセンブリ
   アプリケーションの配置と分離
   ガベージ コレクション
   リモーティング
   相互運用性
   セキュリティ

概念的な質問

ランタイムに関する技術的な質問

用語

アセンブリ

アプリケーションの配置と分離

ガベージ コレクション

リモーティング

相互運用性

セキュリティ

概念的な質問

.NET とは何ですか?

簡単に言えば、Microsoft® .NET は、ソフトウェアをサービスとして提供するための Microsoft の戦略です。詳細については、このトピックについてのホワイトペーパーをご覧ください。

このホワイトペーパーを引用して、.NET の主な特徴を簡単に説明します。

  • Microsoft .NET プラットフォーム
    次世代のサービスを構築し運用するための .NET インフラストラクチャとツール群、リッチなクライアントを実現する .NET ユーザー エクスペリエンス、.NET ビルディング ブロック サービス、次世代のスマート インターネット デバイスを実現する .NET デバイス ソフトウェアで構成されます。

  • Microsoft .NET 製品およびサービス
    Microsoft® Windows.NET (ビルディング ブロック サービスの中核となるセットを含む)、MSN.NET、パーソナル サブスクリプション サービス、Microsoft® Office.NET、Microsoft® Visual Studio.NET、Microsoft® bCentral™ for .NET があります。

  • サードパーティーの .NET サービス
    さまざまなパートナー企業および開発者が、.NET プラットフォーム上で企業向けの垂直型サービスを構築することになるでしょう。

本 FAQ は、.NET プラットフォームのインフラストラクチャの一部である .NET Framework を対象としています。.NET Framework の詳細については、次の質問をご覧ください。

.NET Framework とは何ですか?

.NET Framework は、Web サービスなどのアプリケーションを構築、配置、実行するための環境です。Common Language Runtime、Framework クラス、ASP.NET という 3 つの主要部分で構成されます。

.NET Framework を利用できるのは、Web サイトを構築する場合だけですか?

.NET Framework を使えば、優れた Web アプリケーションを作成できます。しかし、.NET Framework は通常のアプリケーションを作成するときにも役立ちます。Windows ソフトウェアを書く場合に(ATL/COM、MFC、Microsoft® Visual Basic® を使っても、標準の Microsoft® Win32® でもかまいません)、.NET は現在のアプリケーション構築方法に多くの利点をもたらします。もちろん、Web サイトを開発する場合も、.NET Framework には、ASP.NET をはじめ、魅力的な機能が多数あります。

.NET Framework SDK はどこで入手できますか?

.NET Framework SDK Beta 1 は、MSDN Online Downloadsからダウンロードできます。サイズが非常に大きいため(106 MB)、一括ダウンロードのほか、11 回に分けてダウンロードする方法も用意されています。また、Microsoft Developer Store に CD を注文することもできます。

  • アメリカ/カナダ

  • その他の国

.NET Framework はどのようなプラットフォームで動作しますか?

Beta 1 バージョンは、Microsoft® Windows® 2000、Windows 95/98/ME、Windows NT® 4.0 で動作します。

.NET Framework には、.NET Compact Framework というバージョンもあります。.NET Compact Framework は、.NET Framework の一部の機能を、携帯電話や Enhanced TV といったデバイスに提供することを目的に設計されています。.NET Compact Framework は、Windows CE などの組み込みオペレーティング システムで動作します。

.NET Framework はどのようなプログラミング言語をサポートしますか?

.NET Framework は特定の言語に依存しません。つまり、ほとんどあらゆる言語から .NET Framework を利用できます。現在は、C++、Microsoft® Visual Basic.NET、JScript®、Microsoft の最新言語である C# など、いくつかの言語で .NET プログラムを構築できます。多数のサードパーティ製の言語でも、.NET Framework アプリケーションを構築できるようになるでしょう。たとえば、COBOL、Eiffel、Perl、Python、Smalltalk などです。

.NET Framework と COM+ のサービスには、どのような関係がありますか?

.NET Framework では、COM+ のサービスへのフル アクセスが可能です。また、サービスの対象となるコンポーネントもより簡単に構築できます。

.NET Framework のコンポーネントは、COM+ アプリケーションに追加できます。追加したコンポーネントは、トランザクション、オブジェクト プーリング、待ち行列に入れられるコンポーネント、イベントといった自動コンポーネント サービスを利用できます。

.NET Framework と DCOM には、どのような関係がありますか?

DCOM は、プロセス間通信のための COM インフラストラクチャです。.NET Framework は、プロセス間通信のためのプラグ可能チャネルとフォーマッタを多数サポートしています。管理コードと非管理コードを切り替えるときに、.NET Framework は COM インフラストラクチャ、特に DCOM を使用します。COM+ のサービスを使用するシナリオはすべて、管理コードから非管理コードへの切り替えを行うため、標準では DCOM を使います。.NET Framework は、相互運用性が重要な場合のプロセス間通信用に SOAP (Simple Object Access Protocol)もサポートします。

.NET Framework は、単に Windows DNA の新しい名前なのですか?

違います。Windows DNA は、密結合の分散型 Web アプリケーションを構築するためのアーキテクチャです。疎結合の分散型アプリケーションが求められることが多くなったため、Microsoft は .NET アーキテクチャを開発しました。.NET Framework は .NET アーキテクチャの一部です。

ランタイムに関する技術的な質問 用語

Common Language Runtime (CLR)とは何ですか?

Common Language Runtime は、.NET Framework アプリケーションの実行エンジンです。

以下をはじめ、多くのサービスを提供します。

  • コード管理(ロードと実行)

  • アプリケーション メモリの分離

  • タイプ セーフの検証

  • IL からネイティブ コードへの変換

  • メタデータへのアクセス(拡張タイプ情報)

  • 管理オブジェクト用メモリの管理

  • コード アクセス セキュリティの適用

  • 言語間の例外などの例外処理

  • 管理コード、COM オブジェクト、既存 DLL (非管理コードとデータ)の間の相互運用

  • オブジェクト レイアウトの自動化

  • 開発者によるサービス(プロファイリング、デバッグなど)のサポート

Common Type System (CTS)とは何ですか?

Common Type System は、Common Language Runtime に組み込まれたリッチな型システムで、ほとんどのプログラミング言語に含まれる型と操作をサポートします。Common Type System を利用して、さまざまなプログラミング言語を完全にインプリメントできます。

Common Language Specification (CLS)とは何ですか?

Common Language Specification は、ライブラリおよびコンパイラの作成者の指針となる構造および制限のセットです。これによって、CLS をサポートするすべての言語からライブラリをフル活用できるようになり、言語を統合できるようになります。Common Language Specification は、Common Type System のサブセットです。また、Common Language Specification は、他の開発者に使用されるコードを書いているアプリケーション開発者にとって重要です。開発者が CLS の規則に従ってパブリックにアクセス可能な API を設計すると、Common Language Runtime をターゲットとするその他すべてのプログラミング言語から、その API を簡単に使用することができます。

Microsoft Intermediate Language (MSIL)とは何ですか?

MSIL は CPU に依存しない命令セットで、.NET Framework プログラムをコンパイルすると生成されるものです。オブジェクトでのメソッドのロード、格納、初期化、呼び出しに関する指示が含まれています。

MSIL とメタデータおよび Common Type System を組み合わせると、真の意味で、言語の枠を越えた統合が可能になります。

MSIL は、実行前にマシン コードに変換されます。インタプリタでは実行されません。

管理コードと管理データとは何ですか?

管理コードとは、Common Language Runtime のサービスをターゲットとするために記述されるコードです(「Common Language Runtime とは何ですか?」をご覧ください)。これらのサービスをターゲットとするには、コードはランタイムに対して最低レベルの情報(メタデータ)を提供しなければなりません。C#、Visual Basic.NET、JScript.NET コードはすべて、標準で管理されます。Visual Studio.NET C++ コードは標準では管理されませんが、そのコンパイラがコマンドライン スイッチ(/CLR)を指定することによって、管理コードを作成することができます。

管理コードと密接に関係するのが、Common Language Runtime のガベージ コレクタによって割り当てられたり、割り当てを解除されたりする管理データです。C#、Visual Basic、JScript.NET データは、標準で管理されます。ただし、C# データは特別なキーワードを使って管理対象外として示されます。Visual Studio.NET C++ データは、標準では管理されませんが(/CLR スイッチを使った場合も)、Managed Extensions for C++ を使う場合は、__gc キーワードによって、クラスを管理対象として示すことができます。名前から分かるように、これはクラスのインスタンス用のメモリが、ガベージ コレクタによって管理されることを意味します。さらに、クラスは .NET Framework コミュニティの完全なメンバーとなり、その利点や制限がもたらされます。利点の例としては、他の言語で記述されたクラスとの適切な相互運用性があります(たとえば、管理対象の C++ クラスは Visual Basic クラスから継承可能です)。制限の例としては、管理対象のクラスは 1 つのベース クラスからしか継承できないことが挙げられます)。

アセンブリ

アセンブリとは何ですか?

アセンブリは、.NET Framework アプリケーションの主要なビルディング ブロックです。1 つの実装単位(1 つまたは複数のファイル)として構築、バージョニング、配置される機能のコレクションです。管理対象のタイプとリソースはすべて、その実装単位内でのみアクセス可能なものとして、または実装単位外のコードによってアクセス可能なものとして示されます。

アセンブリは自己記述型で、アセンブリに不可欠な部分であるマニフェストで記述されます。マニフェストは、次のことを行います。

  • アセンブリの身元(テキストによる名前の形式)、バージョン、文化、デジタル署名(アセンブリがアプリケーション間で共有される場合)を設定します。

  • アセンブリのインプリメンテーションを構成するファイルを(名前とファイル ハッシュで)定義します。

  • アセンブリを構成するタイプとリソースを指定します。アセンブリからエクスポートされるものも指定します。

  • コンパイル時間のうち、他のアセンブリに関係する部分を個別に示します。

  • アセンブリを適切に実行するために必要なパーミッションのセットを指定します。

ランタイムにこの情報を使って、参照の解決、バージョン バインディング ポリシーの適用、ロードされたアセンブリの整合性の検証が行われます。すべてのタイプがアセンブリのコンテキストにロードされるため、ランタイムにおいて実行オブジェクトのアセンブリを特定し、見つけることができます。アセンブリは、コード アクセス セキュリティのパーミッションが適用される単位でもあります。各アセンブリの身元の証明は、アセンブリに含まれるコードに付与するパーミッションを決定するときに、個別に検討されます。

アセンブリの自己記述的な性質は、ゼロインパクトのインストールと XCOPY による配置を実現するためにも役立ちます。

プライベート アセンブリと共有アセンブリとは何ですか?

プライベート アセンブリは、1 つのアプリケーションにのみ使用され、そのアプリケーションのインストール ディレクトリ(または、そのサブディレクトリ)に格納されます。共有アセンブリは、複数のアプリケーションから参照できるものです。アセンブリを共有するには、高度に暗号化された名前(共有名として参照される名前)をアセンブリに付けることによって、アセンブリを明示的に構築しなければなりません。対照的にプライベート アセンブリの名前は、それを使うアプリケーションの中で一意の名前を付けるだけで済みます。

プライベート アセンブリと共有アセンブリを区別することによって、共有という概念を明示的な決定として示します。単にプライベート アセンブリをアプリケーション ディレクトリに配置するだけで、そのアプリケーションは、構築され配置されたときに用いられたものを使った場合にのみ実行されるようになります。プライベート アセンブリへの参照は、ローカルでプライベート アプリケーション ディレクトリに対してのみ解決されます。

共有アセンブリを構築して使うのには、バージョン ポリシーを表す機能など、いくつかの理由があります。共有アセンブリには、高度に暗号化された名前が付いているため、アセンブリの作成者だけがそのアセンブリの新しいバージョンを作成するためのキーを持っていることになります。したがって、アセンブリの新バージョンを受け入れるポリシー ステートメントを作成する場合に、確実に作成者がバージョンの更新の管理と確認を行うことになります。それ以外の場合は、アセンブリの新バージョンを受け入れる必要はありません。

ローカルにインストールされたアプリケーションの場合、共有アセンブリは一般に、グローバル アセンブリ キャッシュ(.NET Framework によって維持されるアセンブリのローカル キャッシュ)に明示的にインストールされます。.NET Framework のバージョン管理機能で重要なのは、ダウンロードされたコードは、ローカルにインストールされたアプリケーションの実行に影響を与えないという点です。ダウンロードされたコードは、特別なダウンロード キャッシュに置かれ、ダウンロードされたコンポーネントの一部が共有アセンブリとして構築される場合も、マシン上でグローバルには使用できません。

出荷時に .NET Framework に含まれているクラスはすべて、共有アセンブリとして構築されています。

共有アセンブリを構築する場合、キーのペアの署名と管理のオーバーヘッドは生じますか?

共有アセンブリの構築では、暗号化キーを使用します。アセンブリの構築中は、パブリック キーだけが必ず必要になります。.NET Framework を対象とするコンパイラは、アセンブリ構築時にパブリック キーを指定するためのコマンドライン オプションを提供します(またはユーザー定義の属性を使います)。通常は、共通のパブリック キーのコピーをソース データベースに保持し、ビルドのスクリプトからこのキーを指します。アセンブリは出荷前に、対応するプライベート キーによって完全な署名を行わなければなりません。これは、SN.exe (Strong Name)という SDK ツールを使って行われます。

高度に暗号化された名前による署名では、Authenticode で用いられるような証明書はありません。これに関わる第三機関はなく、費用もかかりません。また、証明書の連鎖もありません。さらに、この名前を検証するためのオーバーヘッドが、Authenticode の場合よりも大幅に削減されます。ただし、高度に暗号化された名前では、特定の発行者を保証するようなステートメントが作成されません。高度に暗号化された名前によって、特定のアセンブリの内容が改ざんされていないことを保証できます。また、ランタイムにロードされたアセンブリが、開発したアセンブリと同じ発行者から発行されたものであることを確認できます。ただし、高度に暗号化された名前では、その発行者の身元の信頼性を示すステートメントは作成されません。

名前空間とアセンブリの名前には、どのような違いがありますか?

名前空間は、タイプに基づく論理的な命名方法です。この方法では、MyType などの単純名の後に、ドットで区切られた階層名を付けます。このような命名方法は、開発者が完全に制御するものです。たとえば、MyCompany.FileAccess.A および MyCompany.FileAccess.B というタイプは、論理的にはファイル アクセスに関連する機能を持つものと予想されるでしょう。.NET Framework では、タイプを ASP.NET アプリケーション フレームワークなどの関連機能やリモーティング機能の論理カテゴリに分類するための、階層的な命名方法を使用します。設計ツールは、開発者がコードの中でタイプをより簡単に参照できるようにするために、名前空間を利用することができます。名前空間の概念とアセンブリの概念は関係ありません。1 つのアセンブリに複数のタイプが含まれ、そのタイプの階層的な名前に別々の名前空間のルートが割り当てられており、論理的な名前空間のルートが複数のアセンブリにまたがることがあります。.NET Framework では、名前空間は設計時に論理的に命名するための仕組みであるため、アセンブリはランタイムにタイプの名前のスコープを設定します。

アプリケーションの配置と分離

.NET アプリケーションを配置するときに、どのようなオプションを使用できますか?

.NET Framework は、他に影響を与えずにアプリケーションをインストールし、XCOPY による配置ができるようにすることによって、配置を単純化します。リクエストはすべて、最初にプライベート アプリケーション ディレクトリを参照して解決されるので、ディレクトリのファイルをディスクにコピーするだけで、アプリケーションが実行できる状態になります。登録も不要です。

このシナリオは特に、Web アプリケーション、Web サービス、独立型デスクトップ アプリケーションに当てはまります。ただし、XCOPY が配布メカニズムとして不十分な場合のシナリオもあります。たとえば、アプリケーションが非公開コードをほとんど含まず、共有アセンブリが使えるかどうかに依存するものであるときや、アプリケーションをローカルにインストールしていないとき(必要に応じてダウンロードする場合)などです。こうした場合、.NET Framework は、拡張コード ダウンロード サービスを提供し、Windows Installer との統合を行います。.NET Framework によって提供されるコード ダウンロード サポートには、インクリメンタル ダウンロード、コード アクセス セキュリティ(Authenticode ダイアログはもう不要です)、アプリケーションの分離(アプリケーションのためにダウンロードされたコードは、その他のアプリケーションに影響を与えません)など、現在のプラットフォームを上回る利点があります。Windows Installer は、.NET アプリケーションに対して使用できる、もう1つの強力な配置メカニズムです。発行、アドバタイズメント、アプリケーションの修正といった Windows Installer の機能はすべて、Windows Installer 1.5 で .NET アプリケーションに対して使用できるようになります。

記述したアセンブリを複数のアプリケーションで使う場合、そのアセンブリをどこに配置すればよいですか?

複数のアプリケーションによって使用されるアセンブリ(共有アセンブリなど)は、グローバル アセンブリ キャッシュに配置します。プレリリース版および Beta 版のビルドで、次のように Alink SDK ツールに対して /i オプションを使って、キャッシュにアセンブリをインストールします。

al /i:myDll.dll

Windows Installer の将来のバージョンでは、アセンブリをグローバル アセンブリ キャッシュにインストールできるようになる予定です。

グローバル アセンブリ キャッシュにインストールされているアセンブリを確認するには、どのようにすればよいですか?

.NET Framework は、アセンブリ キャッシュを表示するための Windows シェル エクステンションと共に出荷されます。Windows Explorer で % windir%\assembly に移動すると、ビューワが起動します。

アプリケーション ドメインとは何ですか?

アプリケーション ドメイン(多くの場合、AppDomain)は、アプリケーションを分離する仮想プロセスです。同じアプリケーション スコープ(つまり、アプリケーションのエントリ ポイントで始まるオブジェクト起動シーケンス内)で作成されたオブジェクトはすべて、同じアプリケーション ドメインで作成されます。1 つのオペレーティング システムのプロセスに複数のアプリケーション ドメインが存在し得るので、負荷の少ないアプリケーション分離手段となります。

OS のプロセスは、個別のメモリ アドレス空間を持つことによって、分離を実現します。この方法は効果的ですが、高価でもあり、大規模な Web サーバーに必要とされる数には対応できません。一方、Common Language Runtime は、アプリケーション ドメイン内で実行中のコードによるメモリの使用を管理することによって、アプリケーションを分離します。つまり、Common Language Runtime はドメインの境界の外側にあるメモリにアクセスしません。タイプセーフ コードだけがこの方法で管理できることに留意してください(ランタイムは、安全でないコードがアプリケーション ドメインにロードされた場合の分離を保証することはできません)。

ガベージ コレクション

ガベージ コレクションとは何ですか?

ガベージ コレクションは、オブジェクトにアクセスできなくなったときに、コンピュータがそれを検出するメカニズムです。さらに、そのオブジェクトによって使用されていたメモリを自動的に解放します(および、ユーザーによって記述されるクリーンアップ ルーチン「finalizer」を呼び出します)。.NET によって使用されるものなど、一部のガベージ コレクタはメモリを圧縮するので、プログラムの作業セットを減らします。

非決定的なガベージ コレクションは、コードにどのような影響を与えますか?

ほとんどのプログラマは、ガベージ コレクタがあれば(およびガベージ コレクションの対象にできるオブジェクトを使用すれば)、洗練されたデータ構造を使用している場合でも、メモリの割り当ての解除や参照カウント オブジェクトを気にする必要はありません。ただし一般に、オブジェクトのメモリを解放するコードのブロックにあるシステム リソース(ファイル ハンドル、ロックなど)の割り当てを解除する場合は、コーディングのスタイルをいくらか変更しなければなりません。およびガベージ コレクタで回収されたオブジェクトによって、システム リソースを決定的に(つまり、プログラムの制御の下で)解放する方法を提供し、ガベージ コレクタが作業セットを圧縮するときにメモリを解放するように設定します。

ガベージ コレクションの対象となるヒープを使わない方法はありますか?

ランタイムをターゲットとする言語はすべて、ガベージ コレションの対象となるヒープからクラス オブジェクトを割り当てることができます。これには、割り当てを素早く行えるという利点があります。また、プログラマは各オブジェクトを明示的に「解放する」タイミングを考える必要がありません。

CLR は ValueType と呼ばれるものも提供します。ValueType はクラスのようなものですが、ValueType オブジェクトが(ヒープではなく)ランタイム スタックに割り当てられる点がクラスとは異なります。このため ValueType オブジェクトは、それが定義されているコードのプロシージャが終了したときに、自動的に回収されます。これが、C# で「structs」が動作する仕組みです。

Managed Extensions to C++ では、クラス オブジェクトが割り当てられる場所を選択できます。クラス オブジェクトは、__gc キーワードを使って管理対象のクラスとして宣言されている場合、ガベージ コレクションの対象となるヒープから割り当てられます。__gc キーワードが含まれない場合、クラス オブジェクトは通常の C++ オブジェクトのように動作し、C++ ヒープから割り当てられ、「free」メソッドによって明示的に解放されます。

ガベージ コレクションに関するその他の情報については、以下のドキュメントをご覧ください。

リモーティング

Common Language Runtime における、プロセス内通信およびプロセス間通信の仕組みは?

プロセス内通信には、1 つのアプリケーション ドメインに含まれるコンテキスト間の通信と、複数のアプリケーション ドメインにまたがった通信の 2 種類があります。同じアプリケーション ドメイン内のコンテキスト間では、プロキシがインターセプト メカニズムとして使用されます。マーシャリングやシリアル化は、行われません。アプリケーション ドメインをまたがるときは、ランタイム バイナリ プロトコルを使ってマーシャリングやシリアル化を行います。

プロセス間通信では、特定の目的に合ったプラグ可能チャネルとフォーマッタ プロトコルを使用します。

  • 開発者が soapsuds.exe ツールを使ってエンドポイントを指定して、メタデータ プロキシを生成する場合、HTTP チャネルと SOAP フォーマッタが標準で使用されます。

  • 開発者が管理対象の場所で明示的なリモーティングを行っている場合、使用するチャネルとフォーマッタを明示する必要があります。これは管理上、特定のチャネルをロードすることを目的に、構成ファイルまたは API コールによって示されます。次の中から選択できます。

    HTTP チャネル、SOAP フォーマッタを使用(HTTP はインターネットで効果的に機能します。また、トラフィックは常にファイアウォールを通過しなければなりません)。

    TCP チャネル、バイナリ フォーマッタを使用(TCP はローカルエリア ネットワーク(LAN)で使用するのに適しています)。

    SMTP チャネル、SOAP フォーマッタを使用(マシン間でのみ適用できます)。

管理コードと非管理コードを切り替えるときに、COM インフラストラクチャ(特に DCOM)は、リモーティングに使用されます。CLR の仮リリース版では、これはサービス対象のコンポーネント(COM+ サービスを使用するコンポーネント)にも適用されます。最終リリース版では、リモーティング可能なコンポーネントを構成できるようになる見込みです。

オブジェクトの分散型ガベージ コレクションは、「貸し出しベースのライフタイム」システムによって管理されます。各オブジェクトには、貸し出し時間が設定されており、この期限が切れると、オブジェクトと CLR のリモーティング インフラストラクチャとの接続が切断されます。オブジェクトには、標準の更新時間が設定されています。クライアントからオブジェクトに対して行われた呼び出しが成功したときに、貸し出しが更新されます。クライアントが、貸し出しを明示的に更新することもできます。

相互運用性

.NET Framework プログラムから COM オブジェクトを使用できますか?

はい。現在配置されている COM コンポーネントはすべて、管理コードから使用できます。通常、この適用は完全に自動的に行われます。

具体的には、COM コンポーネントは Runtime Callable Wrapper (RCW)によって .NET Framework からアクセスされます。RCW は、COM コンポーネントによって公開される COM インターフェイスを、.NET Framework 対応のインターフェイスに変換します。OLE 自動化インターフェイスの場合、RCW はタイプ ライブラリから自動的に生成することができます。OLE 自動化インターフェイス以外の場合、開発者はユーザー定義の RCW を記述し、COM インターフェイスによって公開されるタイプを、.NET Framework 対応のタイプに手作業で割り当てることができます。

.NET Framework コンポーネントは COM プログラムから使用できますか?

はい。現在構築中の管理対象のタイプは、COM からアクセスできるように作成でき、通常、その構成はすべて自動的に行われます。管理対象の開発環境の新機能には、COM からアクセスできないものもあります。たとえば、静的なメソッドとパラメータ化されたコンストラクタは COM から使用できません。普通は、特定のタイプを利用するユーザーを事前に決めておくとよいでしょう。このタイプが COM から使用される場合、COM にアクセス可能な機能しか使えなくなることがあります。

管理対象のタイプを記述する言語によって、標準で可視の場合とそうでない場合があります。

具体的には、.NET Framework のコンポーネントは COM Callable Wrapper (CCW)によって COM からアクセスされます。これは RCW と似ていますが(前の質問をご覧ください)、逆方向で機能します。この場合も、.NET Framework の開発ツールが CCW を自動的に生成できないときや、自動的に行われる動作が必要なものでないときは、ユーザー定義の CCW を開発できます。

.NET Framework プログラムから Win32 API を使用できますか?

はい。.NET Framework のプログラムは、P/Invoke を使って、静的な DLL エントリ ポイントによってネイティブ コードのライブラリにアクセスできます。

C# で Win32MessageBox関数を呼び出す例を、以下に示します。


using System; 
using System.Runtime.InteropServices; 

class MainApp 
{ 
  [DllImport("user32.dll", EntryPoint="MessageBox")] 
  public static extern int MessageBox(int hWnd, String strMessage, String strCaption, uint uiType); 

  public static void Main() 
  { 
    MessageBox(0, "Hello, this is PInvoke in operation!", ".NET", 0); 
  } 
}
セキュリティ

コードとセキュリティ システムを連携させるには、どうすればよいですか?

通常は、何もする必要はありません。ほとんどのアプリケーションは安全に実行され、悪意のある攻撃に利用されることはないでしょう。標準のクラス ライブラリを使うか、リソース(ファイルなど)へのアクセスや、保護された操作(タイプのプライベート メンバへのリフレクションなど)を行うだけで、これらのライブラリによってセキュリティが適用されます。アプリケーション開発者は、コードが受け取るパーミッションを(必要なものだけに)制限するために、パーミッションのリクエスト(宣言型のセキュリティの形式)を簡単に指定することもできます。また、これによって、実行が許可されたコードは必要なパーミッションをすべて使用して実行されます。

セキュリティ システムを直接使用する必要があるのは、新しい種類のリソースを公開する、新しいベース クラスのライブラリを記述している開発者だけです。コード全体が危険にさらされることがないように、コード アクセス セキュリティが、明示的にセキュリティ システムに優先する、非常に小さなコードにのみアクセスできるように制限します。

ネットワークの共有ドライブからコードを実行するときに、セキュリティの例外が発生するのはなぜですか?

標準のセキュリティ ポリシーは、ローカル イントラネット ゾーンからのコードに対して、制限されたパーミッションのセットのみを付与します。このゾーンは、Internet Explorer のセキュリティ設定で定義し、企業内のローカル ネットワークに合わせて設定しなければなりません。UNC または割り当てられたドライブ(NET USE コマンドなどで)によって命名されたファイルは、このローカル ネットワーク上で送信されているので、ローカル インターネット ゾーンにあるともいえます。

標準値は、安全が保証されていない最悪のイントラネットを想定して設定されています。イントラネットが安全なものであれば、セキュリティ ポリシーを(CASPol ツールを使って)変更し、ローカル イントラネットまたはその一部(特定のマシンの共有名など)に対して、より多くのパーミッションを付与することができます。

セキュリティ システムによって実行が制限されているコードを実行するには、どのようにすればよいですか?

コードが、パーミッションを付与されていないアクションを実行しようとすると、セキュリティの例外が発生します。パーミッションは、コードについて認識されている情報(特に、その場所)に基づいて付与されます。たとえば、インターネットから実行されるコードとローカル マシンから実行されるコードとでは、前者に付与されるパーミッションのほうが少なくなります。これは、経験から、一般的に前者のほうが信頼性が低いことが分かっているためです。このため、セキュリティの例外が発生したことが原因で実行できないコードを実行するには、そのコードに付与されているパーミッションを増やす必要があります。これを行う簡単な方法としては、信頼性の高い場所(ローカル ファイル システムなど)にコードを移動する方法があります。しかし、この方法が必ずうまくいくとは限りません(Web アプリケーションでは有効ですが、企業のネットワークにあるイントラネット アプリケーションでは無効です)。したがって、コードの場所を変更する代わりに、その場所に対してさらにパーミッションを付与するようにセキュリティ ポリシーを変更することもできます。これを行うには、コード アクセス セキュリティ ポリシー ユーティリティ(caspol.exe)、またはグラフィカル管理ツール(Beta 2 以降で提供)を使用します。コードの開発者または発行者であれば、そのコードにデジタル署名を行ってから、その署名を有するコードに対してさらにパーミッションを付与するようにセキュリティ ポリシーを変更することもできます。ただし、これらを行う場合、コードにわずかなパーミッションしか付与されていないのは、コードの身元が確認できず信頼できないためであることを忘れないでください。ローカル マシンへのコードの移動や、セキュリティ ポリシーの変更は、コードが悪意のあるアクションや有害なアクションを取らないと確信できる場合にのみ行ってください。

自分のマシンのセキュリティはどのように管理すればよいですか?また、企業の場合はどうですか?

現在は、CASPol コマンドライン ツールが、セキュリティ管理に使用できる唯一の方法といえます。セキュリティ ポリシーは、マシンとユーザーごとの 2 つのレベルで構成されています。.NET Framework の最初のバージョンの一部として、すべての機能を備えた管理ツールと、企業のポリシー管理のサポートを提供する予定です。

証拠に基づくセキュリティは、Windows 2000 のセキュリティとどのように連携するのですか?

証拠に基づくセキュリティ(コードを承認するもの)は、Windows 2000 のセキュリティ(ログオン ID に基づくもの)と連携します。たとえば、ファイルにアクセスするには、管理コードにコード アクセス セキュリティ ファイルのパーミッションが付与されており、NTFS ファイル アクセス権を持つログオン ID の下で、このコードが実行されていなければなりません。.NET Framework に含まれる管理対象のライブラリは、ロールに基づくセキュリティ用にクラスも提供します。これによって、アプリケーションが Windows のログオン ID およびユーザー グループと連携できるようになります。

表示:
© 2014 Microsoft