Microsoft Corporation
2001 年 7 月
要約: このドキュメントには、Microsoft .NET と Microsoft .NET Framework に関してよく寄せられる質問とその答えが含まれています。
目次
概念的な質問
.NET Framework とは何ですか?
ランタイムに関する技術的な質問
用語
共通言語ランタイム (CLR) とは?
共通型システム (CLS) とは?
共通言語仕様 (CTS) とは?
Microsoft Intermediate Language (MSIL) とは?
マネージド コードとマネージド データとは?
アセンブリ
アセンブリとは?
プライベート アセンブリと共有アセンブリとは?
共有アセンブリを作成する場合、署名と、キーのペアの管理を行う必要はありますか?
名前空間とアセンブリ名の違いは?
アプリケーションの導入と隔離
.NET アプリケーションの導入オプションは?
作成したアセンブリを複数のアプリケーションで使用したいと考えています。どこに導入するべきですか?
グローバル アセンブリ キャッシュにどのアセンブリがインストールされているかを確認する方法は?
アプリケーション ドメインとは?
ガーベジ コレクション
ガーベジ コレクションとは?
非決定的ガーベジ コレクションはコードにどのような影響を与えますか?
ガーベジ コレクションが行われるヒープの使用を避けることはできますか?
リモーティング
共通言語ランタイムでは、プロセス内通信とプロセス間通信はどのように行われますか?
相互運用性
.NET Framework プログラムから COM オブジェクトを使用することはできますか?
COM プログラムから .NET Framework コンポーネントを使用することはできますか?
.NET Framework プログラムから Win32 API を使用することはできますか?
セキュリティ
セキュリティ システムに対応したコードを作成する方法は?
コードをネットワーク共有ドライブから実行するとセキュリティ例外が発生するのはなぜですか?
セキュリティ システムが実行を停止するコードを正常に動作させるには?
マシンのセキュリティを管理する方法は? 企業のセキュリティを管理する方法は?
エビデンス ベース セキュリティと Windows 2000 セキュリティの関係は?
その他
.NET に対応したアプリケーションは、Visual Basic 6.0 や Visual C++ 6.0 などの以前のバージョンで作成されたアプリケーションに対して、何らかの影響をあたえますか
概念的な質問
.NET Framework とは何ですか?
Microsoft .NET Framework は、Web サービスおよびアプリケーションの構築、導入、および実行のためのプラットフォームです。既存のシステムを次世代のアプリケーションおよびサービスと統合するための生産性の高い標準ベースの複数言語環境と、インターネット スケールのアプリケーションの導入と運用に関連する問題を解決するための敏捷性を備えています。.NET Framework は、共通言語ランタイム、階層的な統一されたクラス ライブラリのセット、および Active Server Pages のコンポーネント化されたバージョンである ASP.NET の 3 つの部分から構成されています。
目次に戻る
ランタイムに関する技術的な質問
用語
共通言語ランタイム (CLR) とは?
共通言語ランタイムは、.NET Framework アプリケーションのための実行エンジンです。
これは以下のようなサービスを提供しています。
- コード管理 (ロードと実行)
- アプリケーション メモリの隔離
- タイプ セーフティの検証
- IL からネイティブ コードへの変換
- メタデータへのアクセス (拡張された型情報)
- マネージド オブジェクトのメモリの管理
- コード アクセス セキュリティの実施
- クロス言語例外を含む例外処理
- マネージド コード、COM オブジェクト、および既存の DLL (アンマネージドのコードとデータ) の間の相互運用
- オブジェクト レイアウトのオートメーション
- 開発者サービスのサポート (プロファイリング、デバッグなど)
目次に戻る
共通型システム (CTS) とは?
共通型システムは、大部分のプログラミング言語に含まれている型と操作をサポートする、共通言語ランタイムに組み込まれたリッチな型システムです。共通型システムは、幅広いプログラミング言語のインプリメンテーションを完全にサポートしています。
目次に戻る
共通言語仕様 (CLS) とは?
共通言語仕様は、ライブラリ作成者とコンパイラ作成者のためのガイドの役割を果たす言語要素と制約条件のセットです。CLS をサポートしている任意の言語からライブラリを使用できるようになり、またこれらの言語を互いに統合することができます。共通言語仕様は共通型システムのサブセットです。また、共通言語仕様は、他の開発者によって使用されるコードを書いているアプリケーション開発者にとっても重要です。CLS の規則に従ってパブリックにアクセス可能な API を設計することにより、これらの API は共通言語ランタイムをターゲットとしている他のすべてのプログラミング言語から簡単に使用できるようになります。
目次に戻る
Microsoft Intermediate Language (MSIL) とは?
MSIL は、.NET Framework プログラムをコンパイルしたときに生成される CPU に依存しない命令セットです。オブジェクトのロード、格納、初期化、およびそのメソッドの呼び出しのための命令が含まれています。
MSIL をメタデータおよび共通型システムと組み合わせることにより、真の言語間統合が可能となります。
MSIL は実行の前にマシン コードに変換されます。インタープリタによって実行されるわけではありません。
目次に戻る
マネージド コードとマネージド データとは?
マネージド コードとは、共通言語ランタイムのサービスをターゲットとして書かれたコードのことです (「共通言語ランタイムとは?」を参照)。これらのサービスをターゲットとするには、コードはランタイムに対して最低限の情報 (メタデータ) を提供しなくてはなりません。C#、Visual Basic .NET、および JScript .NET のすべてのコードは、デフォルトでマネージドとなります。Visual Studio .NET C++ のコードは、デフォルトではマネージド コードにはなりませんが、コンパイラはコマンド ライン スイッチ (/CLR) を指定することでマネージド コードを生成することができます。
なぜ貴金属を購入する
マネージド コードと深く関係しているのがマネージド データです。これは、共通言語ランタイムのガーベジ コレクタによって割り当てと解放が行われるデータです。C#、Visual Basic .NET、および JScript .NET のデータは、デフォルトではマネージドとなります。ただし、C# のデータは特殊なキーワードを使うことでアンマネージドとしてマークすることができます。Visual Studio .NET C++ のデータは、デフォルトでは (/CLR スイッチを使用した場合でも) アンマネージドになりますが、Managed Extensions for C++ を使用すると、__gc キーワードを使ってクラスをマネージドとしてマークすることができます。その名前が示すように、これはそのクラスのインスタンスのメモリがガーベジ コレクタによって管理されるということを意味しています。さらに、そのクラスは .NET Framework コミュニティの正式なメンバとして参加し、.NET Framework のさまざまな利点と制約が適用されるようになります。利点の例としては、他の言語で書かれたクラスとの適切な相互運用があります (たとえば、マネージド C++ クラスは Visual Basic クラスから継承を行うことができます)。制約の例としては、マネージド クラスは 1 つの基本クラスからしか継承を行えないということがあります。
目次に戻る
アセンブリ
アセンブリとは?
アセンブリとは、.NET Framework アプリケーションの基本的なビルディング ブロックです。これは 1 つのインプリメンテーション単位 (1 つまたは複数のファイル) として構築され、バージョン化され、導入される機能のコレクションです。すべてのマネージド型とリソースは、そのインプリメンテーション単位の中でのみアクセス可能か、その単位の外のコードからアクセス可能としてマークされます。
アセンブリは、すべてのアセンブリに含まれるマニフェストによって自己記述を行います。マニフェストには以下の機能があります。
- アセンブリのアイデンティティ (テキスト名の形式)、バージョン、カルチャー、およびデジタル署名 (アセンブリを複数のアプリケーションで共有する場合) を確立します。
- アセンブリのインプリメンテーションを構成するファイルを (名前とファイル ハッシュによって) 定義します。
- アセンブリを構成する型とリソースを指定します。また、どの型とリソースがアセンブリからエクスポートされるかも指定します。
- 他のアセンブリに対するコンパイル時の依存関係を列挙します。
- アセンブリが正常に動作するために必要な権限のセットを指定します。
この情報は、実行時に、参照の解決、バージョン バインディング ポリシーの実施、およびロードされたアセンブリの整合性の確認に使用されます。すべての型はいずれかのアセンブリのコンテキストの中でロードされるので、ランタイムは任意の実行中のオブジェクトのアセンブリを決定し、探し出すことができます。また、アセンブリはコード アクセス セキュリティ権限が適用される単位でもあります。コードに与える権限を決定する際には、そこに含まれている個々のアセンブリのアイデンティティ エビデンスが考慮に入れられます。
また、アセンブリの自己記述性は、ゼロ インパクト インストールと XCOPY 導入を可能にしています。
目次に戻る
プライベート アセンブリと共有アセンブリとは?
プライベート アセンブリは 1 つのアプリケーションでのみ使用され、そのアプリケーションのインストール ディレクトリ (またはその中のサブディレクトリ) に格納されます。共有アセンブリは、複数のアプリケーションから参照することができるアセンブリです。アセンブリを共有するためには、暗号学上のストロング名 (ストロング名と呼ばれます) を与えることによって、明示的に共有用にビルドする必要があります。一方、プライベート アセンブリ名は、それを使用するアプリケーション内で一意であれば済みます。
プライベート アセンブリと共有アセンブリを区別することで、明示的な決定としての共有という概念が新たに導入されています。単にアプリケーション ディレクトリにプライベート アセンブリを導入すれば、そのアプリケーションは最初から組み合わせて使用されることを前提として作成され、導入されたコードのみを使って実行されることが保証されます。プライベート アセンブリはプライベート アプリケーション ディレクトリに対してのみローカルに解決されます。
共有アセンブリを作成し、使用する理由はいくつか考えられますが、その中にバージョン ポリシーの表現があります。共有アセンブリは暗号学上のストロング名を持つため、そのアセンブリの新バージョンを生成するためのキーは、アセンブリの作者のみが持っています。このため、アセンブリの新バージョンを受け付けるというポリシー ステートメントを作成した場合には、バージョン アップデートが作成者によって制御され、検証されるという保証を得ることができます。そのアップデートが作成者によるものでなければ、受け付ける必要はありません。
ローカルにインストールされるアプリケーションの場合、共有アセンブリは一般にグローバル アセンブリ キャッシュ (.NET Framework によって保守されるローカルなアセンブリ キャッシュ) に明示的にインストールされます。.NET Framework のバージョン管理機能の鍵となるのは、ダウンロードされたコードが、ローカルにインストールされているアプリケーションの実行に影響を与えないということです。ダウンロードされたコードは特殊なダウンロード キャッシュに格納され、ダウンロードされたコンポーネントが共有アセンブリとして作成されている場合でも、マシン上でグローバルに使用可能とはなりません。
.NET Framework に付属するクラスは共有アセンブリとして作成されています。
目次に戻る
共有アセンブリを作成する場合、署名と、キーのペアの管理を行う必要はありますか?
共有アセンブリを作成するためには、暗号キーを扱う必要があります。アセンブリの作成時に必要なのは、厳密にはパブリック キーだけです。.NET Framework をターゲットとするコンパイラは、アセンブリの作成時にパブリック キーを指定するためのコマンド ライン オプションを持っています (またはカスタム属性を使用します)。共通パブリック キーをソース データベースに入れておいて、ビルド スクリプトでこのキーをポイントするという方法はよく使われます。アセンブリを出荷する前に、対応するプライベート キーでアセンブリに完全な署名を行う必要があります。これは SDK の SN.exe (Strong Name) というツールによって行います。
なぜ営業？
ストロング名署名では、Authenticode のように証明書は使用されません。サードパーティ組織は関与せず、使用料を払う必要はなく、証明書のチェーンを考慮する必要もありません。さらに、ストロング名を検証するためのオーバーヘッドは Authenticode よりもはるかに小さくなっています。ただし、ストロング名は特定のパブリシャの信頼性については何の情報ももたらしません。ストロング名は、特定のアセンブリの内容が改ざんされていないこと、また実行時にロードされたアセンブリが、開発時に使用していたアセンブリと同じパブリシャを出所としていることを保証するだけです。そのパブリシャのアイデンティティを信頼できるかどうかについては、何の情報も提供しません。
目次に戻る
名前空間とアセンブリ名の違いは?
名前空間は、MyType などの単純な型名の前に、ドットで区切った階層的な名前が与えられる、型のための論理的な命名方式です。このような命名方式は、開発者の完全な管理下にあります。たとえば、MyCompany.FileAccess.A と MyCompany.FileAccess.B は、ファイル アクセスに関連する機能を持つという論理的な推論が可能です。.NET Framework は、ASP.NET アプリケーション フレームワークやリモーティング機能など、互いに関連する機能の論理的なカテゴリに型をグループ化するために、階層的な命名方式を使用しています。デザイン ツールは名前空間を利用して、開発者がコード内の型を簡単にブラウズし、参照できるようにすることができます。名前空間の概念はアセンブリの概念とは関係ありません。1 つのアセンブリは、階層名が異なる名前空間ルートを持つ複数の型を含むことができますし、1 つの名前空間ルートは複数のアセンブリにまたがることができます。.NET Framework では、名前空間はデザイン時の名前の指定を簡単にするための論理的な仕組みであり、アセンブリは実行時に型の名前のスコープを決定するものとして位置づけられています。
目次に戻る
アプリケーションの導入と隔離
.NET アプリケーションの導入オプションは?
.NET Framework は、アプリケーションのゼロ インパクト インストールと XCOPY 導入を可能にすることで、導入を単純化しています。すべての要求はまずプライベート アプリケーション ディレクトリに対して解決されるため、アプリケーションのディレクトリ ファイルをディスクにコピーするだけで、アプリケーションの実行準備が整います。登録を行う必要はありません。
このシナリオは、Web アプリケーション、Web サービス、および自己完結的なデスクトップ アプリケーションに特に魅力的です。しかし、XCOPY が配布メカニズムとしては不十分なシナリオもあります。たとえば、アプリケーションがプライベート コードをほとんど含んでおらず、共有アセンブリに依存している場合や、アプリケーションがローカルにインストールされない場合 (オンデマンドでのダウンロード) などです。このようなケースのために、.NET Framework は高度なコード ダウンロード サービスと、Windows インストーラとの統合機能を提供しています。.NET Framework のコード ダウンロード サービスは、インクリメンタル ダウンロード、コード アクセス セキュリティ (Authenticode ダイアログは表示されません)、アプリケーションの隔離 (1 つのアプリケーションのためにダウンロードされたコードは他のアプリケーションに影響を与えない) などを含めて、現行のプラットフォームと比べていくつかの点で改善されています。Windows インストーラは、.NET アプリケーションが利用できるもう 1 つの強力な導入メカニズムです。Windows インストーラ 2.0 では、発行、アドバタイズ、およびアプリケーション修復を含む Windows インストーラのすべての機能が、.NET アプリケーションから利用できるようになります。
目次に戻る
作成したアセンブリを複数のアプリケーションで使用したいと考えています。どこに導入するべきですか?
複数のアプリケーションから使用されるアセンブリ (共有アセンブリなど) は、グローバル アセンブリ キャッシュに導入されます。プレリリースおよびベータ ビルドでは、SDK の GACUtil ツールの/i オプションを使用して、アセンブリをキャッシュにインストールします。
Windows XP と Visual Studio .NET に付属する Windows インストーラ 2.0 は、アセンブリをグローバル アセンブリ キャッシュにインストールすることができます。
目次に戻る
グローバル アセンブリ キャッシュにどのアセンブリがインストールされているかを確認する方法は?
.NET Framework には、アセンブリ キャッシュを表示するための Windows シェル エクステンションが付属します。Windows エクスプローラで % windir%\assembly に移動すると、ビューアが起動されます。
目次に戻る
アプリケーション ドメインとは?
アプリケーション ドメイン (AppDomain と表記することがあります) は、アプリケーションを隔離する役割を果たす仮想プロセスです。同じアプリケーション スコープ内で (言い換えると、アプリケーションのエントリ ポイントから始まるオブジェクト アクティベーションのシーケンスの中の任意のポイントで) 作成されたすべてのオブジェクトは、同じアプリケーション ドメイン内に作成されます。1 つのオペレーティング システム プロセス内に複数のアプリケーション ドメインが存在することができるため、アプリケーションを隔離するための低コストの手段として利用できます。
OS プロセスは、互いに独立したメモリ アドレス空間を持つことで隔離を行います。これは効果的ですが、コストが高く、大規模な Web サーバーに必要な数に対応できるだけのスケーラビリティは持っていません。一方、共通言語ランタイムはアプリケーション ドメイン内で実行されるコードが使用するメモリを管理することで、アプリケーションの隔離を行います。これにより、アプリケーションはドメインの外のメモリにはアクセスできなくなります。この方法で管理できるのはタイプ セーフなコードだけであることに注意してください (ランタイムは、アプリケーション ドメインにアンセーフなコードがロードされた場合には、隔離を保証することはできません)。
目次に戻る
ガーベジ コレクション
ガーベジ コレクションとは?
ガーベジ コレクションとは、特定のオブジェクトがアクセスされなくなったことをコンピュータが検出できるようにするメカニズムです。その後、そのオブジェクトが使用していたメモリは自動的に解放されます (また、ユーザー作成の「ファイナライザ」と呼ばれるクリーンアップ ルーチンが呼び出されます)。一部のガーベジ コレクタは、.NET が使用しているものを含めて、メモリの圧縮を行い、プログラムのワーキング セットを縮小します。
目次に戻る
どのような安全sihns意味
非決定的ガーベジ コレクションはコードにどのような影響を与えますか?
ほとんどのプログラマにとって、ガーベジ コレクタを持つ (およびガーベジ コレクションが行われるオブジェクトを使用する) ということは、高度なデータ構造を使用する場合でも、メモリの解放やオブジェクトの参照カウンティングを行う必要がなくなるということを意味しています。ただし、オブジェクトのメモリを解放するのと同じコード ブロックでシステム リソース (ファイル ハンドルやロックなど) を解放している場合には、コーディング スタイルをいくぶん変更する必要があります。ガーベジ コレクションが行われるオブジェクトでは、システム リソースを決定論的に (つまりプログラムの制御下で) 解放するメソッドを用意しておき、ワーキング セットの圧縮の際にガーベジ コレクタにメモリを解放させる必要があります。
目次に戻る
ガーベジ コレクションが行われるヒープの使用を避けることはできますか?
ランタイムをターゲットとするすべての言語では、ガーベジ コレクションが行われるヒープからクラス オブジェクトを割り当てることができます。これにより、割り当てが高速化され、プログラマは個々のオブジェクトをいつ明示的に「解放」すればよいのかを心配せずに済みます。
また、CLR は ValueType と呼ばれるものも用意しています。ValueType オブジェクトはクラスに似ていますが、(ヒープ上ではなく) ランタイム スタック上に割り当てられるため、それらが定義されているプロシージャが終了すると自動的に解放されます。C# の構造体はこの手法を使用しています。
Managed Extensions for C++ では、クラス オブジェクトの割り当て場所を選択することができます。__gc キーワードによってマネージド クラスとして宣言された場合には、ガーベジ コレクションが行われるヒープから割り当てられます。__gc キーワードが指定されなければ、通常の C++ オブジェクトと同じように C++ ヒープから割り当てられ、"free" メソッドによって明示的に解放されます。
ガーベジ コレクションの詳細については、以下を参照してください。
目次に戻る
リモーティング
共通言語ランタイムでは、プロセス内通信とプロセス間通信はどのように行われますか?
プロセス内通信には、1 つのアプリケーション ドメイン内のコンテキスト間と、アプリケーション ドメイン間の 2 つの側面があります。同じアプリケーション ドメイン内のコンテキスト間では、プロキシがインターセプション メカニズムとして使用されます。マーシャリング／シリアル化は行われません。複数のアプリケーション ドメインの間では、ランタイム バイナリ プロトコルを使用してマーシャリング／シリアル化が行われます。
プロセス間通信は、それぞれ特定の用途に適したプラガブル チャネルとフォーマッタ プロトコルが使用されます。
- 開発者が soapsuds.exe ツールを使ってエンドポイントを指定し、メタデータ プロキシを生成する場合には、HTTP チャネルと SOAP フォーマッタがデフォルトとなります。
- 開発者がマネージドの世界で明示的なリモーティングを行う場合は、使用するチャネルとフォーマッタを明示的に指定する必要があります。これは構成ファイルを通して管理することもできますし、特定のチャネルをロードする API 呼び出しを使って指定することもできます。以下の選択肢があります。
HTTP チャネルと SOAP フォーマッタ (HTTP はインターネット上で、またトラフィックがファイヤウォールを通らなくてはならないときに有効です)
TCP チャネルとバイナリ フォーマッタ (ローカル エリア ネットワーク (LAN) では、TCP の方が高性能です)
マネージド コードとアンマネージド コードの間で移行するときには、COM インフラストラクチャ (具体的には DCOM) がリモーティングに使用されます。CLR の暫定リリースでは、これはサービスド コンポーネント (COM+ サービスを使用するコンポーネント) にも適用されます。最終リリースでは、任意のリモータブル コンポーネントを構成できるようになる予定です。
オブジェクトの分散ガーベジ コレクションは、「リース ベース ライフタイム」と呼ばれるシステムによって管理されます。個々のオブジェクトはリース期間を持っており、その期間が終了すると、オブジェクトは CLR のリモーティング インフラストラクチャから切り離されます。オブジェクトはデフォルトの更新期間を持っています。リースは、クライアントからオブジェクトへの呼び出しが成功するたびに更新されます。また、クライアントはリースを明示的に更新することができます。
目次に戻る
相互運用性
.NET Framework プログラムから COM オブジェクトを使用することはできますか?
はい。これまでに開発したすべての COM コンポーネントをマネージド コードから使用することができ、その対応は通常は完全に自動的に行われます。
具体的に述べると、COM コンポーネントを .NET Framework からアクセスする際には、ランタイム呼び出し可能ラッパー (RCW) が使用されます。このラッパーは、COM コンポーネントが公開している COM インターフェイスを、.NET Framework 互換のインターフェイスに変換します。OLE オートメーション インターフェイスについては、RCW をタイプ ライブラリから自動生成することができます。非 OLE オートメーション インターフェイスについては、開発者はカスタム RCW を作成し、COM インターフェイスが公開している型を .NET Framework 互換の型に手動でマッピングすることができます。
目次に戻る
COM プログラムから .NET Framework コンポーネントを使用することはできますか?
はい。いま開発しているマネージド型は COM からアクセス可能にすることができ、その構成は通常は完全に自動的に行われます。マネージド開発環境には、COM からはアクセスできないいくつかの新機能があります。たとえば、スタティック メソッドとパラメータ付きコンストラクタは COM から使用することができません。一般には、個々の型のユーザーを事前に想定しておくことが勧められます。型が COM から使用される場合には、COM からのアクセスが可能な機能だけを使用するようにします。
型がデフォルトでアクセス可能になるかどうかは、マネージド型の作成に使用された言語によって異なります。
具体的に述べると、.NET Framework コンポーネントを COM からアクセスする際には、COM 呼び出し可能ラッパー (CCW) が使用されます。これは RCW に似ていますが (前の項を参照)、その反対向きに作用します。.NET Framework 開発ツールがラッパーを自動生成できない場合、または自動生成される振る舞いが希望のものと異なる場合には、やはりカスタム CCW を開発することができます。
目次に戻る
.NET Framework プログラムから Win32 API を使用することはできますか?
はい。.NET Framework プログラムは、プラットフォーム呼び出しを使用することで、スタティック DLL エントリ ポイントを通してネイティブ コード ライブラリにアクセスすることができます。
次に、C# から Win32 MessageBox 関数を呼び出す例を示します。
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 ); } } 目次に戻る
セキュリティ
セキュリティ システムに対応したコードを作成する方法は?
通常は、何も行う必要はありません。大部分のアプリケーションは安全に動作し、悪意のある攻撃から守られます。リソース (ファイルなど) へのアクセスに標準クラス ライブラリを使用したり、保護された操作 (型のプライベート メンバのリフレクションなど) を実行するだけで、これらのライブラリがセキュリティを確保してくれます。アプリケーション開発者が行うべき簡単な処理の 1 つに、自分のコードが受け取る権限を、必要なものだけに制限する権限要求 (宣言型セキュリティの一種) を含めるということがあります。これにより、コードの実行が許可されたときには、そのコードに必要なすべての権限が得られた状態で実行されることが保証されます。
セキュリティ システムを直接扱わなくてはならないのは、新しい種類のリソースを公開する新しい基本クラス ライブラリを作成する開発者だけです。コード アクセス セキュリティは、すべてのコードが潜在的なセキュリティ リスクになるという状況を解消し、セキュリティ システムを明示的にオーバーライドするごく一部のコードのみにリスクを限定します。
目次に戻る
コードをネットワーク共有ドライブから実行するとセキュリティ例外が発生するのはなぜですか?
デフォルトのセキュリティ ポリシーは、ローカル イントラネット ゾーンを出所とするコードに、限定された権限のセットのみを与えます。このゾーンは Internet Explorer のセキュリティ設定によって定義されるもので、企業のローカル ネットワークの状況に合わせて構成されなくてはなりません。UNC またはドライブ マッピング (NET USE コマンドなど) によって指定されるファイルはこのローカル ネットワーク経由で送信されるため、ローカル イントラネット ゾーンに分類されます。
デフォルト設定では、セキュリティが確保されていないイントラネットの最悪のケースが想定されています。イントラネットのセキュリティが確保されている場合には、(.NET Framework の構成ツールか CASPol ツールを使って) セキュリティ ポリシーを変更し、ローカル イントラネットかその一部 (特定のマシン共有ディレクトリ名など) に高度な権限を与えることができます。
目次に戻る
セキュリティ システムが実行を停止するコードを正常に動作させるには?
セキュリティ例外は、コードが、権限が与えられていないアクションを実行しようと試みたときに発生します。権限は、コードについてわかっている事実、特にその位置に基づいて与えられます。たとえば、インターネットから実行されるコードには、ローカル マシンから実行されるコードよりも少ない権限しか与えられません。これは経験上、インターネットから実行されるコードは一般に信頼性が低いことが実証されているためです。したがって、セキュリティ例外のせいで実行に失敗するコードを正常に動作させるためには、そのコードに与えられる権限を増やさなくてはなりません。簡単な方法としては、コードをより信頼の置かれている位置 (ローカル ファイル システムなど) に移動するというものがあります。しかし、この方法はすべてのケースで使用できるわけではありません (Web アプリケーションや、企業ネットワーク上のイントラネット アプリケーションなどがこれに該当します)。その場合には、コードの位置を変える代わりに、セキュリティ ポリシーの方を変更して、その位置により高度な権限を与えることができます。これは、.NET Framework の構成ツールか、コード アクセス セキュリティ ポリシー ユーティリティ (caspol.exe) を使って行います。また、コードの開発者またはパブリシャは、コードにデジタル署名を付けておき、その署名を持つコードに高度な権限を与えるようセキュリティ ポリシーを変更することもできます。ただしこれらのアクションを実行するときには、コードに少ない権限しか与えられていないのは、それが信頼の置ける出所からのものでないからということを忘れないでください。コードをローカル マシンに移動したり、セキュリティ ポリシーを変更する前に、そのコードが悪意のある、またはダメージを与えるような操作を実行しないことを確認してください。
目次に戻る
マシンのセキュリティを管理する方法は? 企業のセキュリティを管理する方法は?
.NET Framework には、セキュリティ ポリシーを含む CLR のいくつかの側面を構成するための .NET Framework 構成ツール、MMC スナップイン (mscorcfg.msc) が付属しています。このスナップインは、ローカル マシン上のセキュリティ ポリシーの管理をサポートするだけでなく、Systems Management Server とグループ ポリシーとの互換性を持つエンタープライズ ポリシー導入パッケージも作成します。また、コマンド ライン ユーティリティの CASPol.exe を使うと、コンピュータ上のポリシーをスクリプティングによって変更することができます。これらのツールを実行するには、コマンド プロンプトでカレント ディレクトリを .NET Framework のインストール ディレクトリ (%windir%\Microsoft.Net\Framework\v1.0.2914.16\) に変更し、mscorcfg.msc または caspol.exe と入力します。
目次に戻る
エビデンス ベース セキュリティと Windows 2000 セキュリティの関係は?
(コードの承認を行う) エビデンス ベース セキュリティは、(ログオン アイデンティティをベースにした) Windows 2000 セキュリティと連係して動作します。たとえば、マネージド コードがファイルにアクセスするためには、コード アクセス セキュリティ ファイル権限を持つと同時に、NTFS ファイル アクセス権を持つログオン アイデンティティの下で実行されていなくてはなりません。また、.NET Framework に含まれているマネージド ライブラリは、ロール ベース セキュリティのためのクラスを提供しています。これらのクラスにより、アプリケーションは Windows ログオン アイデンティティおよびユーザー グループを扱うことができます。
目次に戻る
その他
.NET に対応したアプリケーションは、Visual Basic 6.0 や Visual C++ 6.0 などの以前のバージョンで作成されたアプリケーションに対して、何らかの影響をあたえますか
いいえ、.NET アプリケーションは、以前のバージョンで作成されたアプリケーションへ影響をあたえません。これは、.NET のランタイム ライブラリや実行エンジンが、Visual Basic ランタイムや MFC ランタイム ライブラリと完全に独立しているためです。
目次に戻る
0 件のコメント:
コメントを投稿