diff --git a/docs/standard/application-essentials.md b/docs/standard/application-essentials.md index f593685d3aa..15fdc379bb0 100644 --- a/docs/standard/application-essentials.md +++ b/docs/standard/application-essentials.md @@ -1,24 +1,28 @@ --- -title: ".NET Framework アプリケーションの基本事項 | Microsoft Docs" -ms.custom: "" -ms.date: "03/30/2017" -ms.prod: ".net" -ms.reviewer: "" -ms.suite: "" -ms.technology: - - "dotnet-standard" -ms.tgt_pltfrm: "" -ms.topic: "article" -helpviewer_keywords: - - ".NET Framework の開発" +title: ".NET Framework アプリケーションの基本事項" +ms.custom: +ms.date: 03/30/2017 +ms.prod: .net +ms.reviewer: +ms.suite: +ms.technology: dotnet-standard +ms.tgt_pltfrm: +ms.topic: article +helpviewer_keywords: +- .NET Framework development ms.assetid: 653da4ba-3752-4d1f-a08a-de017dc86ecc caps.latest.revision: 19 -author: "rpetrusha" -ms.author: "ronpet" -manager: "wpickett" -caps.handback.revision: 19 +author: rpetrusha +ms.author: ronpet +manager: wpickett +ms.translationtype: HT +ms.sourcegitcommit: 318bf7a77748dfcee5f28243409d31e8d3e5c9ff +ms.openlocfilehash: 00bc12a16418038c74a5e8858a77818e66982727 +ms.contentlocale: ja-jp +ms.lasthandoff: 08/21/2017 + --- -# .NET Framework アプリケーションの基本事項 +# .NET Framework アプリケーションの基本事項 .NET Framework ドキュメントのこのセクションでは、.NET Framework での基本的なアプリケーション開発タスクに関する情報を提供します。 ## このセクションの内容 @@ -40,7 +44,7 @@ caps.handback.revision: 19 [例外](../../docs/standard/exceptions/index.md) .NET Framework が提供するエラー処理および例外処理の基本事項について説明します。 - [ファイルおよびストリームは、O](../../docs/standard/io/index.md) + [ファイルおよびストリーム入出力](../../docs/standard/io/index.md) ファイルやデータ ストリームに対する同期アクセスおよび非同期アクセスの実行方法と、分離ストレージの使用方法について説明します。 [日付、時刻、およびタイム ゾーン](../../docs/standard/datetime/index.md) @@ -49,13 +53,13 @@ caps.handback.revision: 19 [アプリケーション ドメインとアセンブリ](../../docs/framework/app-domains/index.md) アセンブリとアプリケーション ドメインの作成方法および操作方法について説明します。 - [シリアル化](../../docs/framework/serialization/index.md) + [シリアル化](../../docs/standard/serialization/index.md) オブジェクトの状態を永続化または転送できる形式に変換するプロセスについて説明します。 - [デスクトップ アプリでのリソース](../../docs/framework/resources/index.md) + [デスクトップ アプリケーションのリソース](../../docs/framework/resources/index.md) リソースを作成し格納するための .NET Framework のサポートについて説明します。 また、このセクションでは、ローカライズされたリソースに対するサポートについて説明し、それらローカライズされたリソースのパッケージ化および配置のサテライト アセンブリ リソース モデルについて説明します。 - [グローバリゼーションとローカリゼーション](../../docs/standard/globalization-localization/index.md) + [グローバライズとローカライズ](../../docs/standard/globalization-localization/index.md) 国際対応アプリケーションの設計および開発に役立つ情報を提供します。 ユーザー補助 @@ -72,4 +76,5 @@ caps.handback.revision: 19 アプリケーションの作成、構成、デバッグ、セキュリティ、配置、および動的プログラミング、相互運用性、拡張性、メモリ管理、スレッド処理に関する情報を含む、アプリケーション開発用の主要な技術領域とタスクのすべてについての手引書です。 [セキュリティ](../../docs/standard/security/index.md) - 共通言語ランタイムおよび .NET Framework において安全なアプリケーションの開発を促進するクラスおよびサービスに関する情報を提供します。 \ No newline at end of file + 共通言語ランタイムおよび .NET Framework において安全なアプリケーションの開発を促進するクラスおよびサービスに関する情報を提供します。 + diff --git a/docs/standard/assembly-format.md b/docs/standard/assembly-format.md index 91ce7b93ee2..6fd8a6493ed 100644 --- a/docs/standard/assembly-format.md +++ b/docs/standard/assembly-format.md @@ -1,6 +1,6 @@ --- title: ".NET アセンブリ ファイルの形式" -description: ".NET アセンブリ ファイルの形式" +description: ".NET アプリおよびライブラリを記述する場合や含める場合に使用する .NET アセンブリ ファイル形式について説明します。" keywords: .NET, .NET Core author: richlander ms.author: mairaw @@ -10,22 +10,23 @@ ms.prod: .net ms.technology: dotnet-standard ms.devlang: dotnet ms.assetid: 6520323e-ff28-4c8a-ba80-e64a413199e6 -translationtype: Human Translation -ms.sourcegitcommit: 90fe68f7f3c4b46502b5d3770b1a2d57c6af748a -ms.openlocfilehash: ec5619e164be44205060d790ba1dc66e261faf92 -ms.lasthandoff: 03/02/2017 +ms.translationtype: HT +ms.sourcegitcommit: 934373d61407c8cc19b7d6424898a582880f9c21 +ms.openlocfilehash: 47e895274f6d400639878e0bd5c700e04b554ce5 +ms.contentlocale: ja-jp +ms.lasthandoff: 08/21/2017 --- # .NET アセンブリ ファイルの形式 -.NET プラットフォームでは、.NET プログラムの完全な記述と格納に使用するバイナリ ファイル形式として、"アセンブリ" が定義されています。 アセンブリは、プログラム自体と同様に従属ライブラリにも使用されます。 .NET プログラムは、適切な .NET ランタイム以外の成果物を必要とせずに、1 つ以上のアセンブリとして実行できます。 ネイティブの依存関係 (オペレーティング システム API を含む) は別の考慮事項であり、.NET アセンブリの形式には存在しません。ただし、この形式を使用して記述されることがあります (たとえば WinRT)。 +.NET では、.NET プログラムの完全な記述と格納に使用するバイナリ ファイル形式として、"アセンブリ" が定義されています。 アセンブリは、プログラム自体と同様に従属ライブラリにも使用されます。 .NET プログラムは、適切な .NET 実装以外の成果物を必要とせずに、1 つ以上のアセンブリとして実行できます。 ネイティブの依存関係 (オペレーティング システム API を含む) は別の考慮事項であり、.NET アセンブリの形式には存在しません。ただし、この形式を使用して記述されることがあります (たとえば WinRT)。 > 各 CLI コンポーネントには、そのコンポーネントに固有の宣言、実装、参照のためのメタデータが含まれます。 そのため、コンポーネント固有のメタデータはコンポーネント メタデータと呼ばれ、結果として得られるコンポーネントは自己記述と呼ばれます (ECMA 335 I.9.1 のコンポーネントおよびアセンブリの仕様)。 この形式は ECMA 335 として仕様が完全に指定され、標準化されています。 すべての .NET コンパイラとランタイムが、この形式を使用します。 ドキュメント化された、更新が頻繁でないバイナリ形式の存在は、相互運用性の面で大きなメリットであり、ほぼ間違いなく必要条件になっています。 この形式が最後に実質的な方法で更新されたのは 2005 年 (.NET 2.0) で、ジェネリックやプロセッサ アーキテクチャに対応するための変更が行われました。 -この形式は CPU や OS に依存しません。 多くのチップや CPU を対象にした .NET ランタイムの一部として使用されています。 この形式自体は Windows で開発された経緯がありますが、任意のオペレーティング システムに実装できます。 OS の相互運用性にかかわる、この形式の最も重要なオプションと言えるのは、ほとんどの値をリトル エンディアン形式で格納することです。 コンピューターのポインター サイズ (32 ビット、64 ビットなど) に対する特定の関係はありません。 +この形式は CPU や OS に依存しません。 多くのチップや CPU を対象にした .NET 実装の一部として使用されています。 この形式自体は Windows で開発された経緯がありますが、任意のオペレーティング システムに実装できます。 OS の相互運用性にかかわる、この形式の最も重要なオプションと言えるのは、ほとんどの値をリトル エンディアン形式で格納することです。 コンピューターのポインター サイズ (32 ビット、64 ビットなど) に対する特定の関係はありません。 .NET アセンブリ形式は、特定のプログラムまたはライブラリの構造をとてもわかりやすく記述することもできます。 アセンブリの内部コンポーネント、具体的にはアセンブリ参照や定義済みの型とそれらの内部構造を記述します。 ツールまたは API で表示のためにこの情報の読み取り、処理を行ったり、プログラムによる決定を行うことができます。 @@ -39,5 +40,5 @@ ECMA 335 II.25.1 のランタイム ファイル形式の構造に基づくア ## アセンブリの処理 -アセンブリを処理するツールや API を記述することができます。 アセンブリ情報を使用して、実行時のプログラムによる決定、アセンブリの書き換え、エディターでの API IntelliSense の提供、ドキュメントの生成ができます。 [System.Reflection](https://msdn.microsoft.com/library/system.reflection.aspx) と [Mono.Cecil](http://www.mono-project.com/docs/tools+libraries/libraries/Mono.Cecil/) は、この目的によく使われるツールの好例です。 +アセンブリを処理するツールや API を記述することができます。 アセンブリ情報を使用して、実行時のプログラムによる決定、アセンブリの書き換え、エディターでの API IntelliSense の提供、ドキュメントの生成ができます。 と [Mono.Cecil](http://www.mono-project.com/docs/tools+libraries/libraries/Mono.Cecil/) は、この目的によく使われるツールの好例です。 diff --git a/docs/standard/async-in-depth.md b/docs/standard/async-in-depth.md index b04e8586363..19eb657c8ff 100644 --- a/docs/standard/async-in-depth.md +++ b/docs/standard/async-in-depth.md @@ -1,6 +1,6 @@ --- title: "非同期の詳細" -description: ".NET での非同期コードの動作についての詳細な説明" +description: ".NET のタスクベース非同期モデルを使用して、I/O バインドおよび CPU バインドの非同期コードを簡単に記述する方法について説明します。" keywords: ".NET, .NET Core, .NET の標準" author: cartermp ms.author: wiwagn @@ -10,16 +10,17 @@ ms.prod: .net ms.technology: dotnet-standard ms.devlang: dotnet ms.assetid: 1e38f9d9-8f84-46ee-a15f-199aec4f2e34 -translationtype: Human Translation -ms.sourcegitcommit: b967d8e55347f44a012e4ad8e916440ae228c8ec -ms.openlocfilehash: 92d94fd7f148bb4c1bbad50212d90d722214085f -ms.lasthandoff: 03/10/2017 +ms.translationtype: HT +ms.sourcegitcommit: ef6d1bf9a7153f7adf635d13b4dcfb7647ed2e33 +ms.openlocfilehash: 88492a5db66977f3b914123aa8489c079aff59c5 +ms.contentlocale: ja-jp +ms.lasthandoff: 08/21/2017 --- # 非同期の詳細 -I/O および CPU バインドの非同期コードは、.NET のタスクベース非同期モデルを使用して簡単に記述できます。 このモデルは、`Task` および `Task` 型と、`async` および `await` 言語キーワードによって公開されます。 この記事では、.NET 非同期を使用する方法について説明し、背後で使用される非同期フレームワークを把握するための情報を示します。 +I/O および CPU バインドの非同期コードは、.NET のタスクベース非同期モデルを使用して簡単に記述できます。 C# と Visual Basic では、このモデルは `Task` および `Task` 型と、`async` および `await` キーワードによって公開されます (言語固有のリソースについては、「[関連項目](#see-also)」セクションを参照してください)。この記事では、.NET 非同期を使用する方法について説明し、背後で使用される非同期フレームワークを把握するための情報を示します。 ## Task と Task<T> @@ -34,7 +35,7 @@ Task は、[Promise Model of Concurrency](https://en.wikipedia.org/wiki/Futures_ `await` を使用すると、アプリケーションまたはサービスで、タスク完了まで呼び出し元に制御を渡すことによって、タスクの実行中に有用な作業を実行できます。 コードは、タスク完了後に実行を続けるために、コールバックまたはイベントに依存する必要はありません。 言語とタスクの API 統合によって処理されます。 `Task` を使用する場合、`await` キーワードはさらに、タスク完了時に返された値を "ラップ解除" します。 この動作の詳細について次に詳しく説明します。 -タスクと、タスクを処理するさまざまな方法について詳しく知るには、[タスクベースの非同期パターン (TAP) に関する記事](https://msdn.microsoft.com/library/hh873175.aspx)を参照してください。 +タスクと、タスクを処理するさまざまな方法については、[タスクベースの非同期パターン (TAP) に関するトピック](~/docs/standard/asynchronous-programming-patterns/task-based-asynchronous-pattern-tap.md)を参照してください。 ## I/O バインド操作に関するタスクの詳細 @@ -45,7 +46,7 @@ Task は、[Promise Model of Concurrency](https://en.wikipedia.org/wiki/Futures_ ```csharp public Task GetHtmlAsync() { - // Execution is synchronous here + // Execution is synchronous here var client = new HttpClient(); return client.GetStringAsync("http://www.dotnetfoundation.org"); @@ -146,4 +147,11 @@ public async Task CalculateResult(InputData data) ### async が役に立つ理由 -`async`と `await` は、応答性を必要とする場合に CPU バインドの作業を管理する際のベスト プラクティスです。 CPU バインドの作業で async を使用するには、複数のパターンがあります。 async を使用すると小さいながらも負荷がかかるため、厳密なループ処理にはお勧めしません。 この新しい機能を利用してコードを記述するかどうかは、ユーザーの判断に任されます。 +`async`と `await` は、応答性を必要とする場合に CPU バインドの作業を管理する際のベスト プラクティスです。 CPU バインドの作業で async を使用するには、複数のパターンがあります。 async を使用すると小さいながらも負荷がかかるため、厳密なループ処理にはお勧めしません。 この新しい機能を利用してコードを記述するかどうかは、ユーザーの判断に任されます。 + +## 関連項目 + +[C# の非同期プログラミングの詳細](~/docs/csharp/async.md) +[F# の非同期プログラミング](~/docs/fsharp/tutorials/asynchronous-and-concurrent-programming/async.md) +[Async および Await を使用した非同期プログラミング (Visual Basic)](~/docs/visual-basic/programming-guide/concepts/async/index.md) + diff --git a/docs/standard/async.md b/docs/standard/async.md index 702b12638cb..b07365b0380 100644 --- a/docs/standard/async.md +++ b/docs/standard/async.md @@ -1,6 +1,6 @@ --- title: "非同期の概要" -description: "非同期の概要" +description: "ブロッキング I/O と複数コアでの同時操作の処理を容易にする鍵となる手法である非同期プログラミングについて説明します。" keywords: .NET, .NET Core author: cartermp ms.author: wiwagn @@ -10,10 +10,11 @@ ms.prod: .net ms.technology: dotnet-standard ms.devlang: dotnet ms.assetid: 1e38e9d9-8284-46ee-a15f-199adc4f26f4 -translationtype: Human Translation -ms.sourcegitcommit: b967d8e55347f44a012e4ad8e916440ae228c8ec -ms.openlocfilehash: db4c9721381a9675b06f0fc6b5381d987816e9a4 -ms.lasthandoff: 03/10/2017 +ms.translationtype: HT +ms.sourcegitcommit: ef6d1bf9a7153f7adf635d13b4dcfb7647ed2e33 +ms.openlocfilehash: bf0cc4ed21c92a57f3f5b2cfa27ac1f054e15172 +ms.contentlocale: ja-jp +ms.lasthandoff: 08/21/2017 --- @@ -28,7 +29,7 @@ ms.lasthandoff: 03/10/2017 ## 非同期コードを記述する理由 -最新アプリでは、ファイルおよびネットワーク I/O を広範囲に使用します。 従来の I/O API は既定によりブロックし、困難なパターンを学習して使用しない限り、結果的にユーザー エクスペリエンスとハードウェア使用率が不適切になっていました。 このモデルを逆転させたのが非同期 API と言語レベルの非同期プログラミング モデルであり、非同期実行が既定になりました。これに関して新たに学習する必要がある概念はほとんどありません。 +最新アプリでは、ファイルおよびネットワーク I/O を広範囲に使用します。 従来の I/O API は既定によりブロックし、困難なパターンを学習して使用しない限り、結果的にユーザー エクスペリエンスとハードウェア使用率が不適切になっていました。 このモデルを逆転させたのがタスクベースの非同期 API と言語レベルの非同期プログラミング モデルであり、非同期実行が既定になりました。これに関して新たに学習する必要がある概念はほとんどありません。 非同期コードの特性は次のとおりです。 @@ -39,6 +40,5 @@ ms.lasthandoff: 03/10/2017 ## 次の内容 -非同期の概念とプログラミングの詳細については、「[非同期の詳細](async-in-depth.md)」を参照してください。 - +非同期の概念とプログラミングの詳細については、「[非同期の詳細](async-in-depth.md)」と「[Task-based asynchronous programming](~/docs/standard/parallel-programming/task-based-asynchronous-programming.md)」(タスクベースの非同期プログラミング) を参照してください。 diff --git a/docs/standard/building-console-apps.md b/docs/standard/building-console-apps.md index 047775f59a0..28265695425 100644 --- a/docs/standard/building-console-apps.md +++ b/docs/standard/building-console-apps.md @@ -1,41 +1,46 @@ --- -title: ".NET Framework におけるコンソール アプリケーションの構築 | Microsoft Docs" -ms.custom: "" -ms.date: "03/30/2017" -ms.prod: ".net" -ms.reviewer: "" -ms.suite: "" -ms.technology: - - "dotnet-standard" -ms.tgt_pltfrm: "" -ms.topic: "article" -helpviewer_keywords: - - ".NET Framework, ビルド (コンソール アプリケーションを)" - - "アプリケーション開発 [.NET Framework], コンソール" - - "コンソール アプリケーション" +title: ".NET Framework におけるコンソール アプリケーションの構築" +ms.custom: +ms.date: 03/30/2017 +ms.prod: .net +ms.reviewer: +ms.suite: +ms.technology: dotnet-standard +ms.tgt_pltfrm: +ms.topic: article +helpviewer_keywords: +- .NET Framework, building console applications +- application development [.NET Framework], console +- console applications ms.assetid: c21fb997-9f0e-40a5-8741-f73bba376bd8 caps.latest.revision: 16 -author: "rpetrusha" -ms.author: "ronpet" -manager: "wpickett" -caps.handback.revision: 16 +author: rpetrusha +ms.author: ronpet +manager: wpickett +ms.translationtype: HT +ms.sourcegitcommit: 306c608dc7f97594ef6f72ae0f5aaba596c936e1 +ms.openlocfilehash: bba3cde0d4e1c15ea764322b8ab0ef1501e53739 +ms.contentlocale: ja-jp +ms.lasthandoff: 08/21/2017 + --- -# .NET Framework におけるコンソール アプリケーションの構築 -.NET Framework のアプリケーションは、 クラスを使用して、コンソールから文字を読み取り、コンソールに文字を書き込みます。 コンソールからのデータは標準入力ストリームから読み取られ、コンソールへのデータは標準出力ストリームに書き込まれ、コンソールへのエラー データは標準エラー出力ストリームに書き込まれます。 これらのストリームは、アプリケーションの起動時に自動的にコンソールに関連付けられ、それぞれ プロパティ、 プロパティ、および プロパティとして示されます。 +# .NET Framework におけるコンソール アプリケーションの構築 +.NET Framework のアプリケーションは、 クラスを使用して、コンソールから文字を読み取り、コンソールに文字を書き込みます。 コンソールからのデータは標準入力ストリームから読み取られ、コンソールへのデータは標準出力ストリームに書き込まれ、コンソールへのエラー データは標準エラー出力ストリームに書き込まれます。 これらのストリームは、アプリケーションの起動時に自動的にコンソールに関連付けられ、それぞれ プロパティ、 プロパティ、および プロパティとして示されます。 - プロパティの値が オブジェクトであるのに対し、 および プロパティの値は オブジェクトです。 これらのプロパティを、コンソールを表さないストリームに関連付けることがができます。これにより、ストリームの出力先または入力元として異なる位置を指定できます。 たとえば、 プロパティを メソッドで をカプセル化する に設定することにより、出力をファイルにリダイレクトできます。 プロパティと プロパティとが同じストリームを参照する必要はありません。 + プロパティの値が オブジェクトであるのに対し、 および プロパティの値は オブジェクトです。 これらのプロパティを、コンソールを表さないストリームに関連付けることができます。これにより、ストリームの出力先または入力元として異なる位置を指定できます。 たとえば、 プロパティを メソッドで をカプセル化する に設定することにより、出力をファイルにリダイレクトできます。 プロパティと プロパティとが同じストリームを参照する必要はありません。 > [!NOTE] -> コンソール アプリケーション \(C\#、Visual Basic、および C\+\+ の例を含む\) をビルドする方法の詳細については クラスのドキュメントを参照してください。 +> コンソール アプリケーション (C#、Visual Basic、および C++ の例を含む) をビルドする方法の詳細については クラスのドキュメントを参照してください。 - Windows ベースのアプリケーションなどでコンソールが存在しない場合には、情報を書き込む先のコンソールがないため、標準出力ストリームに書き込まれた出力を参照できません。 アクセスできないコンソールに情報を書き込んでも、例外は発生しません。 + Windows ベースのアプリケーションなどでコンソールが存在しない場合には、情報を書き込む先のコンソールがないため、標準出力ストリームに書き込まれた出力を参照できません。 アクセスできないコンソールに情報を書き込んでも、例外は発生しません。 - Visual Studio を使用して開発した Windows ベースのアプリケーション内で読み取りおよび書き込み用のコンソールを有効にするには、プロジェクトの **\[プロパティ\]** ダイアログ ボックスを開き、**\[アプリケーション\]** タブをクリックして、**\[アプリケーションの種類\]** を **\[コンソール アプリケーション\]** に設定します。 + Visual Studio を使用して開発した Windows ベースのアプリケーション内で読み取りおよび書き込み用のコンソールを有効にするには、プロジェクトの **[プロパティ]** ダイアログ ボックスを開き、**[アプリケーション]** タブをクリックして、**[アプリケーションの種類]** を **[コンソール アプリケーション]** に設定します。 - コンソール アプリケーションには、既定で起動されるメッセージ ポンプがありません。 したがって、コンソールが Microsoft Win32 タイマーを呼び出すと、失敗する場合があります。 + コンソール アプリケーションには、既定で起動されるメッセージ ポンプがありません。 したがって、コンソールが Microsoft Win32 タイマーを呼び出すと、失敗する場合があります。 - **System.Console** クラスには、コンソールから個々の文字または行全体を読み取ることができるメソッドがあります。 その他のメソッドは、まずデータと書式指定文字列を変換してから、書式設定された文字列をコンソールに書き込みます。 書式指定文字列の詳細については、「[型の書式設定](../../docs/standard/base-types/formatting-types.md)」を参照してください。 + **System.Console** クラスには、コンソールから個々の文字または行全体を読み取ることができるメソッドがあります。 その他のメソッドは、まずデータと書式指定文字列を変換してから、書式設定された文字列をコンソールに書き込みます。 書式指定文字列の詳細については、「[Formatting Types](../../docs/standard/base-types/formatting-types.md)」(型の書式設定) を参照してください。 -## 参照 +## 関連項目 - [型の書式設定](../../docs/standard/base-types/formatting-types.md) \ No newline at end of file + [型の書式設定](../../docs/standard/base-types/formatting-types.md) + diff --git a/docs/standard/choosing-core-framework-server.md b/docs/standard/choosing-core-framework-server.md index 2d10cc93c84..f2cce07d7cd 100644 --- a/docs/standard/choosing-core-framework-server.md +++ b/docs/standard/choosing-core-framework-server.md @@ -1,76 +1,74 @@ --- title: "サーバー アプリ用 .NET Core と .NET Framework の選択" -description: ".NET でのサーバー アプリのビルド時に考慮する必要がある .NET の種類に関するガイドです。" -keywords: .NET, .NET Core, .NET Framework +description: ".NET でのサーバー アプリのビルド時に考慮する必要がある .NET の実装に関するガイドです。" author: cartermp ms.author: mairaw -ms.date: 11/16/2016 +ms.date: 08/15/2016 ms.topic: article ms.prod: .net -ms.technology: dotnet-standard -ms.devlang: dotnet -ms.assetid: 155553e4-89a2-418d-be88-4e75f6c3cc69 -translationtype: Human Translation -ms.sourcegitcommit: 405bac1faa446687a4acdcf2d5536ee31f31f246 -ms.openlocfilehash: 7151c87d373afce88c83239499ba33980383ab98 -ms.lasthandoff: 03/15/2017 - ---- +ms.translationtype: HT +ms.sourcegitcommit: fe2c7ff4055779a000b68a68333f3e4d06381410 +ms.openlocfilehash: aa06ff8253f22c5c867d4ba12c0a132269e04a97 +ms.contentlocale: ja-jp +ms.lasthandoff: 08/21/2017 +--- # サーバー アプリ用 .NET Core と .NET Framework の選択 -.NET を使用してサーバー側のアプリケーションをビルドする場合に選択できるサポート対象ランタイムには、.NET Framework と .NET Core の 2 つがあります。 両方で同じ .NET プラットフォーム コンポーネントの多くが共有され、2 つの間でコードを共有することができます。 ただし、2 つには基本的な違いがあり、どちらを選択するかは実行内容によって決まります。 この記事では、それぞれを使用するタイミングに関するガイダンスを提供します。 +.NET を使用してサーバー側のアプリケーションをビルドする場合に選択できるサポート対象の実装には、.NET Framework と .NET Core の 2 つがあります。 この 2 つは多数の同じコンポーネントを共有しているため、両者でコードを共有できます。 ただし、2 つには基本的な違いがあり、どちらを選択するかは実行内容によって決まります。 この記事では、それぞれを使用するタイミングに関するガイダンスを提供します。 -次のような場合、サーバー アプリケーションには .NET Core を使用する必要があります。 +次のような場合、サーバー アプリケーションには .NET Core を使用します。 * クロスプラット フォームが必要である。 * マイクロサービスが対象である。 * Docker コンテナーを使用している。 * 高パフォーマンスでスケーラブルなシステムが必要である。 -* アプリケーションごとに異なる .NET バージョンが必要である。 +* 1 つのアプリケーションに複数の .NET バージョンが必要である。 -次のような場合、サーバー アプリケーションには .NET Framework を使用する必要があります。 +次のような場合、サーバー アプリケーションには .NET Framework を使用します。 -* 現在、アプリケーションで .NET Framework を使用している (移行ではなく拡張することをお勧めします)。 -* .NET Core で使用できないサードパーティ製の .NET ライブラリまたは NuGet パッケージを使用する必要がある。 -* .NET Core で使用できない .NET テクノロジを使用する必要がある。 -* .NET Core をサポートしていないプラットフォームを使用する必要があります。 +* 現在、アプリで .NET Framework を使用している (移行ではなく拡張することをお勧めします)。 +* アプリが .NET Core で使用できないサードパーティ製の .NET ライブラリや NuGet パッケージを使用している。 +* アプリで、.NET Core で使用できない .NET テクノロジを使用している。 +* アプリで、.NET Core をサポートしていないプラットフォームを使用している。 ## どのような場合に .NET Core を選択すべきか -以下に、前述の .NET Core を選択する理由について詳しく説明します。 +以下のセクションで、前述の .NET Core を選択する理由について詳しく説明します。 ### クロスプラットフォームの必要性 -複数のプラットフォーム (Windows、Linux および macOS) でアプリケーション (Web/サービス) を実行できるようにすることが目的であれば、明らかに .NET Core は最良の選択です。 +複数のプラットフォーム (Windows、Linux、macOS ) で実行する必要があるアプリケーション (Web/サービス) の場合は、.NET Core を使用します。 -.NET Core では、開発ワークステーションとして前述のオペレーティング システムもサポートします。 Visual Studio では、Windows 用の統合開発環境 (IDE) が提供されます。 Visual Studio コードは、IntelliSense とデバッグを含む、.NET Core を完全にサポートする macOS、Linux および Windows でも使用できます。 また、Sublime、Emacs、VI などのサードパーティ製のほとんどのエディターを .NET Core で使用することができ、オープン ソースの [Omnisharp](http://www.omnisharp.net/) プロジェクトを使用してエディターの IntelliSense を取得できます。 さらに、コード エディターをまったく使用せずに、サポートされているすべてのプラットフォームで利用可能な .NET Core コマンドライン ツールを直接使用することもできます。 +.NET Core は、開発ワークステーションとして前述のオペレーティング システムをサポートしています。 Visual Studio では、Windows および Mac 用の統合開発環境 (IDE) が用意されています。 また、macOS、Linux、および Windows 上で動作する Visual Studio Code も使用できます。 Visual Studio Code は、IntelliSense、デバッグなどの .NET Core をサポートしています。 Sublime、Emacs、VI など、ほとんどのサード パーティ製エディターは、.NET Core で動作します。 これらのサード パーティ製エディターでは、[Omnisharp](http://www.omnisharp.net/) を使用して、エディターを IntelliSense にします。 さらに、コード エディターをまったく使用せずに、サポートされているすべてのプラットフォームで利用可能な [.NET Core CLI ツール](../core/tools/index.md)を直接使用することもできます。 ### マイクロサービス アーキテクチャ -複数の独立した動的にスケーラブルなステートフルまたはステートレス マイクロサービスで構成されるマイクロサービス指向のシステムを採用する場合は、.NET Core が最適です。 .NET Core は軽量で、その API サーフェイスはマイクロサービスのスコープに合わせて最小化することができます。 マイクロサービス アーキテクチャでは、サービスの境界をまたいでテクノロジを混在させることもできます。これにより、.NET Framework、Java、Ruby、またはその他のモノリシック テクノロジで開発された他のマイクロサービスやサービスと連動する新しいマイクロサービスで .NET Core を段階的に採用することができます。 +マイクロサービス アーキテクチャでは、サービスの境界を越えて、複数のテクノロジを組み合わせて使用できます。 このテクノロジの組み合わせによって、他のマイクロサービスやサービスと連携する新しいマイクロサービスに .NET Core を段階的に採用することができます。 たとえば、.NET Framework、Java、Ruby などのモノリシックなテクノロジを使用して開発されたマイクロサービスまたはサービスを組み合わせることができます。 + +使用できるインフラストラクチャ プラットフォームは多数あります。 [Azure Service Fabric](https://azure.microsoft.com/services/service-fabric/) は、大規模で複雑なマイクロサービス システム向けに設計されています。 [Azure App Service](https://azure.microsoft.com/services/app-service/) は、ステートレス マイクロサービスに推奨されます。 「[コンテナー](#containers)」セクションで説明するように、Docker ベースのマイクロサービスの代替手段は、どのような種類のマイクロサービスのアプローチにも適しています。 これらすべてのプラットフォームでは .NET Core がサポートされるため、マイクロサービスをホストするには最適です。 -使用できるインフラストラクチャ プラットフォームは多数あります。 大規模で複雑なマイクロサービス システムでは、[Azure Service Fabric](https://azure.microsoft.com/services/service-fabric/) を使用できます。 ステートレス マイクロサービスでは、[Azure App Service](https://azure.microsoft.com/services/app-service/) などの他の製品を使用することもできます。 Docker ベースのマイクロサービスの代替手段は、以下の説明のように、どのような種類のマイクロサービスのアプローチにもフィットします。 これらすべてのプラットフォームでは .NET Core がサポートされるため、マイクロサービスをホストするには最適です。 +マイクロサービス アーキテクチャの詳細については、「[.NET Microservices:Architecture for Containerized .NET Applications](microservices-architecture/index.md)」(.NET マイクロサービス: コンテナー化された .NET アプリケーションのアーキテクチャ) を参照してください。 ### コンテナー -一般的に、コンテナーはマイクロサービス アーキテクチャと併用されますが、アーキテクチャ パターンに従う Web アプリやサービスをコンテナー化するために使用することもできます。 Windows コンテナーで .NET Framework を使用できますが、モジュール性があり、軽量な .NET Core はコンテナーには最適です。 コンテナーを作成して展開する場合、そのイメージのサイズは .NET Framework より .NET Core の方がはるかに小さくなります。 また、クロスプラットフォームであるため、Linux Docker コンテナーなどにサーバー アプリを展開することができます。 +通常、コンテナーは、マイクロサービス アーキテクチャと組み合わせて使用されます。 コンテナーは、任意のアーキテクチャ パターンに従う Web アプリやサービスをコンテナー化するためにも使用できます。 Windows コンテナーで .NET Framework を使用できますが、モジュール方式で軽量である .NET Core はコンテナーに適しています。 コンテナーを作成して展開する場合、そのイメージのサイズは .NET Framework より .NET Core の方がはるかに小さくなります。 また、クロスプラットフォームであるため、Linux Docker コンテナーなどにサーバー アプリを展開することができます。 -したがって、独自の Linux または Windows インフラストラクチャで Docker コンテナーをホストしたり、クラスターでコンテナー ベースのアプリケーションを管理、オーケストレーションおよびスケーリングできる [Azure Container Service](https://azure.microsoft.com/services/container-service/) などのクラウド サービスを使用したりすることができます。 +Docker コンテナーは、オンプレミスの Linux または Windows インフラストラクチャ、または [Azure Container Service](https://azure.microsoft.com/services/container-service/) などのクラウド サービスでホストできます。 Azure Container Service は、コンテナーベースのアプリケーションの管理、調整、およびスケールをクラウドで行うことができます。 ### 高パフォーマンスでスケーラブルなシステムの必要性 -システムで考えられる最高のパフォーマンスとスケーラビリティが必要な場合、NET Core と ASP.NET Core が最適です。 ASP.NET Core は ASP.NET よりパフォーマンスが 10 倍優れており、Java サーブレット、Go および node.js などのマイクロサービスの他の一般的な業界テクノロジをリードしています。 +システムで考えられる最高のパフォーマンスとスケーラビリティが必要な場合、NET Core と ASP.NET Core が最適です。 .NET は Windows Server および Linux 向けの高パフォーマンスなサーバー ランタイムであり、[TechEmpower のベンチマーク](https://www.techempower.com/benchmarks/#hw=ph&test=plaintext)で高パフォーマンスの Web フレームワークとして上位に評価されました。 -これは、特に何百ものマイクロサービスを実行している可能性があるマイクロサービス アーキテクチャに関連します。 ASP.NET Core を使用することで、はるかに少ない数のサーバー/VM でシステムを実行でき、最終的にインフラストラクチャやホストの費用を節約できます。 +何百ものマイクロサービスが実行される可能性があるマイクロサービス アーキテクチャの場合は特に、パフォーマンスとスケーラビリティが重要です。 ASP.NET Core では、少数のサーバー/仮想マシン (VM) 数でシステムが動作します。 サーバー/VM が減るので、インフラストラクチャとホスティングにかかるコストを節約できます。 ### アプリケーション レベルごとに異なる .NET バージョンの必要性 -.NET で異なるバージョンのフレームワークへの依存関係を持つアプリケーションをインストールできるようにする場合は、100% 共存可能な .NET Core を使用する必要があります。 同じコンピューター上に異なるバージョンの .NET Core を簡単にサイド バイ サイド インストールできるため、同じサーバーの複数のサービスをそれぞれ別のバージョンの .NET Core で使用できます。これにより、アプリケーションのアップグレードや IT 運用におけるリスクがなくなり、費用を節約できます。 +複数バージョンの .NET に依存するアプリケーションをインストールする場合は、.NET Core をお勧めします。 .NET Core では、同じコンピューター上で、複数バージョンの .NET Core ランタイムのサイド バイ サイド インストールを利用できます。 サイド バイ サイド インストールによって、同じサーバー上で、使用する .NET Core バージョンが異なる複数のサービスを実行できるようになります。 また、アプリケーションのアップグレードと IT 運用に関係するリスクとコストを軽減できます。 ## どのような場合に .NET Framework を選択すべきか -.NET Core は新しいアプリケーションとアプリケーション パターンには大きな利点がありますが、既存の多くのシナリオでは引き続き .NET Framework が自然な選択肢となります。そのため、すべてのサーバー アプリケーションで .NET Core が代わりに使用されることはありません。 +新しいアプリケーションやアプリケーション パターンの場合は特に .NET Core の利点があります。 一方、多くの既存のシナリオなどについては、今後も .NET Framework が選ばれても不思議ではありません。 どのサーバー アプリケーションでも、.NET Framework は .NET Core に置き換えられません。 ### 現在の .NET Framework アプリケーション @@ -78,36 +76,41 @@ ms.lasthandoff: 03/15/2017 ### .NET Core で使用できないサードパーティ製の .NET ライブラリや NuGet パッケージを使用する必要性 -ライブラリでは .NET Standard の採用が迅速に進められています。これにより、.NET Core を含むすべての種類の .NET でコードを共有できるようになります。 .NET Standard 2.0 では、これがさらに容易になります。.NET Core API サーフェイスがかなり大きくなり、.NET Core アプリケーションで既存の .NET Framework ライブラリを直接使用できるようになるためです。 この移行はすぐには行われませんが、いずれにせよ、決定する前に、アプリケーションで必要な特定のライブラリを確認することをお勧めします。 +ライブラリは、短期間で .NET Standard を採用しています。 .NET Standard を使用すると、.NET Core を含め、すべての .NET 実装全体でコードを共有できます。 .NET Standard 2.0 を使用すれば、さらに簡単です。 +- API サーフェスがはるかに大きくなりました。 +- .NET Framework 互換モードが導入されました。 この互換モードにより、.NET Standard/.NET Core プロジェクトは .NET Framework ライブラリを参照できます。 互換モードの詳細については、「[Announcing .NET Standard 2.0](https://blogs.msdn.microsoft.com/dotnet/2017/08/14/announcing-net-standard-2-0/)」(.NET Standard 2.0 のお知らせ) を参照してください。 + +そのため、ライブラリまたは NuGet パッケージが、.NET Standard/.NET Core で使用できないテクノロジを使用している場合にのみ、.NET Framework を使用する必要があります。 ### .NET Core で使用できない .NET テクノロジを使用する必要性 -一部の .NET Framework テクノロジは .NET Core では使用できません。 .NET Core の今後のリリースで使用可能になるものもありますが、それ以外は .NET Core の対象となる新しいアプリケーション パターンには適用されず、使用可能にならない可能性があります。 .NET Core 1.0 にはない最も一般的なテクノロジを、以下のリストに示します。 +一部の .NET Framework テクノロジは .NET Core では使用できません。 その一部は、.NET Core の今後のリリースで使用できるようになる可能性があります。 それ以外は .NET Core の対象となる新しいアプリケーション パターンには適用されず、使用可能にならない可能性があります。 .NET Core にはない最も一般的なテクノロジを、以下のリストに示します。 -* ASP.NET Web フォーム アプリケーション: ASP.NET Web フォームは .NET Framework でのみ使用可能であるため、このシナリオでは ASP.NET Core/.NET Core を使用することはできません。 現時点では、ASP.NET Web フォームを .NET Core で使用できるようにする予定はありません。 +* ASP.NET Web フォーム アプリケーション: ASP.NET Web フォームは、.NET Framework でのみ使用できます。 ASP.NET Core は、ASP.NET Web フォームに使用できません。 ASP.NET Web フォームが .NET Core で使用できるようになる予定はありません。 -* ASP.NET Web ページ アプリケーション: ASP.NET Web ページは ASP.NET Core 1.0 には含まれていませんが、[.NET Core のロードマップ](https://github.com/aspnet/Home/wiki/Roadmap)に関するページの説明のとおり、今度のリリースに含まれる予定です。 +* ASP.NET Web ページ アプリケーション: ASP.NET Web ページは、ASP.NET Core に含まれていません。 ASP.NET Core [Razor ページ](/aspnet/core/mvc/razor-pages/)には、Web ページとの類似点が多数あります。 -* ASP.NET SignalR サーバー/クライアントの実装。 .NET Core 1.0 リリース (2016 年 6 月) の時点では、ASP.NET SignalR は ASP.NET Core (クライアントとサーバーの両方) では使用できませんが、[.NET Core のロードマップ](https://github.com/aspnet/Home/wiki/Roadmap)に関するページの説明のとおり、今度のリリースに含まれる予定です。 Preview 版は、[サーバー側](https://github.com/aspnet/SignalR-Server)と[クライアント ライブラリ](https://github.com/aspnet/SignalR-Client-Net)の GitHub リポジトリで利用できます。 +* ASP.NET SignalR サーバー/クライアントの実装。 現時点では、ASP.NET SignalR は ASP.NET Core (クライアントとサーバーの両方) で使用できません。 ASP.NET Core SignalR は ASP.NET Core 2.1 で実装される予定です。 「[ASP.NET Core Schedule and Roadmap](https://github.com/aspnet/Home/wiki/Roadmap)」(ASP.NET Core のスケジュールとロードマップ) を参照してください。 Preview 版は、[サーバー側](https://github.com/aspnet/SignalR-Server)と[クライアント ライブラリ](https://github.com/aspnet/SignalR-Client-Net)の GitHub リポジトリで利用できます。 -* WCF サービスの実装。 .NET Core から WCF サービスを利用する [WCF クライアント ライブラリ](https://github.com/dotnet/wcf)がある場合でも、2016 年 6 月の時点では、WCF サーバーの実装は .NET Framework でのみ可能です。 このシナリオは .NET Core の現在の計画に含まれていませんが、将来に向けて検討中です。 +* WCF サービスの実装。 現在のところ、.NET Core から WCF サービスを利用する [WCF クライアント ライブラリ](https://github.com/dotnet/wcf)がある場合でも、WCF サーバーの実装は .NET Framework でのみ可能です。 このシナリオは .NET Core の現在の計画に含まれていませんが、将来に向けて検討中です。 -* ワークフローに関連するサービス: .Windows Workflow Foundation (WF)、ワークフロー サービス (1 つのサービスに WCF と WF) および WCF Data Services (旧称: "ADO.NET Data Services") は、NET Framework でのみ使用できます。.NET Core で使用できるようにする予定はありません。 +* ワークフローに関連するサービス: .Windows Workflow Foundation (WF)、ワークフロー サービス (1 つのサービスに WCF と WF) および WCF Data Services (旧称: "ADO.NET Data Services") は、NET Framework でのみ使用できます。 WF/WCF+WF/WCF Data Services を .NET Core に導入する予定はありません。 -* Windows Presentation Foundation (WPF) と Windows フォーム: WPF アプリケーションと Windows フォーム アプリケーションは、.NET Framework でのみ使うことができます。 .NET Core に移植する計画はありません。 +* Windows Presentation Foundation (WPF) と Windows フォーム: WPF アプリケーションと Windows フォーム アプリケーションは、.NET Framework でのみ使うことができます。 .NET Core に移植する計画はありません。 -* 言語サポート: 現在、Visual Basic と F# は .NET Core でサポートされていませんが、Visual Studio 2017 以降のバージョンの Visual Studio ではどちらもサポートされる予定です。 +* 言語のサポート: Visual Basic と F# は現在 .NET Core でサポートされていますが、サポートされないプロジェクトの種類もあります。 サポートされるプロジェクト テンプレートの一覧については、[dotnet new のテンプレート オプション](../core/tools/dotnet-new.md#arguments)に関するセクションを参照してください。 -正式なロードマップに加え、.NET Core に移植される他のフレームワークもあります。完全なリストについては、[port-to-core](https://github.com/dotnet/corefx/issues?q=is%3Aopen+is%3Aissue+label%3Aport-to-core) というマークの付いた CoreFX の案件を参照してください。 このリストは Microsoft がこれらのコンポーネントを .NET Core に提供することを約束するものではなく、単にコミュニティの要望を取り込んでいるだけであることに注意してください。 上にリストされているコンポーネントが気になる場合には、GitHub でのディスカッションに参加して意見を述べることを検討してください。 また、何か足りないと感じた場合は、[CoreFX リポジトリで新しい案件を作成](https://github.com/dotnet/corefx/issues/new)してください。 +公式のロードマップに加え、.NET Core に移植される予定のフレームワークが他にもあります。 詳細な一覧については、[port-to-core](https://github.com/dotnet/corefx/issues?q=is%3Aopen+is%3Aissue+label%3Aport-to-core) とマークされている CoreFX の論点を参照してください。 この一覧は、Microsoft がそれらのコンポーネントを .NET Core に導入する予定ではありません。 単に、コミュニティからの希望をまとめたものです。 `port-to-core` とマークされているいずれかのコンポーネントに関心がある場合は、GitHub のディスカッションに参加してください。 また、一覧に欠けている点があるとお考えの場合は、[CoreFX リポジトリ](https://github.com/dotnet/corefx/issues/new)に登録してください。 ### .NET Core をサポートしていないプラットフォームを使用する必要性 Microsoft やサードパーティ製のプラットフォームの中には、.NET Core をサポートしないものもあります。 たとえば、Service Fabric のステートフル Reliable Services や Service Fabric Reliable Actors などのいくつかの Azure サービスでは .NET Framework が必要です。 他のいくつかのサービスでは、.NET Core ではまだ使用できない SDK が提供されます。 すべての Azure サービスでは .NET Core を使用しているために、これは過渡的な状況です。 その間、クライアント SDK の代わりに同等の REST API をいつでも使用できます。 -## 他のリソース - -* [.NET Core のガイド](../core/index.md) -* [.NET Framework から .NET Core への移植](../core/porting/index.md) -* [Docker 上の .NET Framework のガイド](../framework/index.md) -* [.NET コンポーネントの概要](components.md) +## 関連項目 + [ASP.NET と ASP.NET Core の選択](/aspnet/core/choose-aspnet-framework) + [.NET Core ガイド](../core/index.md) + [.NET Framework から .NET Core への移植](../core/porting/index.md) + [Docker 上の .NET Framework のガイド](../framework/docker/index.md) + [.NET コンポーネントの概要](components.md) + [.NET マイクロサービス:コンテナー化された .NET アプリケーションのアーキテクチャ](microservices-architecture/index.md) diff --git a/docs/standard/class-libraries.md b/docs/standard/class-libraries.md index e33cd5eec6b..4319c585691 100644 --- a/docs/standard/class-libraries.md +++ b/docs/standard/class-libraries.md @@ -1,6 +1,6 @@ --- title: ".NET クラス ライブラリ" -description: ".NET クラス ライブラリ" +description: ".NET クラス ライブラリを使用して、役に立つ機能をモジュールとしてコンポーネント化して、複数のアプリケーションで使用する方法について説明します。" keywords: .NET, .NET Core author: richlander ms.author: mairaw @@ -10,11 +10,11 @@ ms.prod: .net ms.technology: dotnet-standard ms.devlang: dotnet ms.assetid: a67484c3-fe92-44d8-8fa3-36fa2071d880 -ms.translationtype: Human Translation -ms.sourcegitcommit: 90fe68f7f3c4b46502b5d3770b1a2d57c6af748a -ms.openlocfilehash: 028fd4961c97e31ea9f213b832c723b2ce2cf27c +ms.translationtype: HT +ms.sourcegitcommit: 3155295489e1188640dae5aa5bf9fdceb7480ed6 +ms.openlocfilehash: c72cdcbbe20c3c7a6890cdacb446e3db8de1b37a ms.contentlocale: ja-jp -ms.lasthandoff: 04/18/2017 +ms.lasthandoff: 08/21/2017 --- @@ -30,29 +30,29 @@ ms.lasthandoff: 04/18/2017 ## プラットフォーム固有のクラス ライブラリ -プラットフォーム固有のライブラリは 1 つの .NET プラットフォーム (たとえば、Windows 上の .NET Framework) にバインドされるため、既知の 1 つの実行環境に大きく依存する可能性があります。 そのような環境は既知の API のセット (.NET および OS API) を公開し、予想される状態 (Windows レジストリ) を維持および公開します。 +プラットフォーム固有のライブラリは 1 つの .NET 実装 (たとえば、Windows 上の .NET Framework) にバインドされるため、既知の 1 つの実行環境に大きく依存する可能性があります。 そのような環境は既知の API のセット (.NET および OS API) を公開し、予想される状態 (Windows レジストリ) を維持および公開します。 プラットフォーム固有のライブラリを作成する開発者は、基になるプラットフォームのすべての機能を利用できます。 このライブラリは特定のプラットフォーム上でのみ実行されるので、プラットフォームの確認や他の形式の条件付きコードの確認は必要ありません (複数プラットフォーム用のモジュール単一ソース コード)。 -プラットフォーム固有のライブラリは、 .NET Framework のプライマリ クラス ライブラリの種類です。 他の .NET プラットフォームが登場しても、プラットフォーム固有のライブラリは、基準となるライブラリの種類として残っています。 +プラットフォーム固有のライブラリは、 .NET Framework のプライマリ クラス ライブラリの種類です。 他の .NET 実装が登場しても、プラットフォーム固有のライブラリは、基準となるライブラリの種類として残っています。 ## ポータブル クラス ライブラリ -ポータブル ライブラリは、複数の .NET プラットフォームでサポートされます。 このライブラリは、既知の実行環境に依存することは同じですが、その環境は、完全な .NET プラットフォームのセットの共通部分によって生成されます。 つまり、公開される API およびプラットフォームの前提は、プラットフォーム固有のライブラリで使用できる機能のサブセットです。 +ポータブル ライブラリは、複数の .NET 実装でサポートされます。 このライブラリは、既知の実行環境に依存することは同じですが、その環境は、完全な .NET 実装のセットの共通部分によって生成されます。 つまり、公開される API およびプラットフォームの前提は、プラットフォーム固有のライブラリで使用できる機能のサブセットです。 ポータブル ライブラリを作成するときに、プラットフォームの構成を選択します。 これらはサポートする必要があるプラットフォーム (たとえば、.NET Framework 4.5 以降、Windows Phone 8.0 以降) のセットです。 サポートするプラットフォームが増えるほど、想定可能な API とプラットフォームが減り、共通分母が最小になります。 このような特性は、最初は混乱を招くことがあります。ユーザーは多くの場合、「多いほどよい」と考えますが、結果はサポートするプラットフォームが増えるほど、使用可能な API は少なくなります。 多くのライブラリ開発者は、1 つのソースから複数のプラットフォーム固有のライブラリを生成する方法 (条件付きコンパイル ディレクティブを使用) からポータブル ライブラリに切り替えています。 ポータブル ライブラリ内のプラットフォーム固有の機能にアクセスする[方法はいくつか](http://blog.stephencleary.com/2012/11/portable-class-library-enlightenment.html)あります。現時点で最も広く採用されている手法は、[bait-and-switch](http://log.paulbetts.org/the-bait-and-switch-pcl-trick/) です。 -### .NET Core クラス ライブラリ +### .NET Standard クラス ライブラリ -.NET Core ライブラリは、プラットフォームに固有のライブラリおよびポータブル ライブラリの概念に代わるものです。 これらは、基になるプラットフォームのすべての機能を公開するという意味でプラットフォーム固有です (統合プラットフォームまたはプラットフォームの交差はありません)。 これらは、すべてのサポートされるプラットフォーム上で機能するという意味でポータブルです。 +.NET Standard ライブラリは、プラットフォームに固有のライブラリおよびポータブル ライブラリの概念に代わるものです。 これらは、基になるプラットフォームのすべての機能を公開するという意味でプラットフォーム固有です (統合プラットフォームまたはプラットフォームの交差はありません)。 これらは、すべてのサポートされるプラットフォーム上で機能するという意味でポータブルです。 -.NET Core は、ライブラリ _コントラクト_のセットを公開します。 .NET プラットフォームは、各コントラクトを完全にサポートするか、またはまったくサポートしない必要があります。 各プラットフォームは、そのため、.NET Core コントラクトのセットをサポートしています。 当然の結果として、各 .NET Core クラス ライブラリは、コントラクトの依存関係をサポートするプラットフォームでサポートされています。 +.NET Standard は、ライブラリ _コントラクト_のセットを公開しています。 .NET 実装は、各コントラクトを完全にサポートするか、またはまったくサポートしない必要があります。 そのため、各実装は .NET Standard コントラクトのセットをサポートしています。 当然の結果として、各 .NET Standard クラス ライブラリは、コントラクトの依存関係をサポートするプラットフォームでサポートされています。 -.NET Core コントラクトは、.NET Framework のすべての機能を公開しません (それが目的でもありません)。ただし、ポータブル クラス ライブラリよりも多くの API を公開する操作を行います。 時間の経過と共にさらに API が追加されます。 +.NET Standard は、.NET Framework のすべての機能を公開していません (それが目的でもありません)。ただし、ポータブル クラス ライブラリよりも多くの API を公開しています。 時間の経過と共にさらに API が追加されます。 -次のプラットフォームは、.NET Core クラス ライブラリをサポートします。 +次のプラットフォームは、.NET Standard ライブラリをサポートしています。 * .NET Core * ASP.NET Core diff --git a/docs/standard/class-library-overview.md b/docs/standard/class-library-overview.md index 58f3d45c5af..fba73b8a774 100644 --- a/docs/standard/class-library-overview.md +++ b/docs/standard/class-library-overview.md @@ -1,57 +1,61 @@ --- -title: ".NET Framework クラス ライブラリの概要 | Microsoft Docs" -ms.custom: "" -ms.date: "03/30/2017" -ms.prod: ".net" -ms.reviewer: "" -ms.suite: "" -ms.technology: - - "dotnet-standard" -ms.tgt_pltfrm: "" -ms.topic: "article" -helpviewer_keywords: - - ".NET Framework クラス ライブラリ, 概要" - - ".NET Framework, クラス ライブラリ" - - "基本型, クラス ライブラリ" - - "組み込み型" - - "クラス ライブラリ [.NET Framework]" - - "クラス オブジェクト値型" - - "クラス [.NET Framework], ライブラリ概要" - - "CLS" - - "共通言語仕様" - - "データ型 [.NET Framework]" - - "データ型 [.NET Framework], C#" - - "データ型 [.NET Framework], C++" - - "データ型 [.NET Framework], JScript" - - "データ型 [.NET Framework], Visual Basic" - - "浮動小数点値型" - - "整数値型" - - "JScript, データ型" - - "ライブラリ, .NET Framework クラス ライブラリ" - - "論理値型" - - "メンバー [.NET Framework], 型" - - "名前空間 [.NET Framework]" - - "名前空間 [.NET Framework], 名前空間の概要" - - "名前付け規則 [.NET Framework]" - - "System 名前空間" - - "型システム [.NET Framework]" - - "型, .NET Framework" - - "ユーザー定義型" - - "値型" - - "Visual Basic, データ型" - - "Visual C#, データ型" - - "Visual C++, データ型" +title: ".NET Framework クラス ライブラリの概要" +ms.custom: +ms.date: 03/30/2017 +ms.prod: .net +ms.reviewer: +ms.suite: +ms.technology: dotnet-standard +ms.tgt_pltfrm: +ms.topic: article +helpviewer_keywords: +- classes [.NET Framework], library overview +- class objects value type +- naming conventions [.NET Framework] +- types, .NET Framework +- user-defined types +- Visual Basic, data types +- data types [.NET Framework], C++ +- Visual C#, data types +- libraries, .NET Framework class library +- data types [.NET Framework], JScript +- System namespace +- JScript, data types +- .NET Framework, class library +- type system [.NET Framework] +- data types [.NET Framework] +- value types +- data types [.NET Framework], Visual Basic +- Common Language Specification +- namespaces [.NET Framework] +- floating point value type +- class library [.NET Framework] +- CLS +- logical value type +- .NET Framework class library, about +- built-in types +- namespaces [.NET Framework], about namespaces +- Visual C++, data types +- members [.NET Framework], type +- data types [.NET Framework], C# +- integer value type +- base types, class library ms.assetid: 7e4c5921-955d-4b06-8709-101873acf157 caps.latest.revision: 19 -author: "rpetrusha" -ms.author: "ronpet" -manager: "wpickett" -caps.handback.revision: 19 +author: rpetrusha +ms.author: ronpet +manager: wpickett +ms.translationtype: HT +ms.sourcegitcommit: 306c608dc7f97594ef6f72ae0f5aaba596c936e1 +ms.openlocfilehash: b88c85eaeabc7fa87b483c7302bd5e135e3fd276 +ms.contentlocale: ja-jp +ms.lasthandoff: 08/21/2017 + --- -# .NET Framework クラス ライブラリの概要 -[!INCLUDE[dnprdnshort](../../includes/dnprdnshort-md.md)] には、開発プロセスを高速化および最適化し、システム機能へのアクセスを提供する、クラス、インターフェイス、および値型があります。 言語間での相互運用性を確保するために、.NET Framework のほとんどの型は共通言語仕様 \(CLS: Common Language Specification\) に準拠しています。このため、コンパイラが CLS に準拠しているすべてのプログラミング言語でこれらの型を使用できます。 +# .NET Framework クラス ライブラリの概要 +[!INCLUDE[dnprdnshort](../../includes/dnprdnshort-md.md)] には、開発プロセスを高速化および最適化し、システム機能へのアクセスを提供する、クラス、インターフェイス、および値型があります。 言語間での相互運用性を確保するために、.NET Framework のほとんどの型は共通言語仕様 (CLS: Common Language Specification) に準拠しています。このため、コンパイラが CLS に準拠しているすべてのプログラミング言語でこれらの型を使用できます。 - .NET Framework の型は、.NET アプリケーション、.NET コンポーネント、および .NET コントロールを構築するときの基礎となります。 [!INCLUDE[dnprdnshort](../../includes/dnprdnshort-md.md)] には、次の機能を実行する型が用意されています。 + .NET Framework の型は、.NET アプリケーション、.NET コンポーネント、および .NET コントロールを構築するときの基礎となります。 [!INCLUDE[dnprdnshort](../../includes/dnprdnshort-md.md)] には、次の機能を実行する型が用意されています。 - 基本データ型と例外を表す。 @@ -65,51 +69,52 @@ caps.handback.revision: 19 - データ アクセス、豊富なクライアント側 GUI、およびサーバー制御式のクライアント側 GUI を提供する。 - [!INCLUDE[dnprdnshort](../../includes/dnprdnshort-md.md)] には、豊富なインターフェイスのセットに加えて、抽象クラスと具象 \(抽象ではない\) クラスが用意されています。 具象クラスはそのまま使用できますが、多くの場合は、具象クラスから独自のクラスを派生させます。 インターフェイスの機能を使用するには、インターフェイスを実装するクラスを作成するか、またはインターフェイスを実装する .NET Framework クラスの 1 つからクラスを派生させます。 + [!INCLUDE[dnprdnshort](../../includes/dnprdnshort-md.md)] には、豊富なインターフェイスのセットに加えて、抽象クラスと具象 (抽象ではない) クラスが用意されています。 具象クラスはそのまま使用できますが、多くの場合は、具象クラスから独自のクラスを派生させます。 インターフェイスの機能を使用するには、インターフェイスを実装するクラスを作成するか、またはインターフェイスを実装する .NET Framework クラスの 1 つからクラスを派生させます。 -## 名前付け規則 - .NET Framework の型では、階層構造を伴うドット構文の名前付け方法が使われます。 この方法では、関連する型が名前空間にグループ化されるため、検索と参照を簡単に行うことができます。 フルネームのうち右端のドットまでの最初の部分は、名前空間の名前です。 名前の最後の部分は型名です。 たとえば、**System.Collections.ArrayList** は **ArrayList** 型であり、名前空間 **System.Collections** に属します。 **System.Collections** 内の型を使用することで、オブジェクトのコレクションを操作できます。 +## 名前付け規則 + .NET Framework の型では、階層構造を伴うドット構文の名前付け方法が使われます。 この方法では、関連する型が名前空間にグループ化されるため、検索と参照を簡単に行うことができます。 フルネームのうち右端のドットまでの最初の部分は、名前空間の名前です。 名前の最後の部分は型名です。 たとえば、**System.Collections.ArrayList** は **ArrayList** 型であり、名前空間 **System.Collections** に属します。 **System.Collections** 内の型を使用することで、オブジェクトのコレクションを操作できます。 - この名前付け方法によって、[!INCLUDE[dnprdnshort](../../includes/dnprdnshort-md.md)] を拡張するライブラリ開発者は、型の階層構造のグループを簡単に作成し、一貫性のあるわかりやすい名前を付けることができます。 また、型の完全名 \(つまり名前空間と型名\) によって型を明確に特定できるため、型名の競合を防ぐことができます。 ライブラリ開発者は、次の規則に従って名前空間の名前を付けてください。 + この名前付け方法によって、[!INCLUDE[dnprdnshort](../../includes/dnprdnshort-md.md)] を拡張するライブラリ開発者は、型の階層構造のグループを簡単に作成し、一貫性のあるわかりやすい名前を付けることができます。 また、型の完全名 (つまり名前空間と型名) によって型を明確に特定できるため、型名の競合を防ぐことができます。 ライブラリ開発者は、次の規則に従って名前空間の名前を付けてください。 *CompanyName*.*TechnologyName* たとえば、名前空間 Microsoft.Word はこのガイドラインに従っています。 - 名前付けパターンを使用して関連する型を名前空間にグループ化する方法は、クラス ライブラリを構築および文書化するのに便利です。 ただし、この名前付け方法は、参照可能範囲、メンバー アクセス、継承、セキュリティ、バインディングには影響しません。 名前空間は複数のアセンブリにまたがって分割でき、また 1 つのアセンブリに複数の名前空間からの型を含めることができます。 アセンブリは、共通言語ランタイムにおけるバージョン管理、配置、セキュリティ、読み込み、および参照可能範囲のための構造を提供します。 + 名前付けパターンを使用して関連する型を名前空間にグループ化する方法は、クラス ライブラリを構築および文書化するのに便利です。 ただし、この名前付け方法は、参照可能範囲、メンバー アクセス、継承、セキュリティ、バインディングには影響しません。 名前空間は複数のアセンブリにまたがって分割でき、また 1 つのアセンブリに複数の名前空間からの型を含めることができます。 アセンブリは、共通言語ランタイムにおけるバージョン管理、配置、セキュリティ、読み込み、および参照可能範囲のための構造を提供します。 - 名前空間と型の名前の詳細については、「[共通型システム](../../docs/standard/base-types/common-type-system.md)」を参照してください。 + 名前空間と型の名前の詳細については、「[Common Type System](../../docs/standard/base-types/common-type-system.md)」(共通型システム) を参照してください。 -## 名前空間 System - 名前空間は、[!INCLUDE[dnprdnshort](../../includes/dnprdnshort-md.md)] における基本的な型のルート名前空間です。 この名前空間には、 \(継承階層構造のルート\)、、、、、 など、すべてのアプリケーションで使用される基本データ型を表すクラスが含まれます。 これらの型の多くは、プログラミング言語で使われるプリミティブなデータ型に対応します。 .NET Framework の型を使用してコードを記述するときには、.NET Framework の基本データ型が使用されるところに、プログラミング言語側の対応するキーワードを使用できます。 +## 名前空間 System + 名前空間は、[!INCLUDE[dnprdnshort](../../includes/dnprdnshort-md.md)] における基本的な型のルート名前空間です。 この名前空間には、 (継承階層構造のルート)、、、、、 など、すべてのアプリケーションで使用される基本データ型を表すクラスが含まれます。 これらの型の多くは、プログラミング言語で使われるプリミティブなデータ型に対応します。 .NET Framework の型を使用してコードを記述するときには、.NET Framework の基本データ型が使用されるところに、プログラミング言語側の対応するキーワードを使用できます。 - 次の表では、[!INCLUDE[dnprdnshort](../../includes/dnprdnshort-md.md)] に用意されているそれぞれの基本型の一覧を示し、各型について簡単に説明し、Visual Basic、C\#、C\+\+、JScript での対応する型を示します。 + 次の表では、[!INCLUDE[dnprdnshort](../../includes/dnprdnshort-md.md)] に用意されているそれぞれの基本型の一覧を示し、各型について簡単に説明し、Visual Basic、C#、C++、JScript での対応する型を示します。 -|カテゴリ|クラス名|説明|Visual Basic のデータ型|C\# のデータ型|C\+\+ データ型|JScript のデータ型| -|----------|----------|--------|------------------------|---------------|----------------|-------------------| -|整数||8 ビット符号なし整数。|**Byte**|**byte**|**unsigned char**|**Byte**| +|カテゴリ|クラス名|説明|Visual Basic のデータ型|C# のデータ型|C++ データ型|JScript のデータ型| +|--------------|----------------|-----------------|----------------------------|-------------------|---------------------|-----------------------| +|整数型||8 ビット符号なし整数。|**Byte**|**byte**|**unsigned char**|**Byte**| |||8 ビット符号付き整数。

非 CLS 準拠|**SByte**|**sbyte**|**char**

または

**signed** **char**|**SByte**| |||16 ビット符号付き整数。|**Short**|**short**|**short**|**short**| -|||32 ビット符号付き整数。|**整数**|**int**|**int**

または

**long**|**int**| -|||64 ビット符号付き整数|**Long**|**long**|**\_\_int64**|**long**| +|||32 ビット符号付き整数。|**Integer**|**int**|**int**

または

**long**|**int**| +|||64 ビット符号付き整数。|**Long**|**long**|**__int64**|**long**| |||16 ビット符号なし整数。

非 CLS 準拠|**UShort**|**ushort**|**unsigned short**|**UInt16**| -|||32 ビット符号なし整数。

非 CLS 準拠|**UInteger**|**uint**|**unsigned int**

または

**unsigned long**|**UInt32**| -|||64 ビット符号なし整数。

非 CLS 準拠|**ULong**|**ulong**|**unsigned \_\_int64**|**UInt64**| -|浮動小数点数||単精度 \(32 ビット\) 浮動小数点数|**Single**|**float**|**float**|**float**| -|||倍精度 \(64 ビット\) 浮動小数点数|**Double \(倍精度浮動小数点型\)**|**double**|**double**|**double**| -|論理||ブール値 \(true または false\)|**Boolean**|**bool**|**bool**|**bool**| -|その他||Unicode \(16 ビット\) 文字|**Char**|**char**|**wchar\_t**|**char**| -|||十進数 \(128 ビット\) の値です。|**Decimal \(10 進数型\)**|**decimal**|**Decimal \(10 進数型\)**|**Decimal \(10 進数型\)**| -|||基になるプラットフォームによってサイズが決まる符号付き整数 \(32 ビットのプラットフォームでは 32 ビット値、64 ビットのプラットフォームでは 64 ビット値\)|**IntPtr**

非組み込み型|**IntPtr**

非組み込み型|**IntPtr**

非組み込み型|**IntPtr**| -|||基になるプラットフォームによってサイズが決まる符号なし整数 \(32 ビットのプラットフォームでは 32 ビット値、64 ビットのプラットフォームでは 64 ビット値\)

非 CLS 準拠|**UIntPtr**

非組み込み型|**UIntPtr**

非組み込み型|**UIntPtr**

非組み込み型|**UIntPtr**| -|クラス オブジェクト||オブジェクト階層構造のルート|**Object**|**object**|**Object\***|**Object**| +|||32 ビット符号なし整数

非 CLS 準拠|**UInteger**|**uint**|**unsigned int**

または

**unsigned long**|**UInt32**| +|||64 ビット符号なし整数。

非 CLS 準拠|**ULong**|**ulong**|**unsigned __int64**|**UInt64**| +|浮動小数点数||単精度 (32 ビット) 浮動小数点数|**Single**|**float**|**float**|**float**| +|||倍精度 (64 ビット) 浮動小数点数|**Double**|**double**|**double**|**double**| +|論理||ブール値 (true または false)|**Boolean**|**bool**|**bool**|**bool**| +|その他||Unicode (16 ビット) 文字|**Char**|**char**|**wchar_t**|**char**| +|||十進数 (128 ビット) の値です。|**Decimal**|**decimal**|**Decimal**|**Decimal**| +|||基になるプラットフォームによってサイズが決まる符号付き整数 (32 ビットのプラットフォームでは 32 ビット値、64 ビットのプラットフォームでは 64 ビット値)|**IntPtr**

非組み込み型|**IntPtr**

非組み込み型|**IntPtr**

非組み込み型|**IntPtr**| +|||基になるプラットフォームによってサイズが決まる符号なし整数 (32 ビットのプラットフォームでは 32 ビット値、64 ビットのプラットフォームでは 64 ビット値)

非 CLS 準拠|**UIntPtr**

非組み込み型|**UIntPtr**

非組み込み型|**UIntPtr**

非組み込み型|**UIntPtr**| +クラス オブジェクト||オブジェクト階層構造のルート|**Object**|**object**|**Object\***|**Object**| |||Unicode 文字の不変固定長文字列|**String**|**string**|**String\***|**String**| - 基本データ型に加えて、 名前空間には、例外を処理するクラスから、核となるランタイム概念 \(アプリケーション ドメインやガベージ コレクターなど\) を扱うクラスまで、100 以上のクラスが含まれます。 名前空間には、2 次レベルの名前空間も数多く含まれています。 + 基本データ型に加えて、 名前空間には、例外を処理するクラスから、核となるランタイム概念 (アプリケーション ドメインやガベージ コレクターなど) を扱うクラスまで、100 以上のクラスが含まれます。 名前空間には、2 次レベルの名前空間も数多く含まれています。 - 名前空間の詳細については、「[.NET Framework クラス ライブラリ](http://go.microsoft.com/fwlink/?LinkID=227195)」を参照してください。 参照ドキュメントには、各名前空間の簡単な概要と、各型とそのメンバーについての説明が記載されています。 + 名前空間の詳細については、「[.NET Framework クラス ライブラリ リファレンス](http://go.microsoft.com/fwlink/?LinkID=227195)」を参照してください。 参照ドキュメントには、各名前空間の簡単な概要と、各型とそのメンバーについての説明が記載されています。 -## 参照 +## 関連項目 [共通型システム](../../docs/standard/base-types/common-type-system.md) [.NET Framework クラス ライブラリ](http://go.microsoft.com/fwlink/?LinkID=227195) - [概要](../../docs/framework/get-started/overview.md) \ No newline at end of file + [概要](../../docs/framework/get-started/overview.md) + diff --git a/docs/standard/common-type-system.md b/docs/standard/common-type-system.md index 21a07e79b1c..2744f78883b 100644 --- a/docs/standard/common-type-system.md +++ b/docs/standard/common-type-system.md @@ -1,6 +1,6 @@ --- title: "共通型システムと共通言語仕様" -description: "共通型システムと共通言語仕様" +description: "共通型システム (CTS) と共通言語仕様 (CLS) を使用して .NET で複数の言語をサポートする方法について説明します。" keywords: .NET, .NET Core author: blackdwarf ms.author: mairaw @@ -10,25 +10,26 @@ ms.prod: .net ms.technology: dotnet-standard ms.devlang: dotnet ms.assetid: 3b1f5725-ac94-4f17-8e5f-244442438a4d -translationtype: Human Translation -ms.sourcegitcommit: b967d8e55347f44a012e4ad8e916440ae228c8ec -ms.openlocfilehash: 1680934b40c3055d2c33ed7457d8734dccbd0a8c -ms.lasthandoff: 03/10/2017 +ms.translationtype: HT +ms.sourcegitcommit: 3155295489e1188640dae5aa5bf9fdceb7480ed6 +ms.openlocfilehash: 9c2cc090dfd5405def0cd6ab9ec1771be4a332a5 +ms.contentlocale: ja-jp +ms.lasthandoff: 08/21/2017 --- # 共通型システムと共通言語仕様 -これらの 2 つの用語は、.NET の世界で自由に使用されます。これらは実際には、.NET プラットフォームで多言語開発を可能にし、そのしくみを理解するために重要です。 +これらの 2 つの用語は、.NET の世界で自由に使用されます。これらは実際には、.NET 実装で多言語開発を可能にし、そのしくみを理解するために重要です。 ## 共通型システム -初めての場合、.NET プラットフォームは、_言語に依存しない_ことに注意してください。 これはプログラマーが IL にコンパイルできる任意の言語でコードを記述できることを意味するだけではありません。 プログラマーが、.NET プラットフォーム上で使用できる他の言語で記述されたコードを操作できる必要があることも意味します。 +最初に、.NET 実装は_言語に依存しない_点に注意してください。 これはプログラマーが IL にコンパイルできる任意の言語でコードを記述できることを意味するだけではありません。 また、.NET 実装で使用可能な他の言語で記述されたコードをプログラマーが操作できる必要があることも意味します。 これを透過的に行うには、すべてのサポートされる種類を記述するための共通の方法が存在している必要があります。 これは、共通型システム (CTS) の役割です。 CTS には、次のようないくつかの目的があります。 * 多言語での実行のためのフレームワークを確立する。 -* .NET プラットフォーム上でさまざまな言語の実装をサポートするためのオブジェクト指向モデルを提供する。 +* .NET 実装でさまざまな言語の実装をサポートするためのオブジェクト指向モデルを提供する。 * 型を扱うときにすべての言語が従う必要がある規則のセットを定義する。 * アプリケーション開発に使用される基本的なプリミティブ データ型 (`Boolean`、`Byte`、`Char` など) を含んだライブラリを提供します。 @@ -50,9 +51,9 @@ CTS では、アクセス修飾子、有効な型のメンバー、継承とオ ## 共通言語仕様 -完全な相互運用シナリオを有効にするには、コードで作成されるすべてのオブジェクトがそれらを使用している言語 (_呼び出し元_) で何らかの共通点に依存する必要があります。 多くの異なる言語があるので、.NET プラットフォームでは、**共通言語仕様** (CLS) という共通点を指定しています。 CLS は、多くの一般的なアプリケーションに必要な機能のセットを定義しています。 さらに、サポートする必要がある .NET プラットフォームの上に実装される言語用のある種のレシピも提供しています。 +完全な相互運用シナリオを有効にするには、コードで作成されるすべてのオブジェクトがそれらを使用している言語 (_呼び出し元_) で何らかの共通点に依存する必要があります。 多くの異なる言語があるので、.NET では、**共通言語仕様** (CLS) という共通性を規定しています。 CLS は、多くの一般的なアプリケーションに必要な機能のセットを定義しています。 さらに、サポートする必要がある .NET 上に実装される言語用のある種のレシピも提供しています。 -CLS は CTS のサブセットです。 つまり、CLS により厳しい規則がない限り、CTS のすべての規則は CLS にも適用されます。 CLS の規則のみを使用してコンポーネントがビルドされている場合、つまり API で CLS の機能のみが公開されている場合、**CLS 準拠**であると言われます。 たとえば、`` は、.NET プラットフォームがサポートされているすべての言語で機能する必要があるため、まさに CLS 準拠です。 +CLS は CTS のサブセットです。 つまり、CLS により厳しい規則がない限り、CTS のすべての規則は CLS にも適用されます。 CLS の規則のみを使用してコンポーネントがビルドされている場合、つまり API で CLS の機能のみが公開されている場合、**CLS 準拠**であると言われます。 たとえば、`` は、.NET がサポートされているすべての言語で機能する必要があるため、まさに CLS 準拠です。 CMS のすべての機能の概要については、下の「[その他のリソース](#more-resources)」セクションのドキュメントを参照してください。 diff --git a/docs/standard/components.md b/docs/standard/components.md index 1b850d8862f..e31026e3c51 100644 --- a/docs/standard/components.md +++ b/docs/standard/components.md @@ -1,86 +1,102 @@ --- title: ".NET アーキテクチャ コンポーネント" -description: ".NET Standard Library、.NET ランタイム、ツールなど、主要な .NET アーキテクチャ コンポーネントについて説明します。" -keywords: ".NET, .NET Standard Library, .NET Standard, .NET Core, .NET Framework, Xamarin, MSBuild, C#, F#, VB, コンパイラ" +description: ".NET Standard、.NET 実装、.NET ランタイム、ツールなど、.NET アーキテクチャ コンポーネントについて説明します。" +keywords: ".NET, .NET Standard, .NET Core, .NET Framework, Mono, Xamarin, MSBuild, C#, F#, VB, コンパイラ" author: cartermp ms.author: mairaw -ms.date: 11/16/2016 +ms.date: 08/10/2017 ms.topic: article ms.prod: .net ms.technology: dotnet-standard ms.devlang: dotnet ms.assetid: 2e38e9d9-8284-46ee-a15f-199adc4f26f4 -translationtype: Human Translation -ms.sourcegitcommit: 7741df222250f3746abb1e3c359bd9e89e6a732c -ms.openlocfilehash: e93764ff4d3391110c79f73a34512bd073ce0499 -ms.lasthandoff: 01/18/2017 +ms.translationtype: HT +ms.sourcegitcommit: 14522f165b22a7b1bb2a717a7c9f293a265f4eb0 +ms.openlocfilehash: 8934febe77b30fb318b06e4d8d297282368438a5 +ms.contentlocale: ja-jp +ms.lasthandoff: 08/21/2017 --- # .NET アーキテクチャ コンポーネント -.NET は複数の主要コンポーネントで構成されています。 .NET Standard Library という名前の標準ライブラリは、どこでも実行できる大規模な API のセットです。 この標準ライブラリは、3 つの .NET ランタイム、つまり .NET Framework、.NET Core、Mono for Xamarin で実装されています。 また、.NET 言語はどの .NET ランタイムでも実行します。 さらに、すべてのプラットフォームにプロジェクトをビルドするためのツールがあります。 これらのツールは、どのランタイムを選んでも同じです。 +.NET アプリは、1 つまたは複数の *.NET 実装*向けに開発され、実行されます。 .NET 実装には、.NET Framework、.NET Core、および Mono が含まれます。 すべての .NET 実装に共通する API 仕様があり、それを.NET Standard と呼びます。 この記事では、それぞれの概念について簡単に説明します。 -次の図は、これまでに説明した .NET の各コンポーネントの概要とそれらの関係を示したものです。 +## .NET Standard -![すべての .NET アーキテクチャ コンポーネント](media/components.png) +.NET Standard は、.NET 実装の基本クラス ライブラリで実装されている API のセットです。 さらに厳密に言うと、コードのコンパイル対象である統一されたコントラクトのセットを構成する .NET API の仕様です。 これらのコントラクトが各 .NET 実装に実装されています。 これにより異なる .NET 実装間で移植することができるため、実質的にコードをどこでも実行できるようになります。 -以降では、これらの主要コンポーネントのそれぞれについて簡単に説明します。 +.NET Standard は、[ターゲット フレームワーク](glossary.md#target-framework)でもあります。 コードが .NET Standard のバージョンをターゲットにする場合、.NET Standard のそのバージョンをサポートするすべての .NET 実装でそのコードを実行できます。 -## .NET Standard Library +.NET Standard とそのターゲットの設定方法については、「[.NET Standard](net-standard.md)」を参照してください。 -.NET Standard Library は、.NET ランタイムによって実装される API のセットです。 +## .NET 実装 -さらに厳密に言うと、コードのコンパイル対象である統一されたコントラクトのセットを構成する .NET API の仕様です。 これらのコントラクトには、各 .NET ランタイムの基になる実装があります。 これにより異なる .NET ランタイム間の移植性が可能になり、コードは効率的に "どこでも実行" できるようになります。 +各 .NET 実装には、次のコンポーネントが含まれています。 -.NET Standard Library はビルド ターゲットでもあり、.NET Standard と呼ばれます。 現在は .NET Standard 1.0 ～ 1.6 を対象にできます。 コードが .NET Standard のバージョンを対象にする場合、そのバージョンを実装するすべての .NET ランタイムで動作することが保証されます。 +- 1 つまたは複数のランタイム。 たとえば、CLR for .NET Framework、CoreCLR、CoreRT for .NET Core などです。 +- .NET Standard を実装し、他の API も実装する可能性があるクラス ライブラリ。 たとえば、.NET Framework 基本クラス ライブラリや .NET Core 基本クラス ライブラリなどです。 +- 必要に応じて、1 つまたは複数のアプリケーション フレームワーク。 たとえば、.NET Framework には、[ASP.NET](https://www.asp.net/)、[Windows フォーム](../framework/winforms/windows-forms-overview.md)、[Windows Presentation Foundation (WPF)](../framework/wpf/index.md) などです。 +- 必要に応じて、開発ツール。 一部の開発ツールは、複数の実装間で共有されます。 -.NET Standard Library および .NET Standard の対象化の詳細については、「[.NET Standard Library](library.md)」をご覧ください。 - -## .NET ランタイム - -Microsoft が積極的に開発し保守している主要な .NET ランタイムとしては、.NET Core、.NET Framework、Mono for Xamarin の 3 つがあります。 +Microsoft が積極的に開発し保守している主要な .NET 実装としては、.NET Core、.NET Framework、Mono、UWP の 4 つがあります。 ### .NET Core -.NET Core は、サーバーのワークロード用に最適化されたクロスプラットフォーム ランタイムです。 .NET Standard Library を実装しているので、.NET Standard を対象とするすべてのコードが .NET Core 上で実行できます。 ASP.NET Core およびユニバーサル Windows プラットフォーム (UWP) で使用されるランタイムです。 最新の機能を備え、効率的であり、大規模なサーバーとクラウドのワークロードを処理するように設計されています。 +.NET Core は、サーバーのワークロード用に最適化されたクロスプラットフォームの .NET 実装です。 最新の機能を備え、効率的であり、大規模なサーバーとクラウドのワークロードを処理するように設計されています。 .NET Standard を実装しているので、.NET Standard をターゲットとするすべてのコードを .NET Core 上で実行できます。 ASP.NET Core は、.NET Core 上で実行されます。 .NET Core について詳しくは、「[.NET Core](../core/index.md)」をご覧ください。 ### .NET Framework -.NET Framework は従来の .NET ランタイムであり、2002 年から使用されています。 既存の .NET 開発者が常に使用してきたものと同じ .NET Framework です。 .NET Standard Library を実装しているので、.NET Standard を対象とするすべてのコードが .NET Framework 上で実行できます。 Windows フォームと WPF での Windows デスクトップ開発用 API など、追加の Windows 固有 API が含まれます。 .NET Framework は、Windows デスクトップ アプリケーション開発用に最適化されています。 +.Net Framework は、2002 年からリリースされている元の .NET 実装です。 既存の .NET 開発者が常に使用してきたものと同じ .NET Framework です。 バージョン 4.5 以降では .NET Standard を実装しているので、.NET Standard をターゲットとするすべてのコードが .NET Framework 4.5 以降で実行できます。 Windows フォームと WPF での Windows デスクトップ開発用 API など、追加の Windows 固有 API が含まれます。 .NET Framework は、Windows デスクトップ アプリケーション開発用に最適化されています。 .NET Framework について詳しくは、「[.NET Framework](../framework/index.md)」をご覧ください。 -### Mono for Xamarin +### Mono + +Mono は、主に小規模なランタイムが必要な場合に使用される .NET 実装です。 Android、Mac、iOS、tvOS、および watchOS 上の Xamarin アプリケーションで利用されるランタイムで、フットプリントが小さいことに重点を置いています。 -Mono は、Xamarin アプリで使われるランタイムです。 .NET Standard Library を実装しているので、.NET Standard を対象とするすべてのコードが Xamarin アプリ上で実行できます。 iOS、Android、Xamarin.Forms、Xamarin.Mac 用の追加 API が含まれます。 iOS および Android でのモバイル アプリケーションの開発に最適化されています。 +現在公開されているすべての .NET Standard バージョンをサポートしています。 + +これまで Mono は .NET Framework の多数の API を実装し、Unix で人気の高い機能の一部をエミュレートしていました。 また、Unix のそのような機能に依存する .NET アプリケーションを実行するために使用されることもあります。 + +一般的に Mono は、Just-In-Time コンパイラと共に使用されますが、iOS のようなプラットフォームに使用される完全な静的コンパイラ (Ahead Of Time コンパイル) としても機能します。 Mono について詳しくは、[Mono のドキュメント](http://www.mono-project.com/docs/)をご覧ください。 -## .NET のツールと共通インフラストラクチャ +### ユニバーサル Windows プラットフォーム (UWP) -.NET 用のツールは、.NET の各実装に共通でもあります。 次に一例を挙げます。 +UWP は、モノのインターネット (IoT) 用に最新のタッチ対応の Windows アプリケーションとソフトウェアを構築するために使われる .NET 実装です。 PC、タブレット、ファブレット、携帯電話、Xbox など、ターゲットにする可能性があるさまざまな種類のデバイスを統一するように設計されています。 UWP は、一元的なアプリ ストア、実行環境 (AppContainer)、Win32 の代わりに使う Windows API のセット (WinRT) など、多くのサービスを提供します。 アプリは、C++、C#、VB.NET、および JavaScript で記述することができます。 C# と VB.NET を使うときは、.NET Core によって .NET API が提供されます。 + +UWP の詳細については、「[ユニバーサル Windows プラットフォームの紹介](https://docs.microsoft.com/windows/uwp/get-started/universal-application-platform-guide)」を参照してください。 + +## .NET ランタイム + +ランタイムは、マネージ プログラムの実行環境です。 OS は、ランタイム環境の一部ですが、.NET ランタイムの一部ではありません。 .NET ランタイムの例を次に示します。 + + - .NET Framework 用共通言語ランタイム (CLR) + - .NET Core 用共通言語ランタイム (CoreCLR) + - ユニバーサル Windows プラットフォーム用 .NET Native + - Xamarin.iOS、Xamarin.Android、Xamarin.Mac、Mono デスクトップ フレームワーク用ランタイム + +## .NET のツールと共通インフラストラクチャ -* .NET 言語とコンパイラ -* JIT やガベージ コレクターなどのランタイム コンポーネント -* .NET プロジェクト システム ("csproj"、"vbproj"、"fsproj" などと呼ばれることもあります) -* プロジェクトのビルドに使われるビルド エンジンである MSBuild -* Microsoft の .NET 用パッケージ マネージャーである NuGet -* .NET プロジェクト開発用のクロスプラットフォーム コマンドライン インターフェイスである .NET CLI -* オープン ソースのビルド オーケストレーション ツール (CAKE、FAKE など) +すべての .NET 実装と連携する多様なツールやインフラストラクチャ コンポーネントにアクセスできます。 その一部を次に示します。 -ここで重要なのは、アプリ開発に .NET のどの "フレーバー" を選択しても共通のツールとインフラストラクチャが多数存在することです。 +- .NET 言語とコンパイラ +- .NET プロジェクト システム (*.csproj*、*.vbproj*、および*.fsproj* ファイルに基づく) +- [MSBuild](/visualstudio/msbuild/msbuild) (プロジェクトのビルドに使用されるビルド エンジン) +- [NuGet](/nuget/) (Microsoft の .NET 用パッケージ マネージャー) +- オープン ソースのビルド オーケストレーション ツール ([CAKE](http://cakebuild.net/)、[FAKE](https://fake.build/) など) -## 次の手順 +## 関連項目 -詳細については、次のトピックを参照してください。 +[.NET Standard](net-standard.md) +[.NET Core のガイド](../core/index.md) +[.NET Framework ガイド](../framework/index.md) +[C# のガイド](../csharp/index.md) +[F# のガイド](../fsharp/index.md) +[VB.NET ガイド](../visual-basic/index.md) -* [.NET 標準ライブラリ](library.md) -* [.NET Core のガイド](../core/index.md) -* [.NET Framework ガイド](../framework/index.md) -* [C# のガイド](../csharp/index.md) -* [F# のガイド](../fsharp/index.md) -* [VB.NET ガイド](../visual-basic/index.md) diff --git a/docs/standard/delegates-lambdas.md b/docs/standard/delegates-lambdas.md index 06331fa72e7..098ab7aaa39 100644 --- a/docs/standard/delegates-lambdas.md +++ b/docs/standard/delegates-lambdas.md @@ -1,6 +1,6 @@ --- title: "デリゲートとラムダ" -description: "デリゲートとラムダ" +description: "特定のメソッド シグネチャを指定する型をデリゲートで定義する方法について説明します。このようなメソッドは、直接呼び出すか、別のメソッドに渡して呼び出すことができます。" keywords: .NET, .NET Core author: richlander ms.author: wiwagn @@ -10,10 +10,11 @@ ms.prod: .net ms.technology: dotnet-standard ms.devlang: dotnet ms.assetid: fe2e4b4c-6483-4106-a4b4-a33e2e306591 -translationtype: Human Translation -ms.sourcegitcommit: 90fe68f7f3c4b46502b5d3770b1a2d57c6af748a -ms.openlocfilehash: 1dbe9c72999c14e45910310eb0bbc91ebe9f1e4a -ms.lasthandoff: 03/02/2017 +ms.translationtype: HT +ms.sourcegitcommit: ef6d1bf9a7153f7adf635d13b4dcfb7647ed2e33 +ms.openlocfilehash: d04a158db4f97a0e37f8a92149a3f237ee2e5434 +ms.contentlocale: ja-jp +ms.lasthandoff: 08/21/2017 --- @@ -39,7 +40,6 @@ public class Program Console.WriteLine(rev("a string")); } } - ``` * 4 行目で特定のシグネチャのデリゲート型を作成しています。この場合、文字列パラメーターを取ってから文字列パラメーターを返すメソッドです。 @@ -47,7 +47,7 @@ public class Program * 13 行目では、メソッドが `Reverse` デリゲートに準拠する型に割り当てられます。 * 最後に、15 行目で元に戻す文字列を渡してデリゲートを呼び出します。 -開発プロセスを効率化するため、.NET にはプログラマが再利用できるデリゲート型のセットが含まれているため、新しい型を作成する必要はありません。 これらは `Func<>`、`Action<>`、および `Predicate<>` で、新しいデリゲート型を定義することなく、.NET API を通じてさまざまな場所で使用できます。 もちろん、これらの&3; つの間にはそのシグネチャで見られるように、いくつかの違いがあり、ほとんどがその用途に関係しています。 +開発プロセスを効率化するため、.NET にはプログラマが再利用できるデリゲート型のセットが含まれているため、新しい型を作成する必要はありません。 これらは `Func<>`、`Action<>`、および `Predicate<>` で、新しいデリゲート型を定義することなく、.NET API を通じてさまざまな場所で使用できます。 もちろん、これらの 3 つの間にはそのシグネチャで見られるように、いくつかの違いがあり、ほとんどがその用途に関係しています。 * `Action<>` は、デリゲートの引数を使用してアクションを実行する必要がある場合に使用されます。 * `Func<>` は、通常、変換が手元にあるときに使用されます。つまり、デリゲートの引数を異なる結果に変換する必要があります。 これの典型的な例が予測です。 @@ -71,7 +71,6 @@ public class Program Console.WriteLine(rev("a string")); } } - ``` この簡単な例では、Main() メソッドの外部で定義されているメソッドは、少し余分なようです。 これは、.NET Framework 2.0 で**匿名デリゲート**の概念が導入されたためです。 そのサポートにより、追加の型やメソッドを指定せずに、"インライン" デリゲートを作成することができます。 必要に応じて、デリゲートの定義を単純にインライン化します。 @@ -104,16 +103,15 @@ public class Program } } } - ``` 強調表示された行に注目してください。 ご覧のように、デリゲートの本体は、他のデリゲートと同じく、単なる式のセットです。 しかし、それを別の定義にする代わりに、`List` 型の `FindAll()` メソッドへの呼び出しでそれを_アド ホック_で導入しました。 ただし、この方法でも、破棄できる多くのコードがまだ残ります。 このような場合に**ラムダ式**が機能します。 -ラムダ式 (または略して単に「ラムダ」) は、最初に C# 3.0 で統合言語クエリ (LINQ) のコア ビルディング ブロックの 1 つとして導入されました。 これらは、デリゲートの使用の利便性を高める構文です。 これらは、シグネチャとメソッド本体を宣言しますが、デリゲートに割り当てられない限り、独自の正式な ID を持ちません。 デリゲートの場合とは異なり、これらはイベント登録の左側として、またはさまざまな Linq 句およびメソッドで、直接割り当てることができます。 +ラムダ式 (または略して単に "ラムダ") は、最初に C# 3.0 で統合言語クエリ (LINQ) のコア ビルディング ブロックの 1 つとして導入されました。 これらは、デリゲートの使用の利便性を高める構文です。 これらは、シグネチャとメソッド本体を宣言しますが、デリゲートに割り当てられない限り、独自の正式な ID を持ちません。 デリゲートの場合とは異なり、これらはイベント登録の左側として、またはさまざまな Linq 句およびメソッドで、直接割り当てることができます。 -ラムダ式はデリゲートを指定するもう&1; つの方法であるため、上記のサンプルを匿名デリゲートの代わりにラムダ式を使用するように書き換えることができるようになる必要があります。 +ラムダ式はデリゲートを指定するもう 1 つの方法であるため、上記のサンプルを匿名デリゲートの代わりにラムダ式を使用するように書き換えることができるようになる必要があります。 ```csharp public class Program @@ -136,7 +134,6 @@ public class Program } } } - ``` 強調表示された行を見ると、ラムダ式がどのようなものかがわかります。 繰り返しますが、これは、匿名デリゲートの使用に**非常に**便利な構文であるため、内部での動作は匿名デリゲートの動作と似ています。 @@ -153,7 +150,6 @@ public MainWindow() this.Title = "Loaded"; }; } - ``` ## 参考資料とリソース diff --git a/docs/standard/framework-libraries.md b/docs/standard/framework-libraries.md index 6c5ade802e9..a0b2937963b 100644 --- a/docs/standard/framework-libraries.md +++ b/docs/standard/framework-libraries.md @@ -1,6 +1,6 @@ --- title: "フレームワーク ライブラリ" -description: "フレームワーク ライブラリ" +description: "多くの一般的な型、アプリ固有の型、アルゴリズム、ユーティリティの機能の実装を提供しているライブラリについて説明します。" keywords: .NET, .NET Core author: richlander ms.author: ronpet @@ -10,9 +10,11 @@ ms.prod: .net ms.technology: dotnet-standard ms.devlang: dotnet ms.assetid: 7b77b6c1-8367-4602-bff3-91e4c05ac643 -translationtype: Human Translation -ms.sourcegitcommit: 9df468c7225dbf1e3317ea34bd8b2285361a69f4 -ms.openlocfilehash: f14e6552b2f59694f5cf877ee8ab76ffa026f18f +ms.translationtype: HT +ms.sourcegitcommit: 934373d61407c8cc19b7d6424898a582880f9c21 +ms.openlocfilehash: 9c38237a8e729155c443298814f4c98bec61016b +ms.contentlocale: ja-jp +ms.lasthandoff: 08/21/2017 --- @@ -30,33 +32,33 @@ BCL は最も基本的な型およびユーティリティの機能を提供し .NET には、すべてのプログラムで (さまざまな程度で) 使用されるプリミティブ型のセットが含まれています。 これらの型には、数値、文字列、バイト、および任意のオブジェクトなどのデータが含まれています。 C# 言語には、これらの型のキーワードが含まれています。 これらの型のサンプル セットを、一致する C# キーワードとともに以下に示します。 -* [System.Object](https://msdn.microsoft.com/library/system.object.aspx) ([object](https://msdn.microsoft.com/library/9kkx3h3c.aspx)): CLR 型システムの基底クラス。 型階層のルートです。 -* [System.Int16](https://msdn.microsoft.com/library/system.int16.aspx) ([short](https://msdn.microsoft.com/library/ybs77ex4.aspx)): 16 ビットの符号付き整数型。 符号なしの [UInt16](https://msdn.microsoft.com/library/system.uint16.aspx) も存在します。 -* [System.Int32](https://msdn.microsoft.com/library/system.int32.aspx) ([int](https://msdn.microsoft.com/library/5kzh1b5w.aspx)): 32 ビットの符号付き整数型。 符号なしの [UInt32](https://msdn.microsoft.com/library/x0sksh43.aspx) も存在します。 -* [System.Single](https://msdn.microsoft.com/library/system.single.aspx) ([float](https://msdn.microsoft.com/library/b1e65aza.aspx)): 32 ビット浮動小数点型。 -* [System.Decimal](https://msdn.microsoft.com/library/system.decimal.aspx) ([decimal](https://msdn.microsoft.com/library/364x0z75.aspx)): 128 ビットの 10 進数型。 -* [System.Byte](https://msdn.microsoft.com/library/system.byte.aspx) ([byte](https://msdn.microsoft.com/library/5bdb6693.aspx)): メモリのバイトを表す符号なし 8 ビット整数。 -* [System.Boolean](https://msdn.microsoft.com/library/system.boolean.aspx) ([bool](https://msdn.microsoft.com/library/c8f5xwh7.aspx)): 'true' または 'false' を表すブール型。 -* [System.Char](https://msdn.microsoft.com/library/system.char.aspx) ([char](https://msdn.microsoft.com/library/x9h8tsay.aspx)): Unicode 文字を表す 16 ビットの数値型。 -* [System.String](https://msdn.microsoft.com/library/system.string.aspx) ([string](https://msdn.microsoft.com/library/362314fe.aspx)): 一連の文字を表します。 `char[]` とは異なりますが、`string` で各 `char` にインデックスを付けることができます。 +* ([object](../csharp/language-reference/keywords/object.md)): CLR 型システムの最も基本の基底クラス。 型階層のルートです。 +* ([short](../csharp/language-reference/keywords/short.md)): 16 ビットの符号付き整数型。 符号なしの も存在します。 +* ([int](../csharp/language-reference/keywords/int.md)): 32 ビットの符号付き整数型。 符号なしの [UInt32](../csharp/language-reference/keywords/uint.md) も存在します。 +* ([float](../csharp/language-reference/keywords/float.md)): 32 ビット浮動小数点型。 +* ([decimal](../csharp/language-reference/keywords/decimal.md)): 128 ビットの 10 進数型。 +* ([byte](../csharp/language-reference/keywords/byte.md)): メモリのバイトを表す符号なし 8 ビット整数。 +* ([bool](../csharp/language-reference/keywords/bool.md)): `true` または `false` を表すブール型。 +* ([char](../csharp/language-reference/keywords/char.md)): Unicode 文字を表す 16 ビットの数値型。 +* ([string](../csharp/language-reference/keywords/string.md)): 一連の文字を表します。 `char[]` とは異なりますが、`string` で各 `char` にインデックスを付けることができます。 ## データ構造 .NET には、ほとんどの .NET アプリの主力となるデータ構造体のセットが含まれています。 これらはほとんどがコレクションですが、その他の型も含まれています。 -* [Array](https://msdn.microsoft.com/library/system.array.aspx): インデックスを使用してアクセスできる、厳密に型指定されたオブジェクトの配列を表します。 その構造ごとの固定サイズがあります。 -* [List](https://msdn.microsoft.com/library/6sh2ey19.aspx): インデックスを使用してアクセスできる、厳密に型指定されたオブジェクトのリストを表します。 必要に応じてサイズを自動調整します。 -* [Dictionary](https://msdn.microsoft.com/library/xfhwa508.aspx): -キーによってインデックスが作成される値のコレクションを表します。 値は、キーを使用してアクセスできます。 必要に応じてサイズを自動調整します。 -* [Uri](https://msdn.microsoft.com/library/system.uri.aspx): オブジェクト表現を可能にし、URI (Uniform Resource Identifier) の一部へ簡単にアクセスできるようにします。 -* [DateTime](https://msdn.microsoft.com/library/system.datetime.aspx): 通常、日付や時刻として表現される瞬間を表します。 +* : インデックスを使用してアクセスできる、厳密に型指定されたオブジェクトの配列を表します。 その構造ごとの固定サイズがあります。 +* : インデックスを使用してアクセスできる、厳密に型指定されたオブジェクトのリストを表します。 必要に応じてサイズを自動調整します。 +* : キーによってインデックスが作成される値のコレクションを表します。 値は、キーを使用してアクセスできます。 必要に応じてサイズを自動調整します。 +* : URI (Uniform Resource Identifier) のオブジェクト表現を可能にし、URI の一部へ簡単にアクセスできるようにします。 +* : 通常、日付や時刻として表現される瞬間を表します。 ## ユーティリティ API .NET には多くの重要なタスクの機能を提供するユーティリティ API のセットが含まれています。 -* [HttpClient](https://msdn.microsoft.com/library/system.net.http.httpclient.aspx): URI で識別されるリソースに HTTP 要求を送信し、そのリソースから HTTP 応答を受信するための基底クラスを提供する API です。 -* [XDocument](https://msdn.microsoft.com/library/system.xml.linq.xdocument.aspx): LINQ を使用して XML ドキュメントのロードと照会をするための API です。 -* [StreamReader](https://msdn.microsoft.com/library/system.io.streamreader.aspx): ファイル ([StreamWriter](https://msdn.microsoft.com/library/system.io.stringwriter.aspx)) を読み取るための API です。ファイルの書き込みに使用できます。 +* : URI で識別されるリソースに HTTP 要求を送信し、そのリソースから HTTP 応答を受信するための基底クラスを提供する API です。 +* : LINQ を使用して XML ドキュメントのロードと照会をするための API です。 +* : ファイル () を読み取るための API です。ファイルの書き込みに使用できます。 ## アプリ モデル API @@ -64,8 +66,3 @@ BCL は最も基本的な型およびユーティリティの機能を提供し * [ASP.NET](http://asp.net): Web サイトとサービスを構築するための Web フレームワークを提供します。 Windows、Linux、macOS でサポートされます (ASP.NET のバージョンによって異なります)。 - - - - - diff --git a/docs/standard/frameworks.md b/docs/standard/frameworks.md index 41a2271f12e..37062753672 100644 --- a/docs/standard/frameworks.md +++ b/docs/standard/frameworks.md @@ -1,156 +1,146 @@ --- -title: "ターゲット フレームワーク | Microsoft Docs" -description: ".NET Core アプリケーションおよびライブラリのターゲット フレームワークに関連する情報。" +title: "ターゲット フレームワーク" +description: ".NET Core アプリとライブラリのターゲット フレームワークについて説明します。" keywords: ".NET, .NET Core, フレームワーク, TFM" author: richlander ms.author: mairaw -ms.date: 04/27/2017 +ms.date: 07/23/2017 ms.topic: article ms.prod: .net ms.technology: dotnet-standard ms.devlang: dotnet ms.assetid: 6ef56a2e-593d-497b-925a-1e25bb6df2e6 -ms.translationtype: Machine Translation -ms.sourcegitcommit: 45835eb80642253f80ea630ae9db1ac766b72b9c -ms.openlocfilehash: 11c1f11e4f8354b7573d03e680cf4a8a16fa26d9 +ms.translationtype: HT +ms.sourcegitcommit: cf480ffd8e791e3416433f2d13b364743ba42938 +ms.openlocfilehash: 7f1189239f61bc55c5f517ee797e5148082ebbab ms.contentlocale: ja-jp -ms.lasthandoff: 05/11/2017 +ms.lasthandoff: 08/21/2017 --- # ターゲット フレームワーク -*フレームワーク*は、アプリとライブラリの作成に使用するオブジェクト、メソッド、ツールを定義します。 .NET Framework は、主に Windows オペレーティング システムを実行しているシステム上で実行されるアプリとライブラリの作成に使用されます。 .NET Core には、さまざまなオペレーティング システムで実行されるアプリとライブラリを構築できるフレームワークが含まれています。 - -*フレームワーク*と*プラットフォーム*という用語は、文章の中での使用方法によっては混乱することがあります。 さらに悪いことに、文脈によっては*プラットフォーム*という用語が別の意味になることもあります。 たとえば、".NET Core" という言葉は、アプリとライブラリを構築する文脈では ".NET Core フレームワーク" の意味で、アプリとライブラリ コードを実行する文脈では ".NET Core プラットフォーム" の意味で出現します。 *コンピューティング プラットフォーム*では、アプリケーションが*どこで、どのように*実行されるかについて説明します。 .NET Core は、[.NET Core 共通言語ランタイム (CoreCLR)](https://github.com/dotnet/coreclr) を使用してコードが実行されるので、これもプラットフォームです。 .NET Framework のフレームワーク オブジェクト、メソッド、およびツールを使用して開発されたアプリとライブラリ コードを実行するために[共通言語ランタイム (CLR)](clr.md) を使用している .NET Framework の場合も同様です。 "クロスプラットフォーム" という用語はドキュメントでよく見られますが、この用語を見かけたら、"クロスプラットフォーム システムとクロスアーカイブ (x86、x64、arm)" が通常、執筆者が伝えたいと思う意味なので、これを意味していると考えるのではないでしょうか。 - -フレームワークのオブジェクトとメソッドは、アプリケーション プログラミング インターフェイス (API) と呼ばれます。 フレームワークの API は、[Visual Studio](https://www.visualstudio.com/)、[Visual Studio for Mac](https://www.visualstudio.com/vs/visual-studio-mac/)、[Visual Studio Code](https://code.visualstudio.com/)、およびその他の統合開発環境 (IDE) とエディターで使用され、開発用の適切なオブジェクトとメソッドのセットを提供しています。 また、フレームワークは、アプリまたはライブラリで対象としているフレームワークに適したパッケージを確実に作成して使用するため、NuGet パッケージの運用と使用の両方で [NuGet](https://www.nuget.org/) でも使用されます。 - -*1 つのフレームワークを対象にする*か、複数のフレームワークを対象にすると、使用する API のセットと API のバージョンが決まります。 フレームワークを参照するには、製品名ごと、長い形式または短い形式のフレームワーク名ごと、またはファミリごとという複数の方法があります。 - -## フレームワークを参照する - -フレームワークを参照する方法は複数あります。そのほとんどについてこの .NET Core ドキュメントで使用します。 たとえば .NET Framework 4.6.2 を使用する場合は、次の形式が使用されます。 - -**成果物を参照する** - -.NET プラットフォームまたはランタイムを参照することができます。 両方とも有効です。 - -* .NET Framework 4.6.2 -* .NET 4.6.2 - -**フレームワークを参照する** - -長い形式または短い形式の TFM を使用して、フレームワークまたはフレームワークの対象を参照することができます。 両方とも有効です。 - -* `.NETFramework,Version=4.6.2` -* `net462` - -**フレームワークのファミリを参照する** - -長い形式または短い形式のフレームワーク ID を使用して、フレームワークのファミリを参照することができます。 両方とも有効です。 - -* `.NETFramework` -* `net` - -## 最新のフレームワークバージョン - -次の表では、使用できるフレームワークのセットと、これらが参照される方法、およびこれらが実装する [.NET Standard Library](library.md) のバージョンを定義します。 これらのフレームワークのバージョンは、最新の安定したバージョンです。 プレリリース バージョンは記載されていません。 - -| フレームワーク | [最新バージョン] | ターゲット フレームワーク モニカー (TFM) | コンパクトなターゲット フレームワーク モニカー (TFM) | .NET Standard バージョン | メタパッケージ | -| :-------------------: | :------------: | :----------------------------: | :------------------------------------: | :-------------------: | :---------: | -| .NET Standard | 1.6.1 | .NETStandard,Version=1.6 | netstandard1.6 | N/A | [NETStandard.Library](https://www.nuget.org/packages/NETStandard.Library) | -| .NET Core アプリケーション | 1.1.1 | .NETCoreApp,Version=1.1 | netcoreapp1.1 | 1.6 | [Microsoft.NETCore.App](https://www.nuget.org/packages/Microsoft.NETCore.App) | -| .NET Framework | 4.6.2 | .NETFramework,Version=4.6.2 | net462 | 1.5 | N/A | - -## サポートされるフレームワーク - -通常、フレームワークは、短いターゲット フレームワーク モニカー (*TFM*) で参照されます。 .NET Standard の場合、1 つの参照で複数のフレームワークを参照できるように、*TxM* に汎用化されています。 NuGet クライアントは次のフレームワークをサポートしています。 同等のものがかっこ (`[]`) 内に示されます。 - -| 名前 | 省略形 | TFM/TxM | -| -------------------------- | ------------ | -------------------------------------------- | -| .NET Standard | netstandard | netstandard1.0 | -| | | netstandard1.1 | -| | | netstandard1.2 | -| | | netstandard1.3 | -| | | netstandard1.4 | -| | | netstandard1.5 | -| | | netstandard1.6 | -| .NET Core | netcoreapp | netcoreapp1.0 | -| | | netcoreapp1.1 | -| .NET Framework | net | net11 | -| | | net20 | -| | | net35 | -| | | net40 | -| | | net403 | -| | | net45 | -| | | net451 | -| | | net452 | -| | | net46 | -| | | net461 | -| | | net462 | -| Windows ストア | netcore | netcore [netcore45] | -| | | netcore45 [win、win8] | -| | | netcore451 [win81] | -| .NET Micro Framework | netmf | netmf | -| Silverlight | sl | sl4 | -| | | sl5 | -| Windows Phone | wp | wp [wp7] | -| | | wp7 | -| | | wp75 | -| | | wp8 | -| | | wp81 | -| | | wpa81 | -| ユニバーサル Windows プラットフォーム | uap | uap [uap10.0] | -| | | uap10.0 [win10] [netcore50] | - -## 使用されていないフレームワーク - -次のフレームワークは使用されていません。 これらのフレームワークを対象とするパッケージは、指定されている代替のフレームワークに移行するようにしてください。 - -| 使用されていないフレームワーク | Replacement | -| -------------------- | ----------- | -| aspnet50 | netcoreapp | -| aspnetcore50 | | -| dnxcore50 | | -| dnx | | -| dnx45 | | -| dnx451 | | -| dnx452 | | -| dotnet | netstandard | -| dotnet50 | | -| dotnet51 | | -| dotnet52 | | -| dotnet53 | | -| dotnet54 | | -| dotnet55 | | -| dotnet56 | | -| netcore50 | uap10.0 | -| win | netcore45 | -| win8 | netcore45 | -| win81 | netcore451 | -| win10 | uap10.0 | -| winrt | netcore45 | - -## 優先順位 - -フレームワークの番号は相互の関連性や互換性を示していますが、必ずしも同一ではありません。 - -| フレームワーク | 使用可能 | -| -------------------------------- | --------- | -| uap (ユニバーサル Windows プラットフォーム) | win81 | -| | wpa81 | -| | netcore50 | -| win (Windows ストア) | winrt | -| | winrt45 | - -## .NET Standard - -[.NET Standard](https://github.com/dotnet/standard) は、バイナリ互換フレームワーク間の参照を簡易化し、1 つのターゲット フレームワークで複数のフレームワークの組み合わせを参照できます。 詳細については、「[.NET Standard Library](library.md)」を参照してください。 - -[NuGet Tools の Get Nearest Framework Tool](http://nugettoolsdev.azurewebsites.net/) では、プロジェクトのフレームワークに基づいて、パッケージ内で使用できる複数のフレームワーク アセットから、1 つのフレームワークを選択するために使用する NuGet ロジックをシミュレートしています。 このツールを使用するには、1 つのプロジェクト フレームワークと 1 つ以上のパッケージ フレームワークを入力します。 **[送信]** ボタンを選択します。 列挙したパッケージのフレームワークが、指定したプロジェクトのフレームワークと互換性があるかどうかが表示されます。 - -## ポータブル クラス ライブラリ - -ポータブル クラス ライブラリの詳細については、NuGet ドキュメントの「*Target Framework*」(ターゲット フレームワーク) の「[Portable Class Libraries](https://docs.microsoft.com/nuget/schema/target-frameworks#portable-class-libraries)」(ポータブル クラス ライブラリ) セクションを参照してください。 Stephen Cleary がサポートされる PCL を列挙するツールを作成しています。 詳細については、「[Framework Profiles in .NET](http://blog.stephencleary.com/2012/05/framework-profiles-in-net.html)」(.NET のフレームワーク プロファイル) を参照してください。 +アプリまたはライブラリでフレームワークをターゲットに設定するときは、アプリまたはライブラリで使用できるようにする API のセットを指定します。 プロジェクト ファイルでターゲット フレームワークを指定するには、ターゲット フレームワーク モニカー (TFM) を使います。 + +アプリまたはライブラリでは、[.NET Standard](~/docs/standard/net-standard.md) のバージョンをターゲットにできます。 .NET Standard のバージョンは、.NET のすべての実装で標準化された API のセットを表します。 たとえば、ライブラリは、.NET Standard 1.6 をターゲットにして、.NET Core と .NET Framework で機能する API に同じコードベースを使ってアクセスできます。 + +また、アプリまたはライブラリは、.NET の特定の実装をターゲットにして、実装固有の API にアクセスすることもできます。 たとえば、Xamarin.iOS (たとえば `Xamarin.iOS10`) をターゲットにするアプリは Xamarin が提供する iOS 10 用の iOS API ラッパーにアクセスでき、ユニバーサル Windows プラットフォーム (UWP、`uap10.0`) をターゲットにするアプリは Windows 10 を実行するデバイス用にコンパイルできる API にアクセスできます。 + +一部のターゲット フレームワーク (.NET Framework など) では、API はフレームワークがシステムにインストールするアセンブリによって定義され、アプリケーション フレームワーク API (たとえば ASP.NET) を含む場合があります。 + +パッケージ ベースのターゲット フレームワーク (.NET Standard、.NET Core など) では、API はアプリまたはライブラリに含まれるパッケージによって定義されます。 "*メタパッケージ*" は、それ独自の内容はなく、依存するもの (他のパッケージ) のリストを保持している NuGet パッケージです。 NuGet パッケージ ベースのターゲット フレームワークでは、全体としてフレームワークを構成するすべてのパッケージを参照するメタパッケージが暗黙的に指定されます。 + +## 最新のターゲット フレームワークのバージョン + +次の表では、最も一般的なターゲット フレームワーク、それらの参照方法、およびそれらが実装する [.NET Standard](~/docs/standard/net-standard.md) のバージョンを定義します。 これらのターゲット フレームワークのバージョンは、最新の安定したバージョンです。 プレリリース バージョンは記載されていません。 ターゲット フレームワーク モニカー (TFM) は、.NET アプリまたはライブラリのターゲット フレームワークを指定するための標準化されたトークン形式です。 + +| [対象とする Framework] | [最新バージョン] | ターゲット フレームワーク モニカー (TFM) | .NET Standard バージョン | メタパッケージ | +| :-------------------: | :------------: | :----------------------------: | :-------------------: | :---------: | +| .NET Standard | 1.6.1 | netstandard1.6 | N/A | [NETStandard.Library](https://www.nuget.org/packages/NETStandard.Library) | +| .NET Core アプリケーション | 1.1.2 | netcoreapp1.1 | 1.6 | [Microsoft.NETCore.App](https://www.nuget.org/packages/Microsoft.NETCore.App) | +| .NET Framework | 4.7 | net47 | 1.5 | N/A | + +## サポートされるターゲット フレームワークのバージョン + +ターゲット フレームワークは、通常、TFM によって参照されます。 次の表では、.NET Core SDK および NuGet クライアントによってサポートされるターゲット フレームワークを示します。 同等のものがかっこ内に示されています。 たとえば、`win81` は `netcore451` と同等の TFM です。 + +| [対象とする Framework] | TFM | +| -------------------------- | --- | +| .NET Standard | netstandard1.0
netstandard1.1
netstandard1.2
netstandard1.3
netstandard1.4
netstandard1.5
netstandard1.6 | +| .NET Core | netcoreapp1.0
netcoreapp1.1 | +| .NET Framework | net11
net20
net35
net40
net403
net45
net451
net452
net46
net461
net462
net47 | +| Windows ストア | netcore [netcore45]
netcore45 [win] [win8]
netcore451 [win81] | +| .NET Micro Framework | netmf | +| Silverlight | sl4
sl5 | +| Windows Phone | wp [wp7]
wp7
wp75
wp8
wp81
wpa81 | +| ユニバーサル Windows プラットフォーム | uap [uap10.0]
uap10.0 [win10] [netcore50] | + +## ターゲット フレームワークを指定する方法 + +ターゲット フレームワークはプロジェクト ファイルで指定します。 単一のターゲット フレームワークを指定するときは、**TargetFramework** 要素を使います。 次のコンソール アプリのプロジェクト ファイルでは、.NET Core 1.1 をターゲットにする方法が示されています。 + +```xml + + + + Exe + netcoreapp1.1 + + + +``` + +複数のターゲット フレームワークを指定するときは、各ターゲット フレームワークに対するアセンブリを条件付きで参照できます。 コードでは、プリプロセッサ シンボルと *if-then-else* ロジックを使うことで、これらのアセンブリに対して条件付きでコンパイルできます。 + +次のライブラリ プロジェクト ファイルは、.NET Standard (`netstandard1.4`) の API と、.NET Framework (`net40` および `net45`) の API をターゲットにしています。 ターゲット フレームワークが複数あるときは、複数形の **TargetFrameworks** 要素を使います。 ライブラリが 2 つの .NET Framework TFM に対してコンパイルされるときに `Condition` 属性で実装固有のパッケージを指定する方法に注意してください。 + +```xml + + + + netstandard1.4;net40;net45 + + + + + + + + + + + + + + +``` + +ライブラリまたはアプリ内では、各ターゲット フレームワーク用にコンパイルするための条件付きコードを記述します。 + +```csharp +public class MyClass +{ + static void Main() + { +#if NET40 + Console.WriteLine("Target framework: .NET Framework 4.0"); +#elif NET45 + Console.WriteLine("Target framework: .NET Framework 4.5"); +#else + Console.WriteLine("Target framework: .NET Standard 1.4"); +#endif + } +} +``` + +ビルド システムは、「[サポートされるターゲット フレームワークのバージョン](#supported-target-framework-versions)」の表で示されているターゲット フレームワークを表すプリプロセッサ シンボルを認識します。 .NET Standard または .NET Core の TFM を表すシンボルを使うときは、ドットをアンダースコアに置き換え、小文字を大文字に変更します (たとえば、`netstandard1.4` のシンボルは `NETSTANDARD1_4` です)。 + +.NET Core ターゲット フレームワークのプリプロセッサ シンボルの完全な一覧を次に示します。 + +[!INCLUDE [Preprocessor symbols](~/includes/preprocessor-symbols.md)] + +## 使用されていないターゲット フレームワーク + +次のターゲット フレームワークは使用されていません。 これらのターゲット フレームワークをターゲットにするパッケージは、指定されている代替フレームワークに移行する必要があります。 + +| 使用されていない TFM | Replacement | +| ------------------------------------------------------------------------------------------ | ----------- | +| aspnet50
aspnetcore50
dnxcore50
dnx
dnx45
dnx451
dnx452 | netcoreapp | +| dotnet
dotnet50
dotnet51
dotnet52
dotnet53
dotnet54
dotnet55
dotnet56 | netstandard | +| netcore50 | uap10.0 | +| win | netcore45 | +| win8 | netcore45 | +| win81 | netcore451 | +| win10 | uap10.0 | +| winrt | netcore45 | + +## 関連項目 + +[パッケージ、メタパッケージ、フレームワーク](~/docs/core/packages.md) +[クロス プラットフォーム ツールによるライブラリの開発](~/docs/core/tutorials/libraries.md) +[.NET Standard](~/docs/standard/net-standard.md) +[.NET Core バージョン管理](~/docs/core/versions/index.md) +[dotnet/standard GitHub リポジトリ](https://github.com/dotnet/standard) +[NuGet Tools GitHub リポジトリ](https://github.com/joelverhagen/NuGetTools) +[.NET のフレームワーク プロファイル](http://blog.stephencleary.com/2012/05/framework-profiles-in-net.html) diff --git a/docs/standard/generics.md b/docs/standard/generics.md index d1d30f52c97..6b7733c64b0 100644 --- a/docs/standard/generics.md +++ b/docs/standard/generics.md @@ -1,6 +1,6 @@ --- title: "ジェネリック型 (ジェネリック) の概要" -description: "ジェネリック型 (ジェネリック) の概要" +description: "実際のデータ型をいじらずにタイプ セーフなデータ構造を定義できるコード テンプレートとしてジェネリックがどのように機能するかを説明します。" keywords: .NET, .NET Core author: kuhlenh ms.author: wiwagn @@ -10,10 +10,11 @@ ms.prod: .net ms.technology: dotnet-standard ms.devlang: dotnet ms.assetid: a315b111-8e48-446c-ab19-acb6405894a7 -translationtype: Human Translation -ms.sourcegitcommit: 90fe68f7f3c4b46502b5d3770b1a2d57c6af748a -ms.openlocfilehash: 9827f9f37ce198b23bfd4e5fbca41cd86d5885a4 -ms.lasthandoff: 03/02/2017 +ms.translationtype: HT +ms.sourcegitcommit: 934373d61407c8cc19b7d6424898a582880f9c21 +ms.openlocfilehash: 08b8de2fe17a0032a1c1180667f39b1d6ce0feb6 +ms.contentlocale: ja-jp +ms.lasthandoff: 08/21/2017 --- @@ -21,7 +22,7 @@ ms.lasthandoff: 03/02/2017 暗黙的か明示的かに関わらず、C# では常にジェネリックを使用します。 C# で LINQ を使用していると、IEnumerable を操作することがあります。 または、Entity Framework を使用してデータベースと通信するための "汎用リポジトリ" のオンライン サンプルでは、ほとんどのメソッドが IQueryable を返すことに気付きます。 これらの例の **T** とは何で、なぜそこにあるのでしょうか。 -.NET Framework 2.0 で最初に導入されたジェネリックには、C# 言語と共通言語ランタイム (CLR) の両方に関連する変更が含まれました。 **ジェネリック**は本質的に "コード テンプレート" であり、開発者は実際のデータ型をいじらずに[タイプ セーフな](https://msdn.microsoft.com/library/hbzz1a9a.aspx)データ構造を定義できます。 たとえば、`List` は[ジェネリック コレクション](https://msdn.microsoft.com/library/System.Collections.Generic.aspx)であり、`List`、`List`、`List` などの任意の型で宣言および使用できます。 +.NET Framework 2.0 で最初に導入されたジェネリックには、C# 言語と共通言語ランタイム (CLR) の両方に関連する変更が含まれました。 **ジェネリック**は本質的に "コード テンプレート" であり、開発者は実際のデータ型をいじらずに[タイプ セーフな](https://msdn.microsoft.com/library/hbzz1a9a.aspx)データ構造を定義できます。 たとえば、`List` は[ジェネリック コレクション](xref:System.Collections.Generic)であり、`List`、`List`、`List` などの任意の型で宣言および使用できます。 重点および ジェネリックの有用性を 理解するためには、ジェネリックを追加する前と後の特定のクラスを調べる必要があります。 `ArrayList` を見てみます。 C# 1.0 では、`ArrayList` 要素は `object` 型でした。 これは、追加されたすべての要素は暗黙的に `object` に変換されることを意味します。リストから要素を読み取るときも同じです (この処理はそれぞれ、[ボックス化](https://msdn.microsoft.com/library/yz2be5wk.aspx)およびボックス化解除と呼ばれます)。 ボックス化とボックス化解除はパフォーマンスに影響を与えます。 そうはいっても、コンパイル時にリスト内のデータの実際の型を確認する方法はありません。 これは脆弱なコードを助長します。 ジェネリックは、リストの各インスタンスに含まれるデータの型の追加情報を提供することによってこの問題を解決します。 簡単に言うと、`List` には整数だけを追加でき、`List` には Persons だけを追加できます。 @@ -57,7 +58,6 @@ ms.lasthandoff: 03/02/2017 } } } - ``` このプログラムの出力は、次のようになります。 @@ -65,7 +65,6 @@ ms.lasthandoff: 03/02/2017 ```console Generic Sort: System.Collections.Generic.List\`1[System.Int32] Time taken: 0.0789ms Non-Generic Sort: System.Collections.ArrayList Time taken: 2.4324ms - ``` 最初にわかるのは、非ジェネリック リストよりジェネリック リストの方が並べ替えがはるかに高速であるということです。 また、ジェネリック リストの型が具体的 ([System.Int32]) であるのに対して、非ジェネリック リストの型は一般的であることもわかります。 ジェネリック `List` の場合はランタイムはそれを int 型と認識してメモリの整数配列にリストの要素を格納できるのに対し、非ジェネリック `ArrayList` の場合はメモリではオブジェクト配列に格納されるので各リスト要素をオブジェクトとしてキャストする必要があります。 この例にわかるように、余分なキャストに時間がかかり、リストの並べ替え速度が低下します。 diff --git a/docs/standard/get-started.md b/docs/standard/get-started.md new file mode 100644 index 00000000000..417a1340b17 --- /dev/null +++ b/docs/standard/get-started.md @@ -0,0 +1,42 @@ +--- +title: ".NET の使用を開始する" +description: "言語とプラットフォームの観点から、.NET の使用開始に関するさまざまな記事の一覧を示します。" +keywords: ".NET, 使用開始, C#, F#, Visual Basic" +author: cartermp +ms.author: mairaw +ms.date: 05/01/2017 +ms.topic: article +ms.prod: .net +ms.technology: dotnet-standard +ms.devlang: dotnet +ms.assetid: 81c07080-acdf-4aef-a66d-0ab52fab2c04 +ms.translationtype: HT +ms.sourcegitcommit: 3a25c1c3b540bac8ef963a8bbf708b0700c3e9e2 +ms.openlocfilehash: 29f69cfa5b80f2a73f90e31d58f6b298f3c7ee7b +ms.contentlocale: ja-jp +ms.lasthandoff: 08/21/2017 + +--- + +# 開始するには + +.NET を使い始めるにはさまざまな方法があります。 .NET は巨大なプラットフォームであるため、このドキュメントには異なる観点から .NET の使用開始方法を示す複数の記事があります。 + +## .NET 言語の使用を開始する + +* 「[C# Getting Started](../csharp/getting-started/index.md)」 (C# 入門) の記事と「[C# のチュートリアル](../csharp/tutorials/index.md)」では、主に C# を使って開発を始めるさまざまな方法が示されています。 + +* 「[F# Getting Started](../fsharp/tutorials/getting-started/index.md)」 (F# 入門) のチュートリアルでは、F# を使う主要な方法として、Visual Studio、Visual Studio のコード、コマンドライン ツールの 3 種類が説明されています。 + +* 「[Visual Basic の概要](../visual-basic/getting-started/index.md)」の記事では、Visual Studio での Visual Basic の使用に関するガイドが提供されています。 + +## .NET Core の使用を開始する + +* 「[.NET Core の概要](../core/get-started.md)」では、異なるオペレーティング システムで .NET Core の使用を始める方法、およびさまざまなツールの使用に関する記事の概要が提供されています。 + +* 「[.NET Core チュートリアル](../core/tutorials/index.md)」では、さまざまなオペレーティング システムとツールで .NET Core の使用を始める方法について詳しく説明されています。 + +## .NET Framework で Docker の使用を開始する + +「[.NET Framework で Docker を使用する](../framework/docker/index.md)」では、Windows Docker コンテナーで .NET Framework を使用する方法が示されています。 + diff --git a/docs/standard/glossary.md b/docs/standard/glossary.md new file mode 100644 index 00000000000..89755f42fc6 --- /dev/null +++ b/docs/standard/glossary.md @@ -0,0 +1,280 @@ +--- +title: ".NET 用語集" +description: ".NET のドキュメントで使われている用語からいくつか選択してその意味を説明します。" +keywords: ".NET 用語集, .NET ディクショナリ, .NET の用語, .NET プラットフォーム, .NET Framework, .NET ランタイム" +author: tdykstra +ms.author: tdykstra +ms.date: 07/08/2017 +ms.topic: article +ms.prod: .net +ms.technology: dotnet-standard +ms.devlang: dotnet +ms.translationtype: HT +ms.sourcegitcommit: f8cf12317f1f0163028db003ff31604480da5d1c +ms.openlocfilehash: d9a1b1aa2b19e80b885a2da87746667bff04e234 +ms.contentlocale: ja-jp +ms.lasthandoff: 08/21/2017 + +--- + +# .NET 用語集 + +この用語集の主な目的は、.NET のドキュメントで定義なしに頻繁に出現する用語と頭字語の意味を明確にすることです。 + +## AOT + +Ahead Of Time コンパイラ。 + +[JIT](#jit) と同様に、このコンパイラも [IL](#il) をマシン コードに変換します。 JIT コンパイルとは異なり、AOT コンパイルはアプリケーションが実行される前に行われ、通常は、別のコンピューターで実行されます。 AOT ツール チェーンは実行時にコンパイルしないので、コンパイルに費やされる時間を最小限に抑える必要はありません。 つまり、より多くの時間を最適化に費やすことができます。 AOT のコンテキストはアプリケーション全体であるため、AOT コンパイラはモジュール間のリンクとプログラム全体の分析も実行します。これは、すべての参照が追跡されて、1 つの実行可能ファイルが生成されることを意味します。 + +## ASP.NET + +.NET Framework に付属している ASP.NET の元の実装。 + +ASP.NET は、ASP.NET Core を含む ASP.NET の両方の実装を指す包括的な用語として使われることがあります。 どちらを意味するかはコンテキストによって決まります。 + +「[ASP.NET](/aspnet/#pivot=aspnet)」をご覧ください。 + +## ASP.NET Core + +.NET Core 上に構築された ASP.NET のクロスプラットフォームで高パフォーマンスなオープン ソースの実装。 + +「[ASP.NET Core](/aspnet/#pivot=core)」をご覧ください。 + +## アセンブリ + +アプリまたは他のアセンブリから呼び出すことができる API のコレクションを含む *.dll* ファイル。 + +.NET アセンブリは型のコレクションです。 アセンブリには、インターフェイス、クラス、構造体、列挙型、およびデリゲートが含まれています。 プロジェクトの *bin* フォルダー内のアセンブリは、"*バイナリ*" と呼ばれることもあります。 「[ライブラリ](#library)」もご覧ください。 + +## CLR + +共通言語ランタイム (Common Language Runtime)。 + +厳密な意味はコンテキストによって異なりますが、通常は、.NET Framework のランタイムを指します。 CLR は、メモリの割り当てと管理を行います。 CLR は、アプリの実行だけでなく、JIT コンパイラを使って実行時にコードを生成してコンパイルする仮想マシンでもあります。 現在の Microsoft CLR の実装は Windows だけです。 + +## CoreCLR + +.NET Core 共通言語ランタイム (.NET Core Common Language Runtime)。 + +この CLR は、CLR と同じコード ベースから作成されます。 もともと、CoreCLR は Silverlight のランタイムであり、複数のプラットフォーム (具体的には Windows と OS X) で実行するように設計されていました。現在の CoreCLR は .NET Core の一部であり、CLR の簡素化されたバージョンを表します。 まだクロスプラットフォーム ランタイムであり、多くの Linux ディストリビューションのサポートを含むようになっています。 CoreCLR は、JIT とコード実行機能を備えた仮想マシンでもあります。 + +## CoreFX + +.NET Core 基本クラス ライブラリ (BCL) + +System.* (および限られた範囲の Microsoft.*) 名前空間を構成するライブラリのセット。 BCL は汎用の下位レベル フレームワークであり、ASP.NET Core などの上位レベル アプリケーション フレームワークはそれを基にして構築されています。 .NET Core BCL のソース コードは [CoreFX リポジトリ](https://github.com/dotnet/corefx)に含まれます。 ただし、.NET Core API の大部分は .NET Framework でも使うことができるため、CoreFX は .NET Framework BCL が分岐したものと考えることができます。 + +## CoreRT + +.NET Core ランタイム。 + +CLR/CoreCLR とは異なり、CoreRT は仮想マシンではありません。つまり、[JIT](#jit) が含まれないため、実行時にコードを生成して実行する機能はありません。 ただし、[GC](#gc) およびランタイム型識別 (RTTI) とリフレクションの機能は備えています。 ただ、CoreRT の型システムはリフレクション用のメタデータが必要ないように設計されています。 これにより、[AOT](#aot) ツール チェーンで余分なメタデータのリンクを削除し、(さらに重要なこととして) アプリが使っていないコードを特定することができます。 CoreRT は開発中です。 + +「[Intro to .NET Native and CoreRT](https://github.com/dotnet/corert/blob/master/Documentation/intro-to-corert.md)」(.NET Native と CoreRT の概要) をご覧ください。 + +## エコシステム + +特定のテクノロジ用のアプリケーションを構築して実行するために使われるすべての実行時ソフトウェア、開発ツール、およびコミュニティ リソース。 + +".NET エコシステム" という用語は ".NET スタック" などの用語と似ていますが、サードパーティのアプリとライブラリを含む点が異なります。 文章での使用例を次に示します。 + +- "[.NET Standard](#net-standard) の背後にある意図は、.NET エコシステムの高度な統一性を確立することです。" + +## フレームワーク + +一般に、特定のテクノロジに基づくアプリケーションの開発と展開を容易にする API の包括的なコレクション。 この一般的な意味でのアプリケーション フレームワークの例としては、ASP.NET Core や Windows フォームなどがあります。 「[ライブラリ](#library)」もご覧ください。 + +以下の語句で使われている "フレームワーク" という用語には、さらに具体的な技術的意味があります。 +* [.NET Framework](#net-framework) +* [ターゲット フレームワーク](#target-framework) +* [TFM (ターゲット フレームワーク モニカー)](#tfm) + +既存のドキュメントでは、[.NET の実装](#implementation-of-net)を指して "フレームワーク" が使われていることがあります。 たとえば、.NET Core をフレームワークと呼んでいる場合があります。 このような混乱を招く使用法をドキュメントから除去することが予定されています。 + +## GC + +ガベージ コレクター (Garbage Collector)。 + +ガベージ コレクターは、自動メモリ管理の実装です。 GC は、使われなくなったオブジェクトによって占有されているメモリを解放します。 + +「[ガベージ コレクション](garbage-collection/index.md)」をご覧ください。 + +## IL + +中間言語 (Intermediate Language)。 + +C# などの高レベル .NET 言語は、中間言語 (IL) と呼ばれるハードウェアに依存しない命令セットにコンパイルされます。 IL は、MSIL (Microsoft IL) や CIL (Common IL) などと呼ばれることもあります。 + +## JIT + +Just-In-Time コンパイラ。 + +[AOT](#aot) と同様に、このコンパイラは [IL](#il) をプロセッサが理解するマシン コードに変換します。 AOT とは異なり、JIT のコンパイルはオンデマンドで行われ、コードを実行する必要があるコンピューター上で実行されます。 JIT コンパイルはアプリケーションの実行中に行われるため、コンパイル時間は実行時間の一部になります。 したがって、JIT コンパイラでは、コードの最適化に要する時間と、結果のコードによって得られる時間の節約のバランスを考える必要があります。 ただし、JIT は実際のハードウェアを認識するので、開発者はさまざまな実装を出荷する必要がなくなります。 + +## .NET の実装 + +.NET の実装には次のものが含まれます。 + +- 1 つまたは複数のランタイム。 たとえば、CLR、CoreCLR CoreRT などです。 +- .NET Standard の 1 つのバージョンを実装し、他の API を含むことができるクラス ライブラリ。 たとえば、.NET Framework 基本クラス ライブラリや .NET Core 基本クラス ライブラリなどです。 +- 必要に応じて、1 つまたは複数のアプリケーション フレームワーク。 たとえば、.NET Framework には ASP.NET、Windows フォーム、WPF が含まれます。 +- 必要に応じて、開発ツール。 一部の開発ツールは、複数の実装間で共有されます。 + +.NET の実装の例: + +- [.NET Framework](#net-framework) +- [.NET Core](#net-core) +- [ユニバーサル Windows プラットフォーム (UWP)](#uwp) + +## ライブラリ + +アプリまたは他のライブラリで呼び出すことができる API のコレクション。 .NET ライブラリは 1 つ以上の[アセンブリ](#assembly)で構成されます。 + +ライブラリと[フレームワーク](#framework)は同義語として使われることがよくあります。 + +## メタパッケージ + +それ自体のライブラリを持たず、依存するもののリストのみを含む NuGet パッケージ。 含まれるパッケージは、必要に応じて、ターゲット フレームワーク用の API を確立できます。 + +「[パッケージ、メタパッケージ、フレームワーク](../core/packages.md)」をご覧ください。 + +## Mono + +.NET Framework に代わるオープン ソース。 + +Mono は、.NET Framework の最初のリリースとほぼ同時に始まりました。 .NET Framework はオープン ソースではなかったため、Mono は何もない状態から始めることを余儀なくされ、したがって、共有コードを持たない .NET Framework の再実装になっています。 + +.NET Core を MIT ライセンスでリリースしたとき、Microsoft は[MIT ライセンスの下で .NET Framework の大きなチャンク](https://github.com/microsoft/referencesource)もリリースしました。 これにより、Mono コミュニティは、.NET Framework で使われているものと同じコードを使って、ギャップを埋め、動作の違いを回避できるようになりました。 + +Mono は、主に、.NET アプリケーションを Linux および macOS で実行するために使われています。 Mono は他のプラットフォームにも移植されています。Mono の「[Supported Platforms](http://www.mono-project.com/docs/about-mono/supported-platforms/)」(サポートされているプラットフォーム) をご覧ください。 Mono には WinForms、ASP.NET、`System.Drawing` の実装があります (ただし、必ずしも完全ではありません)。 + +## .NET + +[.NET Standard](#net-standard) とすべての [.NET の実装](#implementation-of-net)およびワークロードを表す包括的な用語。 常にすべて大文字で表し、".Net" とは表記されません。 + +「[.NET ガイド](index.md)」をご覧ください。 + +## .NET Core + +.NET のクロスプラットフォームで高パフォーマンスなオープン ソースの実装。 Core 共通言語ランタイム (CoreCLR)、Core AOT ランタイム (CoreRT、開発中)、Core 基本クラス ライブラリ、Core SDK が含まれます。 + +「[.NET Core](../core/index.md)」をご覧ください。 + +## .NET Core CLI + +.NET Core アプリケーション開発用のクロスプラットフォーム ツールチェーン。 + +「[.NET Core コマンドライン インターフェイス (CLI) ツール](../core/tools/index.md)」をご覧ください。 + +## .NET Core SDK + +一連のライブラリとツールであり、開発者はこれを利用して .NET Core のアプリケーションやライブラリを作成できます。 アプリ構築用の [.NET Core CLI](#net-core-cli)、アプリの構築および実行用の .NET Core ライブラリとランタイム、CLI コマンドとアプリケーションを実行する dotnet 実行可能ファイル (*dotnet.exe*) が含まれます。 + +「[.NET Core SDK の概要](../core/sdk.md)」をご覧ください。 + +## .NET Framework + +Windows でのみ動作する .NET の実装。 共通言語ランタイム (CLR)、基本クラス ライブラリ、および ASP.NET、Windows フォーム、WPF などのアプリケーション フレームワーク ライブラリが含まれます。 + +「[.NET Framework ガイド](../framework/index.md)」をご覧ください。 + +## .NET Native + +Just-In-Time (JIT) ではなく Ahead Of Time (AOT) でネイティブ コードを生成するコンパイラ ツール チェーン。 + +コンパイルは、C++ のコンパイラやリンカーと同様に、開発者のコンピューターで行われます。 未使用のコードが削除され、より多くの時間がコードの最適化に費やされます。 ライブラリからコードを抽出し、実行可能ファイルにそれらをマージします。 結果は、アプリ全体を表す 1 つのモジュールです。 + +UWP は、.NET Native によってサポートされる最初のアプリケーション フレームワークでした。 現在では、Windows、macOS、Linux 用のネイティブ コンソール アプリの構築がサポートされています。 + +「[Intro to .NET Native and CoreRT](https://github.com/dotnet/corert/blob/master/Documentation/intro-to-corert.md)」(.NET Native と CoreRT の概要) をご覧ください。 + +## .NET Standard + +.NET の各実装で使用可能な .NET API の正式な仕様。 + +.NET Standard の仕様は、ドキュメントではライブラリとも呼ばれます。 ライブラリには仕様 (インターフェイス) だけでなく API の実装も含まれるため、.NET Standard を "ライブラリ" と呼ぶのは誤解を招きます。 .NET Standard メタパッケージ (`NETStandard.Library`) の名前を参照する場合を除き、そのような使用法をドキュメントから消去する予定です。 + +「[.NET Standard](net-standard.md)」をご覧ください。 + +## NGEN + +ネイティブ (イメージ) 生成。 + +このテクノロジは、永続的な JIT コンパイラと考えることができます。 通常はコードが実行されるコンピューター上でコードをコンパイルしますが、一般にコンパイルはインストール時に行われます。 + +## package + +NuGet パッケージ — または単にパッケージ — は、同じ名前の 1 つまたは複数のアセンブリと、作成者名などの追加メタデータを含む、*.zip* ファイルです。 + +*.zip* ファイルは、拡張子が *.nupkg* であり、複数のフレームワークとバージョンで使う *.dll* ファイルや *.xml* ファイルなどのアセットを含むことができます。 アプリまたはライブラリでインストールされるときに、アプリまたはライブラリで指定されているターゲット フレームワークに基づいて適切なアセットが選択されます。 インターフェイスを定義するアセットは *ref* フォルダーにあり、実装を定義するアセットは *lib* フォルダーにあります。 + +## platform + +オペレーティング システムとそれが動作するハードウェア (Windows、macOS、Linux、iOS、Android)。 + +文章での使用例を次に示します。 + +- ".NET Core は、.NET のクロスプラットフォームの実装です。" +- "PCL プロファイルは Microsoft のプラットフォームを表し、.NET Standard はプラットフォームに依存しません。" + +.NET のドキュメントでは、.NET の実装またはすべての実装を含む .NET スタックの意味で ".NET プラットフォーム" が使われることがよくあります。 これらの使用法はどちらも本来の (OS/ハードウェア) の意味と紛らわしい場合があるので、ドキュメントから削除される予定です。 + +## ランタイム + +マネージ プログラムの実行環境。 + +OS は、ランタイム環境の一部ですが、.NET ランタイムの一部ではありません。 .NET ランタイムの例を次に示します。 + +- 共通言語ランタイム (CLR) +- Core 共通言語ランタイム (CoreCLR) +- .NET Native (UWP の場合) +- Mono ランタイム + +.NET のドキュメントでは、.NET の実装の意味で "ランタイム" が使われることがあります。 たとえば、次の文章の "ランタイム" は "実装" に置き換える必要があります。 + +- "さまざまな .NET ランタイムで、.NET Standard の特定のバージョンが実装されます。" +- "複数のランタイムでの実行を意図したライブラリは、このフレームワークを対象とする必要があります。" (.NET Standard を指している場合) +- "さまざまな .NET ランタイムで、.NET Standard の特定のバージョンが実装されます。 … .NET ランタイムの各バージョンは、サポートしている .NET Standard の最高のバージョンをアドバタイズします …" + +このような一貫性のない使用法は除去される予定です。 + +## スタック + +全体としてアプリケーションの構築と実行に使われるプログラミング テクノロジのセット。 + +".NET スタック" は、.NET Standard および .NET のすべての実装を指します。 ".NET スタック" という語句が .NET の 1 つの実装を示すこともあります。 + +## ターゲット フレーム + +.NET アプリまたはライブラリが依存する API のコレクション。 + +アプリまたはライブラリは、.NET Standard の 1 つのバージョン (.NET Standard 2.0 など) をターゲットにできます。.NET Standard は、.NET のすべての実装で標準化された API のセットの仕様です。 また、アプリまたはライブラリは、.NET の特定の実装のバージョンをターゲットにすることもでき、その場合は実装固有の API にアクセスできます。 たとえば、Xamarin.iOS をターゲットにするアプリは、Xamarin が提供する iOS API ラッパーにアクセスできます。 + +一部のターゲット フレームワーク (.NET Framework など) では、使用可能な API は .NET の実装がシステムにインストールするアセンブリによって定義され、アプリケーション フレームワーク API (たとえば ASP.NET、WinForms) を含む場合があります。 パッケージ ベースのターゲット フレームワーク (.NET Standard、.NET Core など) では、フレームワーク API はアプリまたはライブラリでインストールされるパッケージによって定義されます。 その場合、ターゲット フレームワークでは、全体としてフレームワークを構成するすべてのパッケージを参照するメタパッケージが暗黙的に指定されます。 + +「[ターゲット フレームワーク](frameworks.md)」をご覧ください。 + +## TFM + +ターゲット フレームワーク モニカー (Target Framework Moniker)。 + +.NET アプリまたはライブラリのターゲット フレームワークを指定するための標準化されたトークン形式。 通常、ターゲット フレームワークは短い名前によって参照されます (`net462` など)。 長い形式の TFM (.NETFramework,Version=4.6.2 など) も存在しますが、一般に、ターゲット フレームワークの指定には使われません。 + +「[ターゲット フレームワーク](frameworks.md)」をご覧ください。 + +## UWP + +ユニバーサル Windows プラットフォーム (Universal Windows Platform)。 + +モノのインターネット (IoT) のために最新のタッチ対応の Windows アプリケーションとソフトウェアを構築するために使われる .NET の実装。 PC、タブレット、ファブレット、携帯電話、Xbox など、ターゲットにする可能性があるさまざまな種類のデバイスを統一するように設計されています。 UWP は、一元的なアプリ ストア、実行環境 (AppContainer)、Win32 の代わりに使う Windows API のセット (WinRT) など、多くのサービスを提供します。 アプリは、C++、C#、VB.NET、および JavaScript で記述することができます。 C# と VB.NET を使うときは、.NET Core によって .NET API が提供されます。 + +## 関連項目 + +[.NET のガイド](index.md) +[.NET Framework ガイド](../framework/index.md) +[.NET Core](../core/index.md) +[ASP.NET の概要](/aspnet/index#pivot=aspnet) +[ASP.NET Core の概要](/aspnet/index#pivot=core) + + diff --git a/docs/standard/language-independence-and-language-independent-components.md b/docs/standard/language-independence-and-language-independent-components.md index 465bb099119..b8306a0b08c 100644 --- a/docs/standard/language-independence-and-language-independent-components.md +++ b/docs/standard/language-independence-and-language-independent-components.md @@ -1,37 +1,41 @@ --- -title: "言語への非依存性、および言語非依存コンポーネント | Microsoft Docs" -ms.custom: "" -ms.date: "03/30/2017" -ms.prod: ".net" -ms.reviewer: "" -ms.suite: "" -ms.technology: - - "dotnet-standard" -ms.tgt_pltfrm: "" -ms.topic: "article" -helpviewer_keywords: - - "CLS" - - "共通言語ランタイム, 言語の相互運用性" - - "共通言語仕様" - - "言語間の相互運用性" - - "言語の相互運用性" - - "ランタイム, 言語の相互運用性" +title: "言語への非依存性、および言語非依存コンポーネント" +ms.custom: +ms.date: 03/30/2017 +ms.prod: .net +ms.reviewer: +ms.suite: +ms.technology: dotnet-standard +ms.tgt_pltfrm: +ms.topic: article +helpviewer_keywords: +- language interoperability +- Common Language Specification +- cross-language interoperability +- CLS +- runtime, language interoperability +- common language runtime, language interoperability ms.assetid: 4f0b77d0-4844-464f-af73-6e06bedeafc6 caps.latest.revision: 35 -author: "rpetrusha" -ms.author: "ronpet" -manager: "wpickett" -caps.handback.revision: 33 +author: rpetrusha +ms.author: ronpet +manager: wpickett +ms.translationtype: HT +ms.sourcegitcommit: 306c608dc7f97594ef6f72ae0f5aaba596c936e1 +ms.openlocfilehash: 270a75e0c4e3da5ea87196580ab09dbff24b80c6 +ms.contentlocale: ja-jp +ms.lasthandoff: 08/21/2017 + --- -# 言語への非依存性、および言語非依存コンポーネント -.NET Framework は言語に依存しません。 つまり、C\+\+\/CLI、Eiffel、F\#、IronPython、IronRuby、PowerBuilder、Visual Basic、Visual COBOL、Windows PowerShell など、.NET Framework を対象とする多くの言語の 1 つを開発に使用できます。 .NET Framework 用に開発されたクラス ライブラリの型とメンバーには、最初に記述された言語を知らなくてもアクセスできます。元の言語の規則に従う必要もありません。 コンポーネントを開発しているのであれば、コンポーネントの言語にかかわらず、すべての .NET Framework アプリからそのコンポーネントにアクセスできます。 +# 言語への非依存性、および言語非依存コンポーネント +.NET Framework は言語に依存しません。 つまり、C++/CLI、Eiffel、F#、IronPython、IronRuby、PowerBuilder、Visual Basic、Visual COBOL、Windows PowerShell など、.NET Framework を対象とする多くの言語の 1 つを開発に使用できます。 .NET Framework 用に開発されたクラス ライブラリの型とメンバーには、最初に記述された言語を知らなくてもアクセスできます。元の言語の規則に従う必要もありません。 コンポーネントを開発しているのであれば、コンポーネントの言語にかかわらず、すべての .NET Framework アプリからそのコンポーネントにアクセスできます。 > [!NOTE] -> この記事の最初の部分では、言語に依存しないコンポーネント、つまり、どの言語で記述されたアプリからでも使用できるコンポーネントの作成について説明します。 また、複数の言語で記述されたソース コードから 1 つのコンポーネントまたはアプリを作成することもできます。この記事の 2 番目のパートにある「[言語間の相互運用性](#CrossLang)」を参照してください。 +> この記事の最初の部分では、言語に依存しないコンポーネント、つまり、どの言語で記述されたアプリからでも使用できるコンポーネントの作成について説明します。 また、複数の言語で記述されたソース コードから 1 つのコンポーネントまたはアプリを作成することもできます。この記事の 2 番目のパートにある「[言語間の相互運用性](#CrossLang)」を参照してください。 - 任意の言語で記述された他のオブジェクトと完全に対話するには、すべての言語に共通の機能だけを呼び出し側に公開するようにオブジェクトを実装する必要があります。 この共通の機能セットは、生成されたアセンブリに適用される規則のセットである、共通言語仕様 \(CLS: Common Language Specification\) によって定義されます。 共通言語仕様は、「[Standard ECMA\-335: Common Language Infrastructure \(標準の ECMA\-335: 共通言語基盤\)](http://go.microsoft.com/fwlink/?LinkID=116487)」の第 1 部の第 7 ～ 11 項で定義されています。 + 任意の言語で記述された他のオブジェクトと完全に対話するには、すべての言語に共通の機能だけを呼び出し側に公開するようにオブジェクトを実装する必要があります。 この共通の機能セットは、生成されたアセンブリに適用される規則のセットである、共通言語仕様 (CLS: Common Language Specification) によって定義されます。 共通言語仕様は、「[Standard ECMA-335: Common Language Infrastructure](http://go.microsoft.com/fwlink/?LinkID=116487)」(標準の ECMA-335: 共通言語基盤) の第 1 部の第 7 ～ 11 項で定義されています。 - コンポーネントが共通言語仕様に準拠している場合は、CLS に準拠することが保証され、CLS をサポートするすべてのプログラミング言語で記述されたアセンブリのコードからアクセスできます。 コンパイル時にコンポーネントが共通言語仕様に準拠しているかどうかを確認するには、 属性をソース コードに適用します。 詳細については、「[CLSCompliantAttribute 属性](#CLSAttribute)」を参照してください。 + コンポーネントが共通言語仕様に準拠している場合は、CLS に準拠することが保証され、CLS をサポートするすべてのプログラミング言語で記述されたアセンブリのコードからアクセスできます。 コンパイル時にコンポーネントが共通言語仕様に準拠しているかどうかを確認するには、 属性をソース コードに適用します。 詳細については、「[CLSCompliantAttribute 属性](#CLSAttribute)」を参照してください。 この記事の内容: @@ -47,7 +51,7 @@ caps.handback.revision: 33 - [インターフェイス](#Interfaces) - - [列挙](#enums) + - [列挙型](#enums) - [一般的な型メンバー](#members) @@ -61,7 +65,7 @@ caps.handback.revision: 33 - [イベント](#events) - - [Overloads](#overloads) + - [オーバーロード](#overloads) - [例外](#exceptions) @@ -72,106 +76,103 @@ caps.handback.revision: 33 - [言語間の相互運用性](#CrossLang) -## CLS 準拠の規則 - ここでは、CLS に準拠したコンポーネントを作成するための規則について説明します。 規則の一覧については、「[Standard ECMA\-335: Common Language Infrastructure \(標準の ECMA\-335: 共通言語基盤\)](http://go.microsoft.com/fwlink/?LinkID=116487)」の第 1 部の第 11 項を参照してください。 +## CLS 準拠の規則 + ここでは、CLS に準拠したコンポーネントを作成するための規則について説明します。 規則の一覧については、「[ECMA-335 Standard: Common Language Infrastructure](http://go.microsoft.com/fwlink/?LinkID=116487)」(標準の ECMA-335: 共通言語基盤) の第 1 部の第 11 項を参照してください。 > [!NOTE] -> 共通言語仕様では、コンシューマー \(プログラムによって CLS 準拠のコンポーネントにアクセスする開発者\)、フレームワーク \(言語コンパイラを使用して CLS 準拠のライブラリを作成する開発者\)、およびエクステンダー \(CLS 準拠のコンポーネントを作成する言語コンパイラ、コード パーサーなどのツールを作成する開発者\) に適用する、CLS 準拠の各規則について説明します。 ここでは、フレームワークに適用するときの規則に焦点を当てます。 エクステンダーに適用する一部の規則は、Reflection.Emit を使用して作成されたアセンブリに適用されることもあります。 +> 共通言語仕様では、コンシューマー (プログラムによって CLS 準拠のコンポーネントにアクセスする開発者)、フレームワーク (言語コンパイラを使用して CLS 準拠のライブラリを作成する開発者)、およびエクステンダー (CLS 準拠のコンポーネントを作成する言語コンパイラ、コード パーサーなどのツールを作成する開発者) に適用する、CLS 準拠の各規則について説明します。 ここでは、フレームワークに適用するときの規則に焦点を当てます。 エクステンダーに適用する一部の規則は、Reflection.Emit を使用して作成されたアセンブリに適用されることもあります。 - 言語に依存しないコンポーネントをデザインするには、コンポーネントのパブリック インターフェイスに CLS 準拠の規則を適用するだけです。 プライベートな実装は仕様に準拠する必要はありません。 + 言語に依存しないコンポーネントをデザインするには、コンポーネントのパブリック インターフェイスに CLS 準拠の規則を適用するだけです。 プライベートな実装は仕様に準拠する必要はありません。 > [!IMPORTANT] > CLS 準拠の規則は、コンポーネントのパブリック インターフェイスにのみ適用されます。プライベート実装には適用されません。 - たとえば、 以外の符号なし整数は CLS に準拠していません。 次の例の `Person` クラスは型 `Age` の プロパティを公開するので、次のコードではコンパイラの警告が表示されます。 + たとえば、 以外の符号なし整数は CLS に準拠していません。 次の例の `Person` クラスは型 `Age` の プロパティを公開するので、次のコードではコンパイラの警告が表示されます。 - [!code-csharp[Conceptual.CLSCompliant#1](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/public1.cs#1)] - [!code-vb[Conceptual.CLSCompliant#1](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/public1.vb#1)] + [!code-csharp[Conceptual.CLSCompliant#1](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/public1.cs#1)] [!code-vb[Conceptual.CLSCompliant#1](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/public1.vb#1)] - `Person` クラスを CLS 準拠にするには、`Age` プロパティの型を から、CLS 準拠の 16 ビット符号付き整数である Int16?qualifyHint=False&autoUpgrade=True に変更します。 プライベート `personAge` フィールドの型を変更する必要はありません。 + `Person` クラスを CLS 準拠にするには、`Age` プロパティの型を から、CLS 準拠の 16 ビット符号付き整数である に変更します。 プライベート `personAge` フィールドの型を変更する必要はありません。 - [!code-csharp[Conceptual.CLSCompliant#2](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/public2.cs#2)] - [!code-vb[Conceptual.CLSCompliant#2](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/public2.vb#2)] + [!code-csharp[Conceptual.CLSCompliant#2](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/public2.cs#2)] [!code-vb[Conceptual.CLSCompliant#2](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/public2.vb#2)] ライブラリのパブリック インターフェイスは、次の要素で構成されます。 - パブリック クラスの定義。 -- パブリック クラスのパブリック メンバーの定義、および派生クラスからアクセスできるメンバー \(つまり、protected メンバー\) の定義。 +- パブリック クラスのパブリック メンバーの定義、および派生クラスからアクセスできるメンバー (つまり、protected メンバー) の定義。 - パブリック クラスのパブリック メソッドのパラメーターおよび戻り値の型、派生クラスからアクセスできるメソッドのパラメーターおよび戻り値の型。 - CLS 準拠の規則を次の表に示します。 この規則は、「[Standard ECMA\-335: Common Language Infrastructure \(標準の ECMA\-335: 共通言語基盤\)](http://go.microsoft.com/fwlink/?LinkID=116487)」\(Copyright 2012: Ecma International\) からの引用です。 これらの規則の詳細については、以降のセクションを参照してください。 + CLS 準拠の規則を次の表に示します。 この規則は、「[ECMA-335 Standard: Common Language Infrastructure](http://go.microsoft.com/fwlink/?LinkID=116487)」(標準の ECMA-335: 共通言語基盤) からの引用で、Ecma International が 2012 年の著作権を保有しています。 これらの規則の詳細については、以降のセクションを参照してください。 |カテゴリ|参照トピック|ルール|規則番号| -|----------|------------|---------|----------| -|ユーザー補助|[メンバーのアクセシビリティ](#MemberAccess)|継承されたメソッドをオーバーライドする場合、アクセシビリティは変更してはいけない。ただし、別のアセンブリから継承されたメソッドをアクセシビリティ `family-or-assembly` でオーバーライドする場合は除く。 この場合、アクセシビリティは `family` にすること。|10| -|ユーザー補助|[メンバーのアクセシビリティ](#MemberAccess)|型およびメンバーの可視性およびアクセシビリティについて、メンバーのシグネチャに指定されている型は、そのメンバーが可視でアクセス可能な場合、必ず可視でアクセス可能でなければいけない。 たとえば、アセンブリ外部から参照できるパブリックなメソッドには、アセンブリ内部でだけ可視である型が引数として含まれていてはいけない。 メンバーのシグネチャに使用されているジェネリック型のインスタンスを構成する型の可視性およびアクセシビリティは、メンバーが可視でアクセス可能の場合、必ず可視でアクセス可能でなければいけない。 たとえば、アセンブリ外部から参照できるメンバーのシグネチャに指定されているジェネリック型のインスタンスに、アセンブリ内部でだけ可視である型の汎用引数が含まれていてはいけない。|12| -|配列|[配列](#arrays)|配列は、要素が CLS 準拠型で、すべての次元でインデックス番号が 0 から始まらなければならない。 項目が配列の場合、オーバーロードどうしを区別するには配列要素の型を必要とする。 オーバーロードが 2 つ以上の配列型に基づく場合、要素型は名前付きの型でなければいけない。|16| +|--------------|---------|----------|-----------------| +|ユーザー補助|[メンバーのアクセシビリティ](#MemberAccess)|継承されたメソッドをオーバーライドする場合、アクセシビリティは変更してはいけない。ただし、別のアセンブリから継承されたメソッドをアクセシビリティ `family-or-assembly` でオーバーライドする場合は除く。 この場合、アクセシビリティは `family` にすること。|10| +|ユーザー補助|[メンバーのアクセシビリティ](#MemberAccess)|型およびメンバーの可視性およびアクセシビリティについて、メンバーのシグネチャに指定されている型は、そのメンバーが可視でアクセス可能な場合、必ず可視でアクセス可能でなければいけない。 たとえば、アセンブリ外部から参照できるパブリックなメソッドには、アセンブリ内部でだけ可視である型が引数として含まれていてはいけない。 メンバーのシグネチャに使用されているジェネリック型のインスタンスを構成する型の可視性およびアクセシビリティは、メンバーが可視でアクセス可能の場合、必ず可視でアクセス可能でなければいけない。 たとえば、アセンブリ外部から参照できるメンバーのシグネチャに指定されているジェネリック型のインスタンスに、アセンブリ内部でだけ可視である型の汎用引数が含まれていてはいけない。|12| +|配列|[配列](#arrays)|配列は、要素が CLS 準拠型で、すべての次元でインデックス番号が 0 から始まらなければならない。 項目が配列の場合、オーバーロードどうしを区別するには配列要素の型を必要とする。 オーバーロードが 2 つ以上の配列型に基づく場合、要素型は名前付きの型でなければいけない。|16| |属性|[属性](#attributes)|属性の型 、またはそれを継承する型である。|41| -|属性|[属性](#attributes)|CLS ではカスタム属性のエンコーディングのサブセットのみ使用できる。 これらのエンコーディングに表示される型 \(第 4 部を参照\) は、、、、、、、、、、、CLS 準拠の基底の整数型に基づく列挙型のみである。|34| -|属性|[属性](#attributes)|CLS では、公開参照される必須の修飾子 \(`modreq`、第 2 部を参照\) は使用できない。ただし、認識しないオプションの修飾子 \(`modopt`、第 2 部を参照\) は使用できる。|35| -|コンストラクター|[コンストラクター](#ctors)|オブジェクト コンストラクターでは、継承しているインスタンス データへのアクセスが発生する前に、基底クラスのインスタンス コンストラクターを呼び出さなければいけない \(コンストラクターが不要である値型は除く\)。|21| +|属性|[属性](#attributes)|CLS ではカスタム属性のエンコーディングのサブセットのみ使用できる。 これらのエンコーディングに表示される型 (第 4 部を参照) は、、、、、、、、、、、CLS 準拠の基底の整数型に基づく列挙型のみである。|34| +|属性|[属性](#attributes)|CLS では、公開参照される必須の修飾子 (`modreq`、第 2 部を参照) は使用できない。ただし、認識しないオプションの修飾子 (`modopt`、第 2 部を参照) は使用できる。|35| +|コンストラクター|[コンストラクター](#ctors)|オブジェクト コンストラクターでは、継承しているインスタンス データへのアクセスが発生する前に、基底クラスのインスタンス コンストラクターを呼び出さなければいけない (コンストラクターが不要である値型は除く)。|21| |コンストラクター|[コンストラクター](#ctors)|オブジェクト コンストラクターがオブジェクトの作成時以外で呼び出されてはならず、またオブジェクトが 2 度初期化されてもいけない。|22| -|列挙|[列挙](#enums)|enum の基になる型は組み込みの CLS 整数型、フィールド名は "value\_\_" であり、そのフィールドには `RTSpecialName` のマークが付けられる。|7| -|列挙|[列挙](#enums)|enum には 2 種類あり、 カスタム属性 \(第 4 部のライブラリを参照\) の有無で区別する。 片方は名前付き整数値を表し、もう片方は名前付きビット フラグを表す。名前付きビット フラグは、それを組み合わせて名前のない値を生成できる。 `enum` の値は、指定した値に限定されない。|9| -|列挙|[列挙](#enums)|enum のリテラルな静的フィールドの型は、その enum 自体の型である。|9| +|列挙型|[列挙型](#enums)|enum の基になる型は組み込みの CLS 整数型、フィールド名は "value__" であり、そのフィールドには `RTSpecialName` のマークが付けられる。|7| +|列挙型|[列挙型](#enums)|enum には 2 種類あり、 カスタム属性 (第 4 部のライブラリを参照) の有無で区別する。 片方は名前付き整数値を表し、もう片方は名前付きビット フラグを表す。名前付きビット フラグは、それを組み合わせて名前のない値を生成できる。 `enum` の値は、指定した値に限定されない。|9| +|列挙型|[列挙型](#enums)|enum のリテラルな静的フィールドの型は、その enum 自体の型である。|9| |イベント|[イベント](#events)|イベントを実装するメソッドは、メタデータ内で `SpecialName` のマークが付けられる。|29| |イベント|[イベント](#events)|イベントとイベントのアクセサーのアクセシビリティは同一である。|30| |イベント|[イベント](#events)|イベントの `add` メソッドおよび `remove` メソッドは、どちらもあってもなくてもよい。|31| |イベント|[イベント](#events)|`add` メソッドおよび `remove` メソッドは、それぞれパラメーターを 1 つ使用する。このパラメーターの型がイベントの型を規定する。また、パラメーターの型は の派生でなければいけない。|32| -|イベント|[イベント](#events)|イベントは、特定の名前付けパターンに従わなくてはいけない。 CLS 規則 29 で触れられている `SpecialName` 属性は、適切な名前比較で無視され、識別子規則に従わなければいけない。|33| -|例外|[例外](#exceptions)|スローできるオブジェクト型は、、またはそれを継承する型である。 ただし、CLS 準拠のメソッドで他の型の例外のスローをブロックする必要はない。|40| +|イベント|[イベント](#events)|イベントは、特定の名前付けパターンに従わなくてはいけない。 CLS 規則 29 で触れられている `SpecialName` 属性は、適切な名前比較で無視され、識別子規則に従わなければいけない。|33| +|例外|[例外](#exceptions)|スローできるオブジェクト型は、、またはそれを継承する型である。 ただし、CLS 準拠のメソッドで他の型の例外のスローをブロックする必要はない。|40| |全般|[CLS 準拠: 規則](#Rules)|CLS 規則は、型の構成部分のうち、その型を定義しているアセンブリの外部からアクセスまたは参照できる部分にのみ適用される。|1| |全般|[CLS 準拠: 規則](#Rules)|CLS 非準拠型のメンバーを CLS 準拠と指定しない。|2| -|ジェネリック|[ジェネリック型とメンバー](#Generics)|入れ子になった型は、少なくともその外側の型と同じ数のジェネリック パラメーターを持つ。 入れ子にされた型のジェネリック パラメーターは、それを囲む型のジェネリック パラメーターと、位置によって対応します。|42| +|ジェネリック|[ジェネリック型とメンバー](#Generics)|入れ子になった型は、少なくともその外側の型と同じ数のジェネリック パラメーターを持つ。 入れ子にされた型のジェネリック パラメーターは、それを囲む型のジェネリック パラメーターと、位置によって対応します。|42| |ジェネリック|[ジェネリック型とメンバー](#Generics)|ジェネリック型の名前は、入れ子にされない型で宣言される型パラメーターの数をエンコードする必要がある。入れ子にされる場合は、上記の規則に従って、型に新しく組み込まれる型パラメーターの数をエンコードする必要がある。|43| |ジェネリック|[ジェネリック型とメンバー](#Generics)|ジェネリック型は必要な制約を再宣言して、基本型またはインターフェイスの制約がジェネリック型の制約で確実に満たされるようにする必要がある。|4444| |ジェネリック|[ジェネリック型とメンバー](#Generics)|ジェネリック パラメーターの制約として使用される型は CLS に準拠する必要がある。|45| -|ジェネリック|[ジェネリック型とメンバー](#Generics)|インスタンス化されたジェネリック型のメンバー \(入れ子になった型も含む\) の可視性およびアクセシビリティは、ジェネリック型の全体の宣言ではなく、特定のインスタンス化に対してスコープが設定される必要がある。 この場合でも、CLS 規則 12 の可視性規則とアクセシビリティ規則は同様に適用される。|46| +|ジェネリック|[ジェネリック型とメンバー](#Generics)|インスタンス化されたジェネリック型のメンバー (入れ子になった型も含む) の可視性およびアクセシビリティは、ジェネリック型の全体の宣言ではなく、特定のインスタンス化に対してスコープが設定される必要がある。 この場合でも、CLS 規則 12 の可視性規則とアクセシビリティ規則は同様に適用される。|46| |ジェネリック|[ジェネリック型とメンバー](#Generics)|抽象メソッドまたは仮想ジェネリック メソッドごとに、既定の具体的な実装がある。|47| -|インターフェイス|[インターフェイス](#interfaces)|CLS 準拠のインターフェイスでは、CLS に準拠しないメソッドを実装するために、これらを定義する必要はない。|18| -|インターフェイス|[インターフェイス](#interfaces)|CLS 準拠インターフェイスでは、静的メソッドを定義してはいけない。また、フィールドも定義してはいけない。|19| -|メンバー|[一般的な型メンバー](#members)|グローバルで静的な \(static\) フィールドとメソッドは CLS 準拠ではありません。|36| -|メンバー|\-\-|静的リテラル値の指定には、フィールド初期化メタデータを使用する。 CLS 準拠のリテラルには、そのリテラルと同じ型 \(または、そのリテラルが `enum` の場合は基本型\) の値がフィールド初期化メタデータに指定されている必要がある。|13| -|メンバー|[一般的な型メンバー](#members)|vararg 制約は CLS の一部ではなく、CLS でサポートする呼び出し規約だけが標準のマネージ呼び出し規約である。|15| -|名前付け規則|[名前付け規則](#naming)|アセンブリは、識別子の頭文字および構成文字として使用できる文字セットを規定する Unicode Standard 3.0 の『Technical Report 15』の「Annex 7」に従う必要がある。詳細については、http:\/\/www.unicode.org\/unicode\/reports\/tr15\/tr15\-18.html を参照。 識別子は、Unicode 正規形 C に定義されている標準形式で記述する必要がある。 CLS で 2 つの識別子が同じと見なされるのは、小文字マッピング \(Unicode のロケール非依存で 1 対 1 の小文字による対応付け\) が同じ場合である。 つまり、CLS で 2 つの識別子が異なる場合、大文字小文字の違いだけではない。 ただし、継承された定義をオーバーライドする場合、CLI では元の宣言と厳密に同じエンコーディングの使用が求められる。|4| -|オーバーロード|[名前付け規則](#naming)|CLS 準拠のスコープに導入されるすべての名前は、完全に独立した種類でなければいけない。ただし、名前が同じでオーバーロードによって解決できる場合を除く。 CTS では 1 つの型でメソッドとフィールドとに同じ名前を使用できるが、CLS では使用できない。|5| -|オーバーロード|[名前付け規則](#naming)|フィールドおよび入れ子になった型について、CTS ではシグネチャでの区別が可能だが、CLS では識別子の比較だけで区別できる必要がある。 CLS 規則 39 の指定を除き、識別子の比較により名前が同じであるメソッド、プロパティ、およびイベントでは、相違点は戻り値の型だけに限定されない。|6| -|オーバーロード|[Overloads](#overloads)|プロパティおよびメソッドのみオーバーロードできる。|37| -|オーバーロード|[Overloads](#overloads)|プロパティおよびメソッドは、パラメーターの数値と型にのみ基づいてオーバーロードできる。ただし、戻り値の型に基づいてオーバーロードできる変換演算子の `op_Implicit` と o`op_Explicit` は例外である。|38| -|オーバーロード|\-\-|型で宣言された複数の CLS 準拠のメソッドに同じ名前が指定されている場合、特定の一連の型のインスタンス化において、これらのメソッドのパラメーターと戻り値の型は同じである。また、これらの型のインスタンス化で、すべてのメソッドをセマンティクス レベルで等価にする必要がある。|48| -|型|[型および型メンバーのシグネチャ](#Types)| は CLS 準拠である。 これ以外のあらゆる CLS 準拠クラスは CLS 準拠クラスの継承でなければならない。|23| +|インターフェイス|[インターフェイス](#Interfaces)|CLS 準拠のインターフェイスでは、CLS に準拠しないメソッドを実装するために、これらを定義する必要はない。|18| +|インターフェイス|[インターフェイス](#Interfaces)|CLS 準拠インターフェイスでは、静的メソッドを定義してはいけない。また、フィールドも定義してはいけない。|19| +|メンバー|[一般的な型メンバー](#members)|グローバルで静的な (static) フィールドとメソッドは CLS 準拠ではありません。|36| +|メンバー|--|静的リテラル値の指定には、フィールド初期化メタデータを使用する。 CLS 準拠のリテラルには、そのリテラルと同じ型 (または、そのリテラルが `enum` の場合は基本型) の値がフィールド初期化メタデータに指定されている必要がある。|13| +|メンバー|[一般的な型メンバー](#members)|vararg 制約は CLS の一部ではなく、CLS でサポートする呼び出し規則だけが標準のマネージ呼び出し規則である。|15| +|名前付け規則|[名前付け規則](#naming)|アセンブリは、識別子の頭文字および構成文字として使用できる文字セットを規定する Unicode Standard 3.0 の『Technical Report 15』の「Annex 7」に従う必要がある。詳細については、http://www.unicode.org/unicode/reports/tr15/tr15-18.html を参照。 識別子は、Unicode 正規形 C に定義されている標準形式で記述する必要がある。CLS で 2 つの識別子が同じと見なされるのは、小文字マッピング (Unicode のロケール非依存で 1 対 1 の小文字による対応付け) が同じ場合である。 つまり、CLS で 2 つの識別子が異なる場合、大文字小文字の違いだけではない。 ただし、継承された定義をオーバーライドする場合、CLI では元の宣言と厳密に同じエンコーディングの使用が求められる。|4| +|オーバーロード|[名前付け規則](#naming)|CLS 準拠のスコープに導入されるすべての名前は、完全に独立した種類でなければいけない。ただし、名前が同じでオーバーロードによって解決できる場合を除く。 CTS では 1 つの型でメソッドとフィールドとに同じ名前を使用できるが、CLS では使用できない。|5| +|オーバーロード|[名前付け規則](#naming)|フィールドおよび入れ子になった型について、CTS ではシグネチャでの区別が可能だが、CLS では識別子の比較だけで区別できる必要がある。 CLS 規則 39 の指定を除き、識別子の比較により名前が同じであるメソッド、プロパティ、およびイベントでは、相違点は戻り値の型だけに限定されない。|6| +|オーバーロード|[オーバーロード](#overloads)|プロパティおよびメソッドのみオーバーロードできる。|37| +|オーバーロード|[オーバーロード](#overloads)|プロパティおよびメソッドは、パラメーターの数値と型にのみ基づいてオーバーロードできる。ただし、戻り値の型に基づいてオーバーロードできる変換演算子の `op_Implicit` と o`op_Explicit` は例外である。|38| +|オーバーロード|--|型で宣言された複数の CLS 準拠のメソッドに同じ名前が指定されている場合、特定の一連の型のインスタンス化において、これらのメソッドのパラメーターと戻り値の型は同じである。また、これらの型のインスタンス化で、すべてのメソッドをセマンティクス レベルで等価にする必要がある。|48| +|種類|[型および型メンバーのシグネチャ](#Types)| は CLS 準拠である。 これ以外のあらゆる CLS 準拠クラスは CLS 準拠クラスの継承でなければならない。|23| |プロパティ|[プロパティ](#properties)|プロパティの getter メソッドおよび setter メソッドを実装するメソッドは、メタデータで `SpecialName` とマークする。|24| |プロパティ|[プロパティ](#properties)|プロパティ アクセサーはすべて静的、すべて仮想、またはすべてインスタンスになる。|26| -|プロパティ|[プロパティ](#properties)|プロパティの型は、getter の戻り値の型であり、かつ setter の最後の引数の型でなければいけない。 プロパティのパラメーターの型は、getter へのパラメーターの型であり、かつ setter の最後のパラメーター以外のすべての型でなければいけない。 すべての型は CLS 準拠でなければならない。また、マネージ ポインターであってはいけない。つまり、参照渡しではいけない。|27| -|プロパティ|[プロパティ](#properties)|プロパティは、特定の名前付けパターンに従わなくてはいけない。 CLS 規則 24 で触れられている `SpecialName` 属性は、適切な名前比較で無視され、識別子規則に従わなければいけない。 プロパティには getter メソッド、setter メソッド、またはこの両方が必ずなければいけない。|28| +|プロパティ|[プロパティ](#properties)|プロパティの型は、getter の戻り値の型であり、かつ setter の最後の引数の型でなければいけない。 プロパティのパラメーターの型は、getter へのパラメーターの型であり、かつ setter の最後のパラメーター以外のすべての型でなければいけない。 すべての型は CLS 準拠でなければならない。また、マネージ ポインターであってはいけない。つまり、参照渡しではいけない。|27| +|プロパティ|[プロパティ](#properties)|プロパティは、特定の名前付けパターンに従わなくてはいけない。 CLS 規則 24 で触れられている `SpecialName` 属性は、適切な名前比較で無視され、識別子規則に従わなければいけない。 プロパティには getter メソッド、setter メソッド、またはこの両方が必ずなければいけない。|28| |型変換|[型変換](#conversion)|`op_Implicit` または `op_Explicit` が指定されている場合は、強制変換のための別の方法を用意する必要がある。|39| -|型|[型および型メンバーのシグネチャ](#Types)|ボックス化された値型は CLS 準拠ではない。|3| -|型|[型および型メンバーのシグネチャ](#Types)|シグネチャに出現するすべての型は CLS 準拠でなければいけない。 ジェネリック型のインスタンスを構成するすべての型は CLS 準拠でなければいけない。|11| -|型|[型および型メンバーのシグネチャ](#Types)|型指定された参照は CLS 準拠ではありません。|14| -|型|[型および型メンバーのシグネチャ](#Types)|アンマネージ ポインター型は CLS 準拠ではない。|17| -|型|[型および型メンバーのシグネチャ](#Types)|CLS 準拠のクラス、値型、およびインターフェイスでは、CLS に準拠しないメンバーの実装は不要である。|20| +|種類|[型および型メンバーのシグネチャ](#Types)|ボックス化された値型は CLS 準拠ではない。|3| +|種類|[型および型メンバーのシグネチャ](#Types)|シグネチャに出現するすべての型は CLS 準拠でなければいけない。 ジェネリック型のインスタンスを構成するすべての型は CLS 準拠でなければいけない。|11| +|種類|[型および型メンバーのシグネチャ](#Types)|型指定された参照は CLS 準拠ではありません。|14| +|種類|[型および型メンバーのシグネチャ](#Types)|アンマネージ ポインター型は CLS 準拠ではない。|17| +|種類|[型および型メンバーのシグネチャ](#Types)|CLS 準拠のクラス、値型、およびインターフェイスでは、CLS に準拠しないメンバーの実装は不要である。|20| -### 型および型メンバーのシグネチャ - 型は CLS に準拠しており、.NET Framework 型システムのすべてのオブジェクト型の基本型です。 .NET Framework の継承は暗黙的また明示的に行われます。たとえば、 クラスは クラスから暗黙的に継承します。また、 クラスは、 クラスから明示的に継承し、これは クラスから明示的に継承します。そして、このクラスは クラスから明示的に継承します。 派生型を CLS 準拠にするには、その基本型も CLS に準拠している必要があります。 +### 型および型メンバーのシグネチャ + 型は CLS に準拠しており、.NET Framework 型システムのすべてのオブジェクト型の基本型です。 .NET Framework の継承は暗黙的また明示的に行われます。たとえば、 クラスは クラスから暗黙的に継承します。また、 クラスは、 クラスから明示的に継承し、これは クラスから明示的に継承します。そして、このクラスは クラスから明示的に継承します。 派生型を CLS 準拠にするには、その基本型も CLS に準拠している必要があります。 - 次の例は、基本型が CLS に準拠していない派生型を示しています。 これは、符号なし 32 ビット整数をカウンターとして使用する `Counter` 基底クラスを定義します。 クラスには、符号なし整数をラップすることでカウンター機能が用意されます。このため、クラスは CLS 非準拠としてマークされます。 結果として、派生クラス `NonZeroCounter` も CLS に準拠しなくなります。 + 次の例は、基本型が CLS に準拠していない派生型を示しています。 これは、符号なし 32 ビット整数をカウンターとして使用する `Counter` 基底クラスを定義します。 クラスには、符号なし整数をラップすることでカウンター機能が用意されます。このため、クラスは CLS 非準拠としてマークされます。 結果として、派生クラス `NonZeroCounter` も CLS に準拠しなくなります。 - [!code-csharp[Conceptual.CLSCompliant#12](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/type3.cs#12)] - [!code-vb[Conceptual.CLSCompliant#12](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/type3.vb#12)] + [!code-csharp[Conceptual.CLSCompliant#12](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/type3.cs#12)] [!code-vb[Conceptual.CLSCompliant#12](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/type3.vb#12)] - メソッドの戻り値の型、プロパティ型を含め、メンバー シグネチャに表示されるすべての型が CLS に準拠する必要があります。 さらに、ジェネリック型の場合は、次の要件もあります。 + メソッドの戻り値の型、プロパティ型を含め、メンバー シグネチャに表示されるすべての型が CLS に準拠する必要があります。 さらに、ジェネリック型の場合は、次の要件もあります。 - ジェネリック型のインスタンスを構成するすべての型が、CLS に準拠する必要があります。 - ジェネリック パラメーターで制約として使用されるすべての型が、CLS に準拠する必要があります。 - .NET Framework の[共通型システム](../../docs/standard/base-types/common-type-system.md)には、共通言語ランタイムが直接サポートする組み込み型がいくつか含まれ、アセンブリのメタデータで特別にエンコードされています。 これらの組み込み型のうち、次の表に示す型は CLS に準拠しています。 + .NET Framework の[共通型システム](../../docs/standard/base-types/common-type-system.md)には、共通言語ランタイムが直接サポートする組み込み型がいくつか含まれ、アセンブリのメタデータで特別にエンコードされています。 これらの組み込み型のうち、次の表に示す型は CLS に準拠しています。 |CLS 準拠型|説明| -|-------------|--------| +|-------------------------|-----------------| ||8 ビット符号なし整数| ||16 ビット符号付き整数| ||32 ビット符号付き整数| @@ -179,7 +180,7 @@ caps.handback.revision: 33 ||単精度浮動小数点数値| ||倍精度浮動小数点数値| ||`true` or `false` 値型| -||UTF\-16 でエンコードされたコード単位| +||UTF-16 でエンコードされたコード単位| ||10 進浮動小数点数以外| ||プラットフォーム定義サイズのポインターまたはハンドル| ||0 個以上の オブジェクトのコレクション| @@ -187,282 +188,259 @@ caps.handback.revision: 33 次の表に示す組み込み型は CLS に準拠していません。 |非準拠型|説明|CLS に準拠する代替| -|----------|--------|-----------------| +|-------------------------|-----------------|--------------------------------| ||8 ビット符号付き整数データ型|| ||オブジェクトとそのランタイム型へのポインター|なし| ||16 ビット符号なし整数|| ||32 ビット符号なし整数|| -||64 ビット符号なし整数| \(オーバーフローの可能性あり\)、、または | +||64 ビット符号なし整数| (オーバーフローの可能性あり)、、または | ||符号なしポインターまたはハンドル|| .NET Framework のクラス ライブラリまたはその他のクラス ライブラリには、CLS に準拠していない他の型が含まれる場合があります。次に例を示します。 -- ボックス化された値型。 次の C\# コード例では、`int*` という名前の型 `Value` のパブリック プロパティを持つクラスを作成します。 `int*` はボックス化された値型であるため、コンパイラは CLS 非準拠としてフラグを設定します。 +- ボックス化された値型。 次の C# コード例では、`int*` という名前の型 `Value` のパブリック プロパティを持つクラスを作成します。 `int*` はボックス化された値型であるため、コンパイラは CLS 非準拠としてフラグを設定します。 [!code-csharp[Conceptual.CLSCompliant#26](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/box2.cs#26)] -- 型指定された参照。オブジェクトへの参照および型への参照を含む特別なコンストラクトです。 型指定された参照は、.NET Framework では クラスによって表されます。 +- 型指定された参照。オブジェクトへの参照および型への参照を含む特別なコンストラクトです。 型指定された参照は、.NET Framework では クラスによって表されます。 - 型が CLS に準拠していない場合は、 値が `isCompliant` に指定された `false` 属性を適用する必要があります。 詳細については、「[CLSCompliantAttribute 属性](#CLSAttribute)」を参照してください。 + 型が CLS に準拠していない場合は、 値が `isCompliant` に指定された `false` 属性を適用する必要があります。 詳細については、「[CLSCompliantAttribute 属性](#CLSAttribute)」を参照してください。 - 次の例は、メソッド シグネチャとジェネリック型のインスタンス化で発生する CLS 準拠の問題を示しています。 ここでは、`InvoiceItem` クラスを、型 のプロパティ、型 `Nullable(Of UInt32)` のプロパティ、および型 と `Nullable(Of UInt32)` のパラメーターが指定されたコンストラクターで定義します。 この例をコンパイルしようとすると、4 つのコンパイラの警告が表示されます。 + 次の例は、メソッド シグネチャとジェネリック型のインスタンス化で発生する CLS 準拠の問題を示しています。 ここでは、`InvoiceItem` クラスを、型 のプロパティ、型 `Nullable(Of UInt32)` のプロパティ、および型 と `Nullable(Of UInt32)` のパラメーターが指定されたコンストラクターで定義します。 この例をコンパイルしようとすると、4 つのコンパイラの警告が表示されます。 - [!code-csharp[Conceptual.CLSCompliant#3](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/type1.cs#3)] - [!code-vb[Conceptual.CLSCompliant#3](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/type1.vb#3)] + [!code-csharp[Conceptual.CLSCompliant#3](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/type1.cs#3)] [!code-vb[Conceptual.CLSCompliant#3](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/type1.vb#3)] コンパイラの警告が表示されないようにするには、`InvoiceItem` パブリック インターフェイスの CLS 非準拠型を準拠型に置き換えます。 - [!code-csharp[Conceptual.CLSCompliant#4](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/type2.cs#4)] - [!code-vb[Conceptual.CLSCompliant#4](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/type2.vb#4)] + [!code-csharp[Conceptual.CLSCompliant#4](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/type2.cs#4)] [!code-vb[Conceptual.CLSCompliant#4](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/type2.vb#4)] - ここで示した特定の型以外にも、CLS に準拠していないカテゴリはいくつかあります。 たとえば、アンマネージ ポインター型やアンマネージ関数ポインター型などです。 次の例では、整数へのポインターを使用して整数の配列を作成するので、コンパイラの警告が生成されます。 + ここで示した特定の型以外にも、CLS に準拠していないカテゴリはいくつかあります。 たとえば、アンマネージ ポインター型やアンマネージ関数ポインター型などです。 次の例では、整数へのポインターを使用して整数の配列を作成するので、コンパイラの警告が生成されます。 [!code-csharp[Conceptual.CLSCompliant#5](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/unmanagedptr1.cs#5)] - CLS 準拠の抽象クラス \(つまり、`abstract` \(C\# の場合\) または `MustInherit` \(Visual Basic の場合\) とマークされたクラス\) については、そのクラスのすべてのメンバーも CLS に準拠にする必要があります。 + CLS 準拠の抽象クラス (つまり、`abstract` (C# の場合) または `MustInherit` (Visual Basic の場合) とマークされたクラス) については、そのクラスのすべてのメンバーも CLS に準拠にする必要があります。 -### 名前付け規則 - 一部のプログラミング言語は大文字と小文字が区別されるので、識別子 \(名前空間、型、メンバーの名前など\) は、大文字と小文字が違うだけで相違します。 2 つの識別子が同じと見なされるのは、小文字マッピングが同じ場合です。 次の C\# コード例では、2 つのパブリック クラス、`Person` および `person` を定義します。 このクラスは大文字と小文字のみが異なるので、コンパイラは CLS 非準拠としてフラグを設定します。 +### 名前付け規則 + 一部のプログラミング言語は大文字と小文字が区別されるので、識別子 (名前空間、型、メンバーの名前など) は、大文字と小文字が違うだけで相違します。 2 つの識別子が同じと見なされるのは、小文字マッピングが同じ場合です。 次の C# コード例では、2 つのパブリック クラス、`Person` および `person` を定義します。 このクラスは大文字と小文字のみが異なるので、コンパイラは CLS 非準拠としてフラグを設定します。 [!code-csharp[Conceptual.CLSCompliant#16](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/naming1.cs#16)] - 名前空間、型、メンバーの名前など、プログラミング言語の識別子は[Unicode Standard 3.0 の Technical Report 15 の Annex 7](http://www.unicode.org/reports/tr15/tr15-18.html) に準拠する必要があります。 これによって、次のことが起こります。 + 名前空間、型、メンバーの名前など、プログラミング言語の識別子は [Unicode Standard 3.0 の Technical Report 15 の Annex 7](http://www.unicode.org/reports/tr15/tr15-18.html) に準拠する必要があります。 これによって、次のことが起こります。 -- 識別子の最初の文字は Unicode の大文字と小文字、大文字と小文字の組み合わせ、修飾子文字、その他の文字、または文字数の番号を指定できます。 Unicode 文字のカテゴリの詳細については、「 列挙体」を参照してください。 +- 識別子の最初の文字は Unicode の大文字と小文字、大文字と小文字の組み合わせ、修飾子文字、その他の文字、または文字数の番号を指定できます。 Unicode 文字のカテゴリの詳細については、「 列挙体」を参照してください。 - 2 文字目以降には、最初の文字で使用できる文字のほかに、非空白記号、空白結合記号、10 進数、接続符号、書式指定コードを使用できます。 - 識別子を比較する場合は、その前に書式設定コードを除外してから、識別子を Unicode 正規形 C に変換する必要があります。これは 1 つの文字を、UTF\-16 でエンコードされた複数のコード単位で表すことができるからです。 同じコード単位を Unicode 正規形 C で生成する文字シーケンスは CLS に準拠していません。 次の例では、最初にオングストローム文字 \(U\+212B\) である `Å` という名前のプロパティを定義し、次に、上に丸が付く LATIN の大文字 A \(U\+00C5\) である `Å` という名前のプロパティを定義します。 C\# と Visual Basic の両方のコンパイラが、CLS 非準拠としてソース コードにフラグを設定します。 + 識別子を比較する場合は、その前に書式設定コードを除外してから、識別子を Unicode 正規形 C に変換する必要があります。これは 1 つの文字を、UTF-16 でエンコードされた複数のコード単位で表すことができるからです。 同じコード単位を Unicode 正規形 C で生成する文字シーケンスは CLS に準拠していません。 次の例では、最初にオングストローム文字 (U+212B) である `Å` という名前のプロパティを定義し、次に、上に丸が付く LATIN の大文字 A (U+00C5) である `Å` という名前のプロパティを定義します。 C# と Visual Basic の両方のコンパイラが、CLS 非準拠としてソース コードにフラグを設定します。 - [!code-csharp[Conceptual.CLSCompliant#17](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/naming1.cs#17)] - [!code-vb[Conceptual.CLSCompliant#17](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/naming1.vb#17)] + [!code-csharp[Conceptual.CLSCompliant#17](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/naming1.cs#17)] [!code-vb[Conceptual.CLSCompliant#17](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/naming1.vb#17)] - 特定のスコープ内のメンバー名 \(アセンブリ内の名前空間、名前空間内の型、型内のメンバーなど\) は一意である必要があります。ただし、オーバーロードによって解決される名前は除きます。 この要件は、共通型システムの要件よりも厳格です。共通型システムでは、スコープ内のメンバーは種類が異なっていれば、たとえば、種類がメソッドのメンバーとフィールドのメンバーは、同じ名前を持つことができます。 特に、型メンバーの場合は次の要件もあります。 + 特定のスコープ内のメンバー名 (アセンブリ内の名前空間、名前空間内の型、型内のメンバーなど) は一意である必要があります。ただし、オーバーロードによって解決される名前は除きます。 この要件は、共通型システムの要件よりも厳格です。共通型システムでは、スコープ内のメンバーは種類が異なっていれば、たとえば、種類がメソッドのメンバーとフィールドのメンバーは、同じ名前を持つことができます。 特に、型メンバーの場合は次の要件もあります。 - フィールドと入れ子になった型は名前でのみ識別されます。 - 名前が同じメソッド、プロパティ、およびイベントは、戻り値の型以外で区別できるようにする必要があります。 - 次の例は、メンバー名がスコープ内で一意でなければならない要件を示しています。 ここでは、`Converter` という名前の 4 つのメンバーを含む `Conversion` という名前のクラスを定義します。 3 つがメソッドで、1 つはプロパティです。 パラメーターを含むメソッドには一意の名前が付けられますが、 パラメーターが指定された 2 つのメソッドには一意の名前は付けられません。これは戻り値がメンバーのシグネチャの一部と見なされないからです。 また、`Conversion` プロパティもこの要件に違反しています。プロパティの名前は、オーバーロードされたメソッドと同じにできないからです。 + 次の例は、メンバー名がスコープ内で一意でなければならない要件を示しています。 ここでは、`Converter` という名前の 4 つのメンバーを含む `Conversion` という名前のクラスを定義します。 3 つがメソッドで、1 つはプロパティです。 パラメーターを含むメソッドには一意の名前が付けられますが、 パラメーターが指定された 2 つのメソッドには一意の名前は付けられません。これは戻り値がメンバーのシグネチャの一部と見なされないからです。 また、`Conversion` プロパティもこの要件に違反しています。プロパティの名前は、オーバーロードされたメソッドと同じにできないからです。 - [!code-csharp[Conceptual.CLSCompliant#19](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/naming3.cs#19)] - [!code-vb[Conceptual.CLSCompliant#19](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/naming3.vb#19)] + [!code-csharp[Conceptual.CLSCompliant#19](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/naming3.cs#19)] [!code-vb[Conceptual.CLSCompliant#19](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/naming3.vb#19)] - 個々の言語に一意のキーワードが含まれるので、共通言語ランタイムを対象にする言語も、キーワードと一致する識別子 \(型名など\) を参照するための機構を用意する必要があります。 たとえば、`case` は、C\# と Visual Basic のキーワードです。 ただし、次の Visual Basic コード例では、左右の中かっこを使用して、`case` キーワードと `case` という名前のクラスを明確に区別できます。 それ以外の場合は、エラー メッセージ "キーワードは、識別子として有効ではありません" が表示され、コンパイルできません。 + 個々の言語に一意のキーワードが含まれるので、共通言語ランタイムを対象にする言語も、キーワードと一致する識別子 (型名など) を参照するための機構を用意する必要があります。 たとえば、`case` は、C# と Visual Basic のキーワードです。 ただし、次の Visual Basic コード例では、左右の中かっこを使用して、`case` キーワードと `case` という名前のクラスを明確に区別できます。 それ以外の場合は、エラー メッセージ "キーワードは、識別子として有効ではありません" が表示され、コンパイルできません。 [!code-vb[Conceptual.CLSCompliant#22](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/keyword1.vb#22)] - 次の C\# コード例では、`case` シンボルを使用して `@` クラスをインスタンス化することで、識別子と言語キーワードを区別できます。 これがないと、C\# コンパイラによって 2 つのエラー メッセージ "型が必要です" および "'case' は無効です" が表示されます。 + 次の C# コード例では、`case` シンボルを使用して `@` クラスをインスタンス化することで、識別子と言語キーワードを区別できます。 これがないと、C# コンパイラによって 2 つのエラー メッセージ "型が必要です" および "'case' は無効です" が表示されます。 [!code-csharp[Conceptual.CLSCompliant#23](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/keyword2.cs#23)] -### 型変換 +### 型変換 共通言語仕様では、次の 2 つの変換演算子が定義されます。 -- `op_Implicit`。データまたは精度の損失につながらない拡大変換に使用されます。 たとえば、 構造体には、整数型の値と `op_Implicit` 値を 値に変換できるように、オーバーロードされた 演算子が含まれます。 +- `op_Implicit`。データまたは精度の損失につながらない拡大変換に使用されます。 たとえば、 構造体には、整数型の値と `op_Implicit` 値を 値に変換できるように、オーバーロードされた 演算子が含まれます。 -- `op_Explicit`。絶対値 \(狭い範囲の値に変換される値\) または精度の損失につながる可能性がある縮小変換に使用されます。 たとえば、 構造体には、`op_Explicit` 値と 値を に変換し、 値を整数値、、、および に変換できるように、オーバーロードされた 演算子が含まれます。 +- `op_Explicit`。絶対値 (狭い範囲の値に変換される値) または精度の損失につながる可能性がある縮小変換に使用されます。 たとえば、 構造体には、`op_Explicit` 値と 値を に変換し、 値を整数値、、、および に変換できるように、オーバーロードされた 演算子が含まれます。 - ただし、すべての言語で、演算子のオーバーロードまたはカスタム演算子の定義がサポートされているわけではありません。 これらの変換演算子を実装する場合は、他の方法で変換を実行する方法も用意する必要があります。 ここでは、`From`*Xxx* メソッドおよび `To`*Xxx* メソッドを用意することをお勧めします。 + ただし、すべての言語で、演算子のオーバーロードまたはカスタム演算子の定義がサポートされているわけではありません。 これらの変換演算子を実装する場合は、他の方法で変換を実行する方法も用意する必要があります。 ここでは、`From`*Xxx* メソッドと `To`*Xxx* メソッドを用意することをお勧めします。 - 次の例では、CLS に準拠する暗黙的な変換と明示的な変換を定義します。 ここでは、符号付き倍精度浮動小数点数を表す `UDouble` クラスを作成します。 暗黙的な変換については、`UDouble` から 、明示的な変換については、`UDouble` から 、 から `UDouble`、および から `UDouble` への例を示しています。 また、暗黙的な変換演算子の代替として `ToDouble` メソッドを、明示的な変換演算子の代替として `ToSingle`、`FromDouble`、`FromSingle` の各メソッドを定義します。 + 次の例では、CLS に準拠する暗黙的な変換と明示的な変換を定義します。 ここでは、符号付き倍精度浮動小数点数を表す `UDouble` クラスを作成します。 暗黙的な変換については、`UDouble` から 、明示的な変換については、`UDouble` から 、 から `UDouble`、および から `UDouble` への例を示しています。 また、暗黙的な変換演算子の代替として `ToDouble` メソッドを、明示的な変換演算子の代替として `ToSingle`、`FromDouble`、`FromSingle` の各メソッドを定義します。 - [!code-csharp[Conceptual.CLSCompliant#15](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/convert1.cs#15)] - [!code-vb[Conceptual.CLSCompliant#15](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/convert1.vb#15)] + [!code-csharp[Conceptual.CLSCompliant#15](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/convert1.cs#15)] [!code-vb[Conceptual.CLSCompliant#15](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/convert1.vb#15)] -### 配列 +### 配列 CLS 準拠の配列は、次の規則に従います。 -- 配列の次元の下限値は 0 にする必要があります。 次の例では、下限が 1 の CLS 非準拠の配列を作成します。 属性の有無に関係なく、コンパイラでは、`Numbers.GetTenPrimes` メソッドによって返される配列が CLS に準拠していないことは検出されません。 +- 配列の次元の下限値は 0 にする必要があります。 次の例では、下限が 1 の CLS 非準拠の配列を作成します。 属性の有無に関係なく、コンパイラでは、`Numbers.GetTenPrimes` メソッドによって返される配列が CLS に準拠していないことは検出されません。 - [!code-csharp[Conceptual.CLSCompliant#8](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/array1.cs#8)] - [!code-vb[Conceptual.CLSCompliant#8](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/array1.vb#8)] + [!code-csharp[Conceptual.CLSCompliant#8](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/array1.cs#8)] [!code-vb[Conceptual.CLSCompliant#8](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/array1.vb#8)] -- すべての配列の要素が、CLS 準拠の型で構成されている必要があります。 次の例では、CLS 非準拠の配列を返す 2 つのメソッドを定義します。 最初のメソッドは、 値の配列を返します。 2 番目のメソッドは 値と 値を含む 配列を返します。 最初の配列は 型であるため、コンパイラによって非準拠として識別されますが、2 番目の配列に CLS 非準拠の要素が含まれていることは認識されません。 +- すべての配列の要素が、CLS 準拠の型で構成されている必要があります。 次の例では、CLS 非準拠の配列を返す 2 つのメソッドを定義します。 最初のメソッドは、 値の配列を返します。 2 番目のメソッドは 値と 値を含む 配列を返します。 最初の配列は 型であるため、コンパイラによって非準拠として識別されますが、2 番目の配列に CLS 非準拠の要素が含まれていることは認識されません。 - [!code-csharp[Conceptual.CLSCompliant#9](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/array2.cs#9)] - [!code-vb[Conceptual.CLSCompliant#9](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/array2.vb#9)] + [!code-csharp[Conceptual.CLSCompliant#9](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/array2.cs#9)] [!code-vb[Conceptual.CLSCompliant#9](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/array2.vb#9)] -- 配列パラメーターを持つメソッドのオーバーロードの解決は、配列であるという事実とその要素型に基づきます。 したがって、次のオーバーロードされた `GetSquares` メソッドの定義は CLS に準拠しています。 +- 配列パラメーターを持つメソッドのオーバーロードの解決は、配列であるという事実とその要素型に基づきます。 したがって、次のオーバーロードされた `GetSquares` メソッドの定義は CLS に準拠しています。 - [!code-csharp[Conceptual.CLSCompliant#10](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/array3.cs#10)] - [!code-vb[Conceptual.CLSCompliant#10](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/array3.vb#10)] + [!code-csharp[Conceptual.CLSCompliant#10](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/array3.cs#10)] [!code-vb[Conceptual.CLSCompliant#10](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/array3.vb#10)] -### インターフェイス - CLS 準拠のインターフェイスでは、プロパティ、イベント、および仮想メソッド \(実装のないメソッド\) を定義できます。 次の項目は、このインターフェイスには指定できません。 +### インターフェイス + CLS 準拠のインターフェイスでは、プロパティ、イベント、および仮想メソッド (実装のないメソッド) を定義できます。 次の項目は、このインターフェイスには指定できません。 -- 静的メソッドまたは静的フィールド。 インターフェイスで静的メンバーを定義すると、C\# と Visual Basic の両方のコンパイラでコンパイラ エラーが発生します。 +- 静的メソッドまたは静的フィールド。 インターフェイスで静的メンバーを定義すると、C# と Visual Basic の両方のコンパイラでコンパイラ エラーが発生します。 -- フィールド。 インターフェイスでフィールドを定義すると、C\# と Visual Basic の両方のコンパイラでコンパイラ エラーが発生します。 +- フィールド。 インターフェイスでフィールドを定義すると、C# と Visual Basic の両方のコンパイラでコンパイラ エラーが発生します。 -- CLS に準拠していないメソッド。 たとえば、次のインターフェイス定義には、CLS 非準拠とマークされているメソッド、`INumber.GetUnsigned` が含まれています。 この例では、コンパイラの警告が生成されます。 +- CLS に準拠していないメソッド。 たとえば、次のインターフェイス定義には、CLS 非準拠とマークされているメソッド、`INumber.GetUnsigned` が含まれています。 この例では、コンパイラの警告が生成されます。 - [!code-csharp[Conceptual.CLSCompliant#6](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/interface2.cs#6)] - [!code-vb[Conceptual.CLSCompliant#6](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/interface2.vb#6)] + [!code-csharp[Conceptual.CLSCompliant#6](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/interface2.cs#6)] [!code-vb[Conceptual.CLSCompliant#6](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/interface2.vb#6)] - この規則のため、CLS に準拠している型は、CLS に準拠していないメンバーを実装する必要はありません。 CLS 準拠のフレームワークによって、CLS に非準拠のインターフェイスを実装するクラスが公開されている場合、そのフレームワークには、CLS 非準拠のすべてのメンバーの具象実装も用意する必要があります。 + この規則のため、CLS に準拠している型は、CLS に準拠していないメンバーを実装する必要はありません。 CLS 準拠のフレームワークによって、CLS に非準拠のインターフェイスを実装するクラスが公開されている場合、そのフレームワークには、CLS 非準拠のすべてのメンバーの具象実装も用意する必要があります。 - CLS 準拠の言語コンパイラでは、クラスによって、複数のインターフェイスにある同じ名前およびシグネチャを持つメンバーを個別に実装できるようにすることも必要です。 C\# と Visual Basic の両方が[明示的なインターフェイス実装](../Topic/Explicit%20Interface%20Implementation%20\(C%23%20Programming%20Guide\).md)をサポートしており、同じ名前を持つメソッドを別々に実装できます。 Visual Basic では `Implements` キーワードもサポートされているので、特定のメンバーが実装するインターフェイスおよびメンバーを明示的に指定できます。 次の例は、明示的なインターフェイス実装として `Temperature` インターフェイスおよび `ICelsius` インターフェイスを実装する `IFahrenheit` クラスを定義することで、このシナリオを示しています。 + CLS 準拠の言語コンパイラでは、クラスによって、複数のインターフェイスにある同じ名前およびシグネチャを持つメンバーを個別に実装できるようにすることも必要です。 C# と Visual Basic の両方が[明示的なインターフェイス実装](~/docs/csharp/programming-guide/interfaces/explicit-interface-implementation.md)をサポートしており、同じ名前を持つメソッドを別々に実装できます。 Visual Basic では `Implements` キーワードもサポートされているので、特定のメンバーが実装するインターフェイスおよびメンバーを明示的に指定できます。 次の例は、明示的なインターフェイス実装として `Temperature` インターフェイスおよび `ICelsius` インターフェイスを実装する `IFahrenheit` クラスを定義することで、このシナリオを示しています。 - [!code-csharp[Conceptual.CLSCompliant#24](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/eii1.cs#24)] - [!code-vb[Conceptual.CLSCompliant#24](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/eii1.vb#24)] + [!code-csharp[Conceptual.CLSCompliant#24](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/eii1.cs#24)] [!code-vb[Conceptual.CLSCompliant#24](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/eii1.vb#24)] -### 列挙 +### 列挙 CLS 準拠の列挙型は、次の規則に従う必要があります。 -- 列挙体の基になる型は、組み込みの CLS 準拠の整数 \(、、、または \) である必要があります。 たとえば、次のコードでは、基になる型が の列挙体を定義しようとしますが、コンパイラの警告が生成されます。 +- 列挙体の基になる型は、組み込みの CLS 準拠の整数 (、、、または ) である必要があります。 たとえば、次のコードでは、基になる型が の列挙体を定義しようとしますが、コンパイラの警告が生成されます。 - [!code-csharp[Conceptual.CLSCompliant#7](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/enum3.cs#7)] - [!code-vb[Conceptual.CLSCompliant#7](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/enum3.vb#7)] + [!code-csharp[Conceptual.CLSCompliant#7](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/enum3.cs#7)] [!code-vb[Conceptual.CLSCompliant#7](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/enum3.vb#7)] -- 列挙型には、`Value__` 属性でマークされた という名前の単一インスタンス フィールドが必要です。 これにより、フィールド値を暗黙的に参照できます。 +- 列挙型には、`Value__` 属性でマークされた という名前の単一インスタンス フィールドが必要です。 これにより、フィールド値を暗黙的に参照できます。 -- 列挙体には、その列挙体自体の型と同じ型を持つリテラルな静的フィールドが含まれます。 たとえば、`State` および `State.On` の値を持つ `State.Off` 列挙体を定義すると、`State.On` と `State.Off` は両方ともリテラルな静的フィールドで、その型は `State` です。 +- 列挙体には、その列挙体自体の型と同じ型を持つリテラルな静的フィールドが含まれます。 たとえば、`State` および `State.On` の値を持つ `State.Off` 列挙体を定義すると、`State.On` と `State.Off` は両方ともリテラルな静的フィールドで、その型は `State` です。 - 列挙体は 2 種類あります。 - - 同時に指定できない一連の名前付き整数値を表す列挙体。 この列挙体の型は、 カスタム属性が存在しないことによって示されます。 + - 同時に指定できない一連の名前付き整数値を表す列挙体。 この列挙体の型は、 カスタム属性が存在しないことによって示されます。 - - 名前のない値を生成するために結合できる一連のビット フラグを表す列挙体。 この列挙体の型は、 カスタム属性が存在することによって示されます。 + - 名前のない値を生成するために結合できる一連のビット フラグを表す列挙体。 この列挙体の型は、 カスタム属性が存在することによって示されます。 詳細については、 構造体のドキュメントを参照してください。 -- 列挙体の値は、その列挙体の指定された値に限定されません。 つまり、列挙体の値の範囲は、その列挙体の基になる値の範囲です。 メソッドを使用すると、指定された値が列挙体のメンバーかどうかを確認できます。 +- 列挙体の値は、その列挙体の指定された値に限定されません。 つまり、列挙体の値の範囲は、その列挙体の基になる値の範囲です。 メソッドを使用すると、指定された値が列挙体のメンバーかどうかを確認できます。 -### 一般的な型メンバー - 共通言語仕様では、すべてのフィールドとメソッドに、特定のクラスのメンバーとしてアクセスする必要があります。 したがって、グローバルな静的フィールドおよび静的メソッド \(つまり、型とは別に定義された静的フィールドまたは静的メソッド\) は CLS に準拠していません。 グローバル フィールドまたはグローバル メソッドをソース コードに追加しようとすると、C\# と Visual Basic の両方のコンパイラでコンパイラ エラーが発生します。 +### 一般的な型メンバー + 共通言語仕様では、すべてのフィールドとメソッドに、特定のクラスのメンバーとしてアクセスする必要があります。 したがって、グローバルな静的フィールドおよび静的メソッド (つまり、型とは別に定義された静的フィールドまたは静的メソッド) は CLS に準拠していません。 グローバル フィールドまたはグローバル メソッドをソース コードに追加しようとすると、C# と Visual Basic の両方のコンパイラでコンパイラ エラーが発生します。 - 共通言語仕様では、標準のマネージ呼び出し規約のみがサポートされます。 アンマネージ呼び出し規約と、`varargs` キーワードでマークされた可変個引数リストを持つメソッドはサポートされません。 標準のマネージ呼び出し規約と互換性がある可変個引数リストについては、 キーワード \(C\# の場合\)、`params` キーワード \(Visual Basic の場合\) など、`ParamArray` 属性または個々の言語の実装を使用します。 + 共通言語仕様では、標準のマネージ呼び出し規約のみがサポートされます。 アンマネージ呼び出し規約と、`varargs` キーワードでマークされた可変個引数リストを持つメソッドはサポートされません。 標準のマネージ呼び出し規約と互換性がある可変個引数リストについては、 キーワード (C# の場合)、`params` キーワード (Visual Basic の場合) など、`ParamArray` 属性または個々の言語の実装を使用します。 -### メンバーのアクセシビリティ - 継承されたメンバーをオーバーライドしても、そのメンバーのアクセシビリティは変更できません。 たとえば、基底クラスのパブリック メソッドは、派生クラスのプライベート メソッドではオーバーライドできません。 ただし例外が 1 つあります。あるアセンブリ内にある、別のアセンブリの型でオーバーライドされた `protected internal` メンバー \(C\# の場合\) または `Protected Friend` メンバー \(Visual Basic の場合\) です。 この場合、オーバーライドのアクセシビリティは `Protected` です。 +### メンバーのアクセシビリティ + 継承されたメンバーをオーバーライドしても、そのメンバーのアクセシビリティは変更できません。 たとえば、基底クラスのパブリック メソッドは、派生クラスのプライベート メソッドではオーバーライドできません。 ただし例外が 1 つあります。あるアセンブリ内にある、別のアセンブリの型でオーバーライドされた `protected internal` メンバー (C# の場合) または `Protected Friend` メンバー (Visual Basic の場合) です。 この場合、オーバーライドのアクセシビリティは `Protected` です。 - 次の例は、 属性が `true` で、`Person` の派生クラス `Animal` が、`Species` プロパティのアクセシビリティをパブリックからプライベートに変更しようとするときに発生するエラーを示しています。 アクセシビリティがパブリックに変更されると、コンパイルが正常に行われます。 + 次の例は、 属性が `true` で、`Person` の派生クラス `Animal` が、`Species` プロパティのアクセシビリティをパブリックからプライベートに変更しようとするときに発生するエラーを示しています。 アクセシビリティがパブリックに変更されると、コンパイルが正常に行われます。 - [!code-csharp[Conceptual.CLSCompliant#28](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/accessibility1.cs#28)] - [!code-vb[Conceptual.CLSCompliant#28](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/accessibility1.vb#28)] + [!code-csharp[Conceptual.CLSCompliant#28](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/accessibility1.cs#28)] [!code-vb[Conceptual.CLSCompliant#28](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/accessibility1.vb#28)] - メンバーにアクセスできる場合は必ず、そのメンバーのシグネチャの型にアクセスできなければなりません。 たとえば、これは、パブリック メンバーには、型がプライベート、プロテクト、または内部のパラメーターを含められないことを意味します。 次の例は、`StringWrapper` クラス コンストラクターが、文字列値のラップ方法を決定する内部 `StringOperationType` 列挙値を公開した場合に発生するコンパイラ エラーを示しています。 + メンバーにアクセスできる場合は必ず、そのメンバーのシグネチャの型にアクセスできなければなりません。 たとえば、これは、パブリック メンバーには、型がプライベート、プロテクト、または内部のパラメーターを含められないことを意味します。 次の例は、`StringWrapper` クラス コンストラクターが、文字列値のラップ方法を決定する内部 `StringOperationType` 列挙値を公開した場合に発生するコンパイラ エラーを示しています。 - [!code-csharp[Conceptual.CLSCompliant#27](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/accessibility3.cs#27)] - [!code-vb[Conceptual.CLSCompliant#27](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/accessibility3.vb#27)] + [!code-csharp[Conceptual.CLSCompliant#27](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/accessibility3.cs#27)] [!code-vb[Conceptual.CLSCompliant#27](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/accessibility3.vb#27)] -### ジェネリック型とメンバー - 入れ子になった型には、少なくともその外側の型と同じ数のジェネリック パラメーターが必要です。 このジェネリック パラメーターは、外側の型のジェネリック パラメーターに位置によって対応します。 ジェネリック型に新しいジェネリック パラメーターを含めることもできます。 +### ジェネリック型とメンバー + 入れ子になった型には、少なくともその外側の型と同じ数のジェネリック パラメーターが必要です。 このジェネリック パラメーターは、外側の型のジェネリック パラメーターに位置によって対応します。 ジェネリック型に新しいジェネリック パラメーターを含めることもできます。 - 外側の型のジェネリック型パラメーターと、その入れ子になった型の関係は、個別の言語構文によって非表示になっていることがあります。 次の例では、入れ子になった 2 つのクラス、`Outer` および `Inner1A` が、ジェネリック型 `Inner1B` に含まれます。 各クラスが `ToString` から継承した メソッドへの呼び出しは、入れ子になった各クラスに、その外側のクラスの型パラメーターが含まれていることを示しています。 + 外側の型のジェネリック型パラメーターと、その入れ子になった型の関係は、個別の言語構文によって非表示になっていることがあります。 次の例では、入れ子になった 2 つのクラス、`Outer` および `Inner1A` が、ジェネリック型 `Inner1B` に含まれます。 各クラスが `ToString` から継承した メソッドへの呼び出しは、入れ子になった各クラスに、その外側のクラスの型パラメーターが含まれていることを示しています。 - [!code-csharp[Conceptual.CLSCompliant#29](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/nestedgenerics2.cs#29)] - [!code-vb[Conceptual.CLSCompliant#29](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/nestedgenerics2.vb#29)] + [!code-csharp[Conceptual.CLSCompliant#29](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/nestedgenerics2.cs#29)] [!code-vb[Conceptual.CLSCompliant#29](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/nestedgenerics2.vb#29)] - ジェネリック型の名前は、フォーム *name*```*n* でエンコードされます。ここで、*name* は型の名前、``` は文字リテラル、*n* は型で宣言されたパラメーターの数、入れ子になったジェネリック型の場合は、新しく導入された型パラメーターの数です。 ジェネリック型の名前のエンコーディングは、主に、リフレクションを使用してライブラリ内の CLS 準拠のジェネリック型にアクセスする開発者が使用します。 + ジェネリック型の名前は、*name\`n* の形でエンコードされます。ここで、*name* は型の名前、\` は文字リテラル、*n* は型で宣言されたパラメーターの数 (入れ子になったジェネリック型の場合は新しく導入された型パラメーターの数) です。 ジェネリック型の名前のエンコーディングは、主に、リフレクションを使用してライブラリ内の CLS 準拠のジェネリック型にアクセスする開発者が使用します。 - 制約がジェネリック型に適用される場合は、制約として使用されるすべての型も CLS に準拠している必要があります。 次の例では、CLS に準拠していない `BaseClass` という名前のクラスと、型パラメーターが `BaseCollection` から派生しなければならない `BaseClass` という名前のジェネリック クラスを定義します。 ただし、`BaseClass` が CLS に準拠していないので、コンパイラによって警告が生成されます。 + 制約がジェネリック型に適用される場合は、制約として使用されるすべての型も CLS に準拠している必要があります。 次の例では、CLS に準拠していない `BaseClass` という名前のクラスと、型パラメーターが `BaseCollection` から派生しなければならない `BaseClass` という名前のジェネリック クラスを定義します。 ただし、`BaseClass` が CLS に準拠していないので、コンパイラによって警告が生成されます。 - [!code-csharp[Conceptual.CLSCompliant#34](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/generics5.cs#34)] - [!code-vb[Conceptual.CLSCompliant#34](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/generics5.vb#34)] + [!code-csharp[Conceptual.CLSCompliant#34](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/generics5.cs#34)] [!code-vb[Conceptual.CLSCompliant#34](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/generics5.vb#34)] - ジェネリック型がジェネリック基本型から派生している場合、そのジェネリック型は、基本型に対する制約も必ず満たすように制約を再宣言する必要があります。 次の例では、任意の数値型を表すことができる `Number` を定義します。 また、浮動小数点値を表す `FloatingPoint` クラスも定義します。 ただし、ソース コードはコンパイルされません。`Number` \(T は値型\) の制約は `FloatingPoint` に適用されないからです。 + ジェネリック型がジェネリック基本型から派生している場合、そのジェネリック型は、基本型に対する制約も必ず満たすように制約を再宣言する必要があります。 次の例では、任意の数値型を表すことができる `Number` を定義します。 また、浮動小数点値を表す `FloatingPoint` クラスも定義します。 ただし、ソース コードはコンパイルされません。`Number` (T は値型) の制約は `FloatingPoint` に適用されないからです。 - [!code-csharp[Conceptual.CLSCompliant#30](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/generics2a.cs#30)] - [!code-vb[Conceptual.CLSCompliant#30](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/generics2a.vb#30)] + [!code-csharp[Conceptual.CLSCompliant#30](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/generics2a.cs#30)] [!code-vb[Conceptual.CLSCompliant#30](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/generics2a.vb#30)] 制約が `FloatingPoint` クラスに追加されると、コンパイルが正常に行われます。 - [!code-csharp[Conceptual.CLSCompliant#31](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/generics2.cs#31)] - [!code-vb[Conceptual.CLSCompliant#31](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/generics2.vb#31)] + [!code-csharp[Conceptual.CLSCompliant#31](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/generics2.cs#31)] [!code-vb[Conceptual.CLSCompliant#31](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/generics2.vb#31)] - 共通言語仕様では、入れ子になった型とプロテクト メンバーに対して従来のインスタンス化ごとのモデルが適用されます。 オープン ジェネリック型では、フィールドまたはメンバーのシグネチャに、入れ子になったプロテクト ジェネリック型の特定のインスタンス化が含まれている場合、これらのフィールドやメンバーは公開できません。 ジェネリックの基底クラスやインターフェイスについて特定のインスタンス化を拡張する非ジェネリック型では、フィールドまたはメンバーのシグネチャに、入れ子になったプロテクト ジェネリック型の別のインスタンス化が含まれている場合、これらのフィールドやメンバーは公開できません。 + 共通言語仕様では、入れ子になった型とプロテクト メンバーに対して従来のインスタンス化ごとのモデルが適用されます。 オープン ジェネリック型では、フィールドまたはメンバーのシグネチャに、入れ子になったプロテクト ジェネリック型の特定のインスタンス化が含まれている場合、これらのフィールドやメンバーは公開できません。 ジェネリックの基底クラスやインターフェイスについて特定のインスタンス化を拡張する非ジェネリック型では、フィールドまたはメンバーのシグネチャに、入れ子になったプロテクト ジェネリック型の別のインスタンス化が含まれている場合、これらのフィールドやメンバーは公開できません。 - 次の例では、ジェネリック型 `C1` \(Visual Basic の場合は `C1(Of T)`\)、およびプロテクト クラス `C1.N` \(Visual Basic の場合は `C1(Of T).N`\) を定義します。 `C1` には、2 つのメソッド `M1` と `M2` があります。 ただし、`M1` は、`C1.N` \(`C1(Of Integer).N`\) オブジェクトを C1\ \(`C1(Of T)`\) から返そうとするので、CLS に準拠していません。 2 番目の `C2` クラスは、 `C1` \(`C1(Of Long)`\) から派生しています。 これには、`M3` と `M4` の 2 つのメソッドがあります。 `M3` は、`C1.N` \(`C1(Of Integer).N`\) オブジェクトを `C1` のサブクラスから返そうとするので、CLS に準拠していません。 言語コンパイラはさらに制限されている可能性があります。 この例では、Visual Basic で `M4` をコンパイルしようとするとエラーが表示されます。 + 次の例では、ジェネリック型 `C1` (Visual Basic の場合は `C1(Of T)`)、およびプロテクト クラス `C1.N` (Visual Basic の場合は `C1(Of T).N`) を定義します。 `C1` には、2 つのメソッド `M1` と `M2` があります。 ただし、`M1` は、`C1.N` (`C1(Of Integer).N`) オブジェクトを C1\ (または `C1(Of T)`) から返そうとするので、CLS に準拠していません。 2 番目の `C2` クラスは、`C1` (`C1(Of Long)`) から派生しています。 これには、`M3` と `M4` の 2 つのメソッドがあります。 `M3` は、`C1.N` (`C1(Of Integer).N`) オブジェクトを `C1` のサブクラスから返そうとするので、CLS に準拠していません。 言語コンパイラはさらに制限されている可能性があります。 この例では、Visual Basic で `M4` をコンパイルしようとするとエラーが表示されます。 - [!code-csharp[Conceptual.CLSCompliant#32](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/generics4.cs#32)] - [!code-vb[Conceptual.CLSCompliant#32](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/generics4.vb#32)] + [!code-csharp[Conceptual.CLSCompliant#32](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/generics4.cs#32)] [!code-vb[Conceptual.CLSCompliant#32](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/generics4.vb#32)] -### コンストラクター +### コンストラクター CLS 準拠のクラスと構造体のコンストラクターは、次の規則に従う必要があります。 -- 派生クラスのコンストラクターは、継承されたインスタンス データにアクセスする前に、基底クラスのインスタンス コンストラクターを呼び出す必要があります。 これは、基底クラスのコンストラクターは派生クラスには継承されないからです。 この規則は、直接継承をサポートしない構造体に適用されません。 +- 派生クラスのコンストラクターは、継承されたインスタンス データにアクセスする前に、基底クラスのインスタンス コンストラクターを呼び出す必要があります。 これは、基底クラスのコンストラクターは派生クラスには継承されないからです。 この規則は、直接継承をサポートしない構造体に適用されません。 - 次の例に示すように、コンパイラは、通常、CLS 準拠とは別にこの規則を適用します。 これにより、`Doctor` クラスから派生した `Person` クラスが作成されますが、`Doctor` クラスでは、継承されたインスタンス フィールドを初期化するための `Person` クラス コンストラクターは呼び出されません。 + 次の例に示すように、コンパイラは、通常、CLS 準拠とは別にこの規則を適用します。 これにより、`Doctor` クラスから派生した `Person` クラスが作成されますが、`Doctor` クラスでは、継承されたインスタンス フィールドを初期化するための `Person` クラス コンストラクターは呼び出されません。 - [!code-csharp[Conceptual.CLSCompliant#11](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/ctor1.cs#11)] - [!code-vb[Conceptual.CLSCompliant#11](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/ctor1.vb#11)] + [!code-csharp[Conceptual.CLSCompliant#11](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/ctor1.cs#11)] [!code-vb[Conceptual.CLSCompliant#11](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/ctor1.vb#11)] -- オブジェクト作成以外の目的で、オブジェクト コンストラクターを呼び出すことはできません。 また、オブジェクトを 2 度初期化することもできません。 たとえば、これは メソッド、および などの逆シリアル化メソッドでは、コンストラクターを呼び出してはいけないことを意味します。 +- オブジェクト作成以外の目的で、オブジェクト コンストラクターを呼び出すことはできません。 また、オブジェクトを 2 度初期化することもできません。 たとえば、これは メソッド、および などの逆シリアル化メソッドでは、コンストラクターを呼び出してはいけないことを意味します。 -### プロパティ +### プロパティ CLS 準拠型のプロパティは、次の規則に従う必要があります。 -- プロパティには setter、getter、またはこの両方が必ず必要です。 アセンブリでは、これらは特殊なメソッドとして実装されます。つまり、個別のメソッドとして \(getter は `get_`*propertyname*、setter は `set_`*propertyname* という名前で\) 表示され、アセンブリのメタデータでは `SpecialName` としてマークされます。 C\# コンパイラおよび Visual Basic コンパイラでは、この規則が自動的に適用されます。 属性を適用する必要はありません。 +- プロパティには setter、getter、またはこの両方が必ず必要です。 アセンブリでは、これらは特殊なメソッドとして実装されます。つまり、個別のメソッドとして (getter は `get_`*propertyname*、setter は `set_`*propertyname* という名前で) 表示され、アセンブリのメタデータでは `SpecialName` としてマークされます。 C# コンパイラおよび Visual Basic コンパイラでは、この規則が自動的に適用されます。 属性を適用する必要はありません。 -- プロパティの型は、プロパティ get アクセス操作子、および set アクセス操作子の最後の引数の戻り値の型です。 これらの型は CLS に準拠している必要があり、引数を参照によってプロパティに割り当てることはできません \(つまり、マネージ ポインターにできません\)。 +- プロパティの型は、プロパティ get アクセス操作子、および set アクセス操作子の最後の引数の戻り値の型です。 これらの型は CLS に準拠している必要があり、引数を参照によってプロパティに割り当てることはできません (つまり、マネージ ポインターにできません)。 -- プロパティに get アクセス操作子と set アクセス操作子の両方がある場合は、両方が仮想、両方が静的、または両方がインスタンスである必要があります。 C\# コンパイラおよび Visual Basic コンパイラでは、この規則がプロパティ定義構文によって自動的に適用されます。 +- プロパティに get アクセス操作子と set アクセス操作子の両方がある場合は、両方が仮想、両方が静的、または両方がインスタンスである必要があります。 C# コンパイラおよび Visual Basic コンパイラでは、この規則がプロパティ定義構文によって自動的に適用されます。 -### イベント - イベントは、名前と型によって定義されます。 イベントの型は、イベントの表示に使用されるデリゲートです。 たとえば、 イベントは 型です。 イベント自体のほか、イベント名に基づく名前の 3 つのメソッドがイベントの実装を提供し、アセンブリのメタデータで `SpecialName` としてマークされています。 +### イベント + イベントは、名前と型によって定義されます。 イベントの型は、イベントの表示に使用されるデリゲートです。 たとえば、 イベントは 型です。 イベント自体のほか、イベント名に基づく名前の 3 つのメソッドがイベントの実装を提供し、アセンブリのメタデータで `SpecialName` としてマークされています。 -- イベント ハンドラーを追加するメソッド \(`add_`*EventName*\)。 たとえば、 イベントのイベント サブスクリプション メソッドの名前は `add_AssemblyResolve` です。 +- イベント ハンドラーを追加するメソッド (`add_`*EventName*)。 たとえば、 イベントのイベント サブスクリプション メソッドの名前は `add_AssemblyResolve` です。 -- イベント ハンドラーを削除するメソッド \(`remove_`*EventName*\)。 たとえば、 イベントの削除メソッドの名前は `remove_AssemblyResolve` です。 +- イベント ハンドラーを削除するメソッド (`remove_`*EventName*)。 たとえば、 イベントの削除メソッドの名前は `remove_AssemblyResolve` です。 -- イベントが発生したことを示すメソッド \(`raise_`*EventName*\)。 +- イベントが発生したことを示すメソッド (`raise_`*EventName*)。 > [!NOTE] > イベントに関する共通言語仕様の規則は、ほとんどが言語コンパイラによって実装され、コンポーネント開発者が意識せずに使用できます。 - イベントの追加、削除、発生の各メソッドには同じアクセシビリティが必要です。 また、すべてが、静的メソッド、インスタンス メソッド、仮想メソッドのいずれかでなければなりません。 イベントを追加および削除するメソッドには、イベント デリゲート型の型を持つパラメーターが 1 つあります。 追加メソッドおよび削除メソッドは両方とも存在するか、両方存在しないかのいずれかでなければなりません。 + イベントの追加、削除、発生の各メソッドには同じアクセシビリティが必要です。 また、すべてが、静的メソッド、インスタンス メソッド、仮想メソッドのいずれかでなければなりません。 イベントを追加および削除するメソッドには、イベント デリゲート型の型を持つパラメーターが 1 つあります。 追加メソッドおよび削除メソッドは両方とも存在するか、両方存在しないかのいずれかでなければなりません。 - 次の例では、2 つのポイントの気温の差がしきい値と等しいか、それを超えた場合に `Temperature` イベントを発生させる、`TemperatureChanged` という名前の CLS 準拠クラスを定義します。 `Temperature` クラスは、イベント ハンドラーを選択的に実行できるように、`raise_TemperatureChanged` メソッドを明示的に定義します。 + 次の例では、2 つのポイントの気温の差がしきい値と等しいか、それを超えた場合に `Temperature` イベントを発生させる、`TemperatureChanged` という名前の CLS 準拠クラスを定義します。 `Temperature` クラスは、イベント ハンドラーを選択的に実行できるように、`raise_TemperatureChanged` メソッドを明示的に定義します。 - [!code-csharp[Conceptual.CLSCompliant#20](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/event1.cs#20)] - [!code-vb[Conceptual.CLSCompliant#20](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/event1.vb#20)] + [!code-csharp[Conceptual.CLSCompliant#20](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/event1.cs#20)] [!code-vb[Conceptual.CLSCompliant#20](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/event1.vb#20)] -### Overloads +### Overloads 共通言語仕様では、次の要件がオーバーロード メンバーに適用されます。 -- メンバーは、パラメーターの数および型に基づいてオーバーロードできます。 オーバーロードを区別するときに、呼び出し規約、戻り値の型、メソッドまたはそのパラメーターに適用されているカスタム修飾子、およびパラメーターが値渡しか参照渡しかは考慮されません。 例については、「[名前付け規則](#naming)」で、名前がスコープ内で一意であることを要求する要件のコードを参照してください。 +- メンバーは、パラメーターの数および型に基づいてオーバーロードできます。 オーバーロードを区別するときに、呼び出し規約、戻り値の型、メソッドまたはそのパラメーターに適用されているカスタム修飾子、およびパラメーターが値渡しか参照渡しかは考慮されません。 例については、「[名前付け規則](#naming)」で、名前がスコープ内で一意であることを要求する要件のコードを参照してください。 -- プロパティおよびメソッドのみオーバーロードできる。 フィールドとイベントはオーバーロードできません。 +- プロパティおよびメソッドのみオーバーロードできる。 フィールドとイベントはオーバーロードできません。 - ジェネリック メソッドは、ジェネリック パラメーターの数に基づいてオーバーロードできます。 > [!NOTE] -> `op_Explicit` 演算子および `op_Implicit` 演算子にはこの規則が適用されず、戻り値は、オーバーロード解決のためのメソッド シグネチャの一部として見なされません。 この 2 つの演算子は、そのパラメーターと戻り値の両方に基づいてオーバーロードできます。 +> `op_Explicit` 演算子および `op_Implicit` 演算子にはこの規則が適用されず、戻り値は、オーバーロード解決のためのメソッド シグネチャの一部として見なされません。 この 2 つの演算子は、そのパラメーターと戻り値の両方に基づいてオーバーロードできます。 -### 例外 - 例外オブジェクトは 、または の別の派生型から派生する必要があります。 次の例は、`ErrorClass` というカスタム クラスを例外処理に使用したときに発生するコンパイラ エラーを示しています。 +### 例外 + 例外オブジェクトは 、または の別の派生型から派生する必要があります。 次の例は、`ErrorClass` というカスタム クラスを例外処理に使用したときに発生するコンパイラ エラーを示しています。 - [!code-csharp[Conceptual.CLSCompliant#13](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/exceptions1.cs#13)] - [!code-vb[Conceptual.CLSCompliant#13](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/exceptions1.vb#13)] + [!code-csharp[Conceptual.CLSCompliant#13](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/exceptions1.cs#13)] [!code-vb[Conceptual.CLSCompliant#13](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/exceptions1.vb#13)] - このエラーを修正するには、`ErrorClass` から継承するように クラスを指定する必要があります。 また、`Message` プロパティはオーバーライドする必要があります。 次の例では、このエラーを修正して CLS 準拠の `ErrorClass` クラスを定義します。 + このエラーを修正するには、`ErrorClass` から継承するように クラスを指定する必要があります。 また、`Message` プロパティはオーバーライドする必要があります。 次の例では、このエラーを修正して CLS 準拠の `ErrorClass` クラスを定義します。 - [!code-csharp[Conceptual.CLSCompliant#14](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/exceptions2.cs#14)] - [!code-vb[Conceptual.CLSCompliant#14](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/exceptions2.vb#14)] + [!code-csharp[Conceptual.CLSCompliant#14](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/exceptions2.cs#14)] [!code-vb[Conceptual.CLSCompliant#14](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/exceptions2.vb#14)] -### 属性 - .NET Framework アセンブリでは、カスタム属性に拡張可能機構が用意されており、そのカスタム属性を格納し、アセンブリ、型、メンバー、メソッド パラメーターなどのプログラミング オブジェクトに関するメタデータを取得します。 カスタム属性は 、または の派生型から派生する必要があります。 +### 属性 + .NET Framework アセンブリでは、カスタム属性に拡張可能機構が用意されており、そのカスタム属性を格納し、アセンブリ、型、メンバー、メソッド パラメーターなどのプログラミング オブジェクトに関するメタデータを取得します。 カスタム属性は 、または の派生型から派生する必要があります。 - 規則に違反する例を次に示します。 この例では、`NumericAttribute` から派生していない クラスを定義します。 コンパイラ エラーは、CLS 非準拠の属性が適用されている場合にのみ発生します。クラスが定義されているときではありません。 + 規則に違反する例を次に示します。 この例では、`NumericAttribute` から派生していない クラスを定義します。 コンパイラ エラーは、CLS 非準拠の属性が適用されている場合にのみ発生します。クラスが定義されているときではありません。 - [!code-csharp[Conceptual.CLSCompliant#18](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/attribute1.cs#18)] - [!code-vb[Conceptual.CLSCompliant#18](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/attribute1.vb#18)] + [!code-csharp[Conceptual.CLSCompliant#18](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/attribute1.cs#18)] [!code-vb[Conceptual.CLSCompliant#18](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/attribute1.vb#18)] CLS 準拠の属性のコンストラクターまたはプロパティは、次の型のみを公開できます。 @@ -488,31 +466,30 @@ caps.handback.revision: 33 - 基になる型が 、、、または である列挙体の型。 - 次の例では、`DescriptionAttribute` から派生する クラスを定義します。 クラス コンストラクターには型 `Descriptor` のパラメーターがあるので、クラスは CLS に準拠していません。 C\# コンパイラでは警告が出力されますが、コンパイルは正常に行われます。一方、Visual Basic コンパイラでは警告もエラーも出力されません。 + 次の例では、`DescriptionAttribute` から派生する クラスを定義します。 クラス コンストラクターには型 `Descriptor` のパラメーターがあるので、クラスは CLS に準拠していません。 C# コンパイラでは警告が出力されますが、コンパイルは正常に行われます。一方、Visual Basic コンパイラでは警告もエラーも出力されません。 - [!code-csharp[Conceptual.CLSCompliant#33](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/attribute2.cs#33)] - [!code-vb[Conceptual.CLSCompliant#33](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/attribute2.vb#33)] + [!code-csharp[Conceptual.CLSCompliant#33](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/attribute2.cs#33)] [!code-vb[Conceptual.CLSCompliant#33](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/attribute2.vb#33)] -## CLSCompliantAttribute 属性 - 属性は、プログラム要素が共通言語仕様でコンパイルされているかどうかを示すために使用されます。 コンストラクターには、プログラム要素が CLS に準拠しているかどうかを示す 1 つの必須パラメーター、`isCompliant` が含まれます。 +## CLSCompliantAttribute 属性 + 属性は、プログラム要素が共通言語仕様でコンパイルされているかどうかを示すために使用されます。 コンストラクターには、プログラム要素が CLS に準拠しているかどうかを示す 1 つの必須パラメーター、`isCompliant` が含まれます。 - コンパイル時に、CLS 準拠が前提とされる非準拠要素が検出され、警告が出力されます。 非準拠として明示的に宣言された型またはメンバーに対しては、警告は出力されません。 + コンパイル時に、CLS 準拠が前提とされる非準拠要素が検出され、警告が出力されます。 非準拠として明示的に宣言された型またはメンバーに対しては、警告は出力されません。 コンポーネント開発者は、次の 2 とおりの目的で 属性を使用できます。 -- コンポーネントによって公開されたパブリック インターフェイスの CLS 準拠部分と CLS 非準拠部分を定義する。 この属性を使用して特定のプログラム要素を CLS 準拠としてマークすると、.NET Framework を対象とするすべてのツールおよび言語から、これらの要素に必ずアクセスできるようになります。 +- コンポーネントによって公開されたパブリック インターフェイスの CLS 準拠部分と CLS 非準拠部分を定義する。 この属性を使用して特定のプログラム要素を CLS 準拠としてマークすると、.NET Framework を対象とするすべてのツールおよび言語から、これらの要素に必ずアクセスできるようになります。 -- コンポーネント ライブラリのパブリック インターフェイスが CLS に準拠するプログラム要素のみを公開するように保証する。 要素が CLS 非準拠の場合は、通常、警告が表示されます。 +- コンポーネント ライブラリのパブリック インターフェイスが CLS に準拠するプログラム要素のみを公開するように保証する。 要素が CLS 非準拠の場合は、通常、警告が表示されます。 > [!WARNING] -> 言語コンパイラでは、 属性が使用されているかどうかに関係なく、CLS 準拠の規則が適用される場合があります。 たとえば、インターフェイスの静的メンバーを定義すると CLS の規則に違反します。 ただし、インターフェイスで `static` メンバー \(C\# の場合\) または `Shared` メンバー \(Visual Basic の場合\) を定義すると、C\# と Visual Basic の両方のコンパイラでエラー メッセージが表示され、アプリはコンパイルされません。 +> 言語コンパイラでは、 属性が使用されているかどうかに関係なく、CLS 準拠の規則が適用される場合があります。 たとえば、インターフェイスの静的メンバーを定義すると CLS の規則に違反します。 ただし、インターフェイスで `static` メンバー (C# の場合) または `Shared` メンバー (Visual Basic の場合) を定義すると、C# と Visual Basic の両方のコンパイラでエラー メッセージが表示され、アプリはコンパイルされません。 - 属性は、値 が指定された 属性でマークされます。 この値を使用すると、 属性を、アセンブリ、モジュール、型 \(クラス、構造体、列挙体、インターフェイス、およびデリゲート\)、型パラメーター \(コンストラクター、メソッド、プロパティ、フィールド、およびイベント\)、パラメーター、ジェネリック パラメーター、戻り値など、すべてのプログラム要素に適用できます。 ただし、実際は、アセンブリ、型、および型メンバーだけに属性を適用することをお勧めします。 そうしないと、属性は、コンパイラによってライブラリのパブリック インターフェイスで非準拠パラメーター、ジェネリック パラメーター、または戻り値が検出されたときに必ず無視され、コンパイラ警告が引き続き生成されます。 + 属性は、値 が指定された 属性でマークされます。 この値を使用すると、 属性を、アセンブリ、モジュール、型 (クラス、構造体、列挙体、インターフェイス、およびデリゲート)、型パラメーター (コンストラクター、メソッド、プロパティ、フィールド、およびイベント)、パラメーター、ジェネリック パラメーター、戻り値など、すべてのプログラム要素に適用できます。 ただし、実際は、アセンブリ、型、および型メンバーだけに属性を適用することをお勧めします。 そうしないと、属性は、コンパイラによってライブラリのパブリック インターフェイスで非準拠パラメーター、ジェネリック パラメーター、または戻り値が検出されたときに必ず無視され、コンパイラ警告が引き続き生成されます。 - 属性の値は、内包型プログラム要素によって継承されます。 たとえば、アセンブリが CLS 準拠としてマークされている場合は、その型も CLS に準拠します。 型が CLS 準拠としてマークされている場合は、その入れ子になった型とメンバーも CLS に準拠します。 + 属性の値は、内包型プログラム要素によって継承されます。 たとえば、アセンブリが CLS 準拠としてマークされている場合は、その型も CLS に準拠します。 型が CLS 準拠としてマークされている場合は、その入れ子になった型とメンバーも CLS に準拠します。 - 継承された準拠状況を明示的にオーバーライドするには、 属性を、格納されているプログラム要素に適用します。 たとえば、 値が `isCompliant` に指定された `false` 属性を使用すると、準拠アセンブリで非準拠型を定義できます。また、`isCompliant` 値が `true` に指定された属性を使用すると、非準拠アセンブリで準拠型を定義できます。 準拠型で非準拠メンバーを定義することもできます。 ただし、非準拠型は準拠メンバーを持つことができないので、`isCompliant` 値が `true` に指定された属性では非準拠型から継承をオーバーライドできません。 + 継承された準拠状況を明示的にオーバーライドするには、 属性を、格納されているプログラム要素に適用します。 たとえば、 値が `isCompliant` に指定された `false` 属性を使用すると、準拠アセンブリで非準拠型を定義できます。また、`isCompliant` 値が `true` に指定された属性を使用すると、非準拠アセンブリで準拠型を定義できます。 準拠型で非準拠メンバーを定義することもできます。 ただし、非準拠型は準拠メンバーを持つことができないので、`isCompliant` 値が `true` に指定された属性では非準拠型から継承をオーバーライドできません。 コンポーネントを開発するときは必ず、 属性を使用して、アセンブリ、その型、およびそのメンバーが CLS に準拠しているかどうかを指定することをお勧めします。 @@ -526,20 +503,19 @@ caps.handback.revision: 33 4. CLS 非準拠メンバーの CLS 準拠の代替を指定します。 - 非準拠の型とメンバーすべてを正常にマークした場合、非準拠の警告は出力されません。 ただし、どのメンバーが CLS に準拠していないかを提示し、CLS 準拠の代替を製品ドキュメントに示すことをお勧めします。 + 非準拠の型とメンバーすべてを正常にマークした場合、非準拠の警告は出力されません。 ただし、どのメンバーが CLS に準拠していないかを提示し、CLS 準拠の代替を製品ドキュメントに示すことをお勧めします。 - 次の例では、 属性を使用して、CLS 準拠のアセンブリと、2 つの CLS 非準拠のメンバーを持つ型、`CharacterUtilities` を定義します。 両メンバーとも `CLSCompliant(false)` 属性でタグ付けされているので、警告は生成されません。 また、クラスには、両方のメソッド用の CLS 準拠の代替も用意されています。 通常、CLS 準拠の代替を用意するには、2 つのオーバーロードを `ToUTF16` メソッドに追加するだけです。 ただし、戻り値に基づいてメソッドをオーバーロードできないので、CLS 準拠のメソッドの名前は、非準拠のメソッドの名前とは異なります。 + 次の例では、 属性を使用して、CLS 準拠のアセンブリと、2 つの CLS 非準拠のメンバーを持つ型、`CharacterUtilities` を定義します。 両メンバーとも `CLSCompliant(false)` 属性でタグ付けされているので、警告は生成されません。 また、クラスには、両方のメソッド用の CLS 準拠の代替も用意されています。 通常、CLS 準拠の代替を用意するには、2 つのオーバーロードを `ToUTF16` メソッドに追加するだけです。 ただし、戻り値に基づいてメソッドをオーバーロードできないので、CLS 準拠のメソッドの名前は、非準拠のメソッドの名前とは異なります。 - [!code-csharp[Conceptual.CLSCompliant#35](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/indicator3.cs#35)] - [!code-vb[Conceptual.CLSCompliant#35](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/indicator3.vb#35)] + [!code-csharp[Conceptual.CLSCompliant#35](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/indicator3.cs#35)] [!code-vb[Conceptual.CLSCompliant#35](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.clscompliant/vb/indicator3.vb#35)] - ライブラリではなくアプリを開発している場合 \(つまり、他のアプリ開発者が使用できる型またはメンバーを公開しない場合\)、アプリが使用するプログラム要素は、そのプログラム要素が使用する言語でサポートされていない場合に CLS に準拠する必要があります。 この場合、CLS 非準拠の要素を使用しようとすると、言語コンパイラによってエラーが生成されます。 + ライブラリではなくアプリを開発している場合 (つまり、他のアプリ開発者が使用できる型またはメンバーを公開しない場合)、アプリが使用するプログラム要素は、そのプログラム要素が使用する言語でサポートされていない場合に CLS に準拠する必要があります。 この場合、CLS 非準拠の要素を使用しようとすると、言語コンパイラによってエラーが生成されます。 -## 言語間の相互運用性 - 言語に依存しないということは、いくつか意味があります。 たとえば、ある言語で記述された型を、別の言語で記述されたアプリからシームレスに利用することができます。これについては、記事「[Language Independence and Language\-Independent Components \(言語非依存性と言語に依存しないコンポーネント\)](../../docs/standard/language-independence-and-language-independent-components.md)」で説明しました。 また、複数の言語で記述されたコードを 1 つの .NET .NET Framework アセンブリにまとめることもできます。ここでは、この点について焦点を当てて説明します。 +## 言語間の相互運用性 + 言語に依存しないということは、いくつか意味があります。 たとえば、ある言語で記述された型を、別の言語で記述されたアプリからシームレスに利用することができます。これについては、記事「[言語への非依存性、および言語非依存コンポーネント](../../docs/standard/language-independence-and-language-independent-components.md)」で説明されています。 また、複数の言語で記述されたコードを 1 つの .NET .NET Framework アセンブリにまとめることもできます。ここでは、この点について焦点を当てて説明します。 - 次の例では、`NumericLib` および `StringLib` という 2 つのクラスを含む Utilities.dll という名前のクラス ライブラリを作成して言語間の相互運用性を示します。 `NumericLib` クラスは C\# で記述され、`StringLib` クラスは Visual Basic で記述されています。 以下は StringUtil.vb のソース コードで、`ToTitleCase` クラスに `StringLib` という単一のメンバーが含まれます。 + 次の例では、`NumericLib` および `StringLib` という 2 つのクラスを含む Utilities.dll という名前のクラス ライブラリを作成して言語間の相互運用性を示します。 `NumericLib` クラスは C# で記述され、`StringLib` クラスは Visual Basic で記述されています。 以下は StringUtil.vb のソース コードで、`ToTitleCase` クラスに `StringLib` という単一のメンバーが含まれます。 [!code-vb[Conceptual.CrossLanguage#1](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.crosslanguage/vb/stringutil.vb#1)] @@ -547,32 +523,31 @@ caps.handback.revision: 33 [!code-csharp[Conceptual.CrossLanguage#2](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.crosslanguage/cs/numberutil.cs#2)] - 単一のアセンブリに 2 つのクラスをパッケージ化するには、モジュールにコンパイルする必要があります。 Visual Basic のソース コード ファイルをモジュールにコンパイルするには、次のコマンドを使用します。 + 単一のアセンブリに 2 つのクラスをパッケージ化するには、モジュールにコンパイルする必要があります。 Visual Basic のソース コード ファイルをモジュールにコンパイルするには、次のコマンドを使用します。 ``` vbc /t:module StringUtil.vb ``` - Visual Basic コンパイラのコマンド ライン構文の詳細については、「[コマンド ラインからのビルド](../Topic/Building%20from%20the%20Command%20Line%20\(Visual%20Basic\).md)」を参照してください。 + Visual Basic コンパイラのコマンド ライン構文の詳細については、「[コマンド ラインからのビルド](~/docs/visual-basic/reference/command-line-compiler/building-from-the-command-line.md)」を参照してください。 - C\# のソース コード ファイルをモジュールにコンパイルするには、次のコマンドを使用します。 + C# のソース コード ファイルをモジュールにコンパイルするには、次のコマンドを使用します。 ``` csc /t:module NumberUtil.cs ``` - C\# コンパイラのコマンド ライン構文の詳細については、「[csc.exe を使用したコマンド ラインからのビルド](../../ocs/csharp/language-reference/compiler-options/command-line-building-with-csc-exe.md)」を参照してください。 + C# コンパイラのコマンド ライン構文の詳細については、「[csc.exe を使用したコマンド ラインからのビルド](~/docs/csharp/language-reference/compiler-options/command-line-building-with-csc-exe.md)」を参照してください。 - 次に、[リンク ツール \(Link.exe\)](../Topic/Linker%20Options.md) を使用してアセンブリに 2 つのモジュールをコンパイルします。 + 次に、[リンク ツール (Link.exe)](http://msdn.microsoft.com/library/c1d51b8a-bd23-416d-81e4-900e02b2c129) を使用して 2 つのモジュールをアセンブリにコンパイルします。 ``` link numberutil.netmodule stringutil.netmodule /out:UtilityLib.dll /dll ``` - 次の例では、その後 `NumericLib.NearZero` メソッドおよび `StringLib.ToTitleCase` メソッドを呼び出します。 Visual Basic コードと C\# コードは、両方のクラスのメソッドにアクセスできることに注意してください。 + 次の例では、その後 `NumericLib.NearZero` メソッドおよび `StringLib.ToTitleCase` メソッドを呼び出します。 Visual Basic コードと C# コードは、両方のクラスのメソッドにアクセスできることに注意してください。 - [!code-csharp[Conceptual.CrossLanguage#3](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.crosslanguage/cs/useutilities1.cs#3)] - [!code-vb[Conceptual.CrossLanguage#3](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.crosslanguage/vb/useutilities1.vb#3)] + [!code-csharp[Conceptual.CrossLanguage#3](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.crosslanguage/cs/useutilities1.cs#3)] [!code-vb[Conceptual.CrossLanguage#3](../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.crosslanguage/vb/useutilities1.vb#3)] Visual Basic コードをコンパイルするには、次のコマンドを使用します。 @@ -580,11 +555,12 @@ link numberutil.netmodule stringutil.netmodule /out:UtilityLib.dll /dll vbc example.vb /r:UtilityLib.dll ``` - C\# でコンパイルするには、コンパイラの名前を **vbc** から **csc** に変更し、ファイル拡張子を .vb から .cs に変更します。 + C# でコンパイルするには、コンパイラの名前を **vbc** から **csc** に変更し、ファイル拡張子を .vb から .cs に変更します。 ``` csc example.cs /r:UtilityLib.dll ``` -## 参照 - \ No newline at end of file +## 関連項目 + + diff --git a/docs/standard/language-independence.md b/docs/standard/language-independence.md index c367a44b901..0603d0c935d 100644 --- a/docs/standard/language-independence.md +++ b/docs/standard/language-independence.md @@ -1,26 +1,26 @@ --- title: "言語への非依存性、および言語非依存コンポーネント" -description: "言語への非依存性、および言語非依存コンポーネント" +description: "C#、C++/CLI、F#、IronPython、VB、Visual COBOL、PowerShell など、.NET でサポートされる多くの言語の中のいずれかで開発する方法を説明します。" keywords: .NET, .NET Core -author: stevehoag -ms.author: shoag +author: dotnet-bot +ms.author: dotnetcontent ms.date: 07/22/2016 ms.topic: article ms.prod: .net ms.technology: dotnet-standard ms.devlang: dotnet ms.assetid: 2dbed1bc-86f5-43cd-9a57-adbb1c5efba4 -ms.translationtype: Human Translation -ms.sourcegitcommit: b967d8e55347f44a012e4ad8e916440ae228c8ec -ms.openlocfilehash: 815d9c24c139ef738b256c7bee791756a2fdb3b3 +ms.translationtype: HT +ms.sourcegitcommit: 3155295489e1188640dae5aa5bf9fdceb7480ed6 +ms.openlocfilehash: 3da0bc3c9abf28aeb588ec9277c4e0b503df4d8b ms.contentlocale: ja-jp -ms.lasthandoff: 03/10/2017 +ms.lasthandoff: 08/21/2017 --- # 言語への非依存性、および言語非依存コンポーネント -.NET プラットフォームは言語に依存しません。 つまり、開発者は、C#、F#、および Visual Basic などの .NET プラットフォームを対象とする多くの言語のいずれかで開発できることを意味します。 .NET プラットフォーム用に開発されたクラス ライブラリの型とメンバーには、最初に記述された言語を知らなくてもアクセスできます。元の言語の規則に従う必要もありません。 コンポーネントを開発しているのであれば、コンポーネントの言語にかかわらず、すべての .NET アプリからそのコンポーネントにアクセスできます。 +.NET は言語に依存しません。 つまり、開発者は、C#、F#、および Visual Basic などの .NET 実装を対象とする多くの言語の中のいずれかで開発できることを意味します。 .NET 実装用に開発されたクラス ライブラリの型とメンバーには、最初に記述された言語を知らなくてもアクセスできます。元の言語の規則に従う必要もありません。 コンポーネントを開発しているのであれば、コンポーネントの言語にかかわらず、すべての .NET アプリからそのコンポーネントにアクセスできます。 > [!NOTE] > この記事の最初の部分では、言語に依存しないコンポーネント、つまり、どの言語で記述されたアプリからでも使用できるコンポーネントの作成について説明します。 また、複数の言語で記述されたソース コードから 1 つのコンポーネントまたはアプリを作成することもできます。この記事の 2 番目のパートにある「[言語間の相互運用性](#cross-language-interoperability)」を参照してください。 @@ -347,7 +347,7 @@ CLS 準拠型 | 説明 .NET Framework のクラス ライブラリまたはその他のクラス ライブラリには、CLS に準拠していない他の型が含まれる場合があります。次に例を示します。 - * ボックス化された値型。 次の C# コード例では、`Value` という名前の型 `int` *のパブリック プロパティを持つクラスを作成します。`int`* はボックス化された値型であるため、コンパイラは CLS 非準拠としてフラグを設定します。 + * ボックス化された値型。 次の C# コード例では、`Value` という名前の型 `int`* のパブリック プロパティを持つクラスを作成します。 `int`* はボックス化された値型であるため、コンパイラは CLS 非準拠としてフラグを設定します。 ```csharp using System; @@ -1110,7 +1110,7 @@ CLS 準拠の配列は、次の規則に従います。 Return numbersOut End Function End Module -``` + ``` ### インターフェイス @@ -1626,7 +1626,7 @@ End Module ' Outer`1+Inner1B`1[System.String,System.Int32] ``` -ジェネリック型の名前は、フォーム *name*'*n* でエンコードされます。ここで、*name* は型の名前、*`* は文字リテラル、*n* は型で宣言されたパラメーターの数、入れ子になったジェネリック型の場合は、新しく導入された型パラメーターの数です。 ジェネリック型の名前のエンコーディングは、主に、リフレクションを使用してライブラリ内の CLS 準拠のジェネリック型にアクセスする開発者が使用します。 +ジェネリック型の名前は、*name*'*n* の形でエンコードされます。ここで、*name* は型の名前、*`* は文字リテラル、*n* は型で宣言されたパラメーターの数 (入れ子になったジェネリック型の場合は新しく導入された型パラメーターの数) です。 ジェネリック型の名前のエンコーディングは、主に、リフレクションを使用してライブラリ内の CLS 準拠のジェネリック型にアクセスする開発者が使用します。 制約がジェネリック型に適用される場合は、制約として使用されるすべての型も CLS に準拠している必要があります。 次の例では、CLS に準拠していない `BaseClass` という名前のクラスと、型パラメーターが `BaseCollection` から派生しなければならない `BaseClass` という名前のジェネリック クラスを定義します。 ただし、`BaseClass` が CLS に準拠していないので、コンパイラによって警告が生成されます。 @@ -1660,7 +1660,6 @@ End Class ' ' Public Class BaseCollection(Of T As BaseClass) ' ~~~~~~~~~ - ``` ジェネリック型がジェネリック基本型から派生している場合、そのジェネリック型は、基本型に対する制約も必ず満たすように制約を再宣言する必要があります。 次の例では、任意の数値型を表すことができる `Number` を定義します。 また、浮動小数点値を表す `FloatingPoint` クラスも定義します。 ただし、ソース コードはコンパイルされません。`Number` (T は値型) の制約は `FloatingPoint` に適用されないからです。 @@ -1938,7 +1937,7 @@ CLS 準拠のクラスと構造体のコンストラクターは、次の規則 * 派生クラスのコンストラクターは、継承されたインスタンス データにアクセスする前に、基底クラスのインスタンス コンストラクターを呼び出す必要があります。 これは、基底クラスのコンストラクターは派生クラスには継承されないからです。 この規則は、直接継承をサポートしない構造体に適用されません。 - 次の例に示すように、コンパイラは、通常、CLS 準拠とは別にこの規則を適用します。 これにより、`Person` クラスから派生した `Doctor` クラスが作成されますが、`Doctor` クラスでは、継承されたインスタンス フィールドを初期化するための `Person` クラス コンストラクターは呼び出されません。 + 次の例に示すように、コンパイラは、通常、CLS 準拠とは別にこの規則を適用します。 これにより、`Doctor` クラスから派生した `Person` クラスが作成されますが、`Doctor` クラスでは、継承されたインスタンス フィールドを初期化するための `Person` クラス コンストラクターは呼び出されません。 ```csharp using System; diff --git a/docs/standard/managed-code.md b/docs/standard/managed-code.md index eeaf4862847..d42fdf4403c 100644 --- a/docs/standard/managed-code.md +++ b/docs/standard/managed-code.md @@ -1,6 +1,6 @@ --- -title: ""マネージ コード" とは" -description: ""マネージ コード" とは" +title: "マネージ コードとは" +description: "ランタイムによって管理されるコードであるマネージ コードが共通言語ランタイム (CLR) によってどのように管理されるかを説明します。" keywords: .NET, .NET Core author: blackdwarf ms.author: mairaw @@ -10,17 +10,15 @@ ms.prod: .net ms.technology: dotnet-standard ms.devlang: dotnet ms.assetid: 20bb7ea8-192e-4a96-8ef3-e10e1950fd3d -ms.translationtype: Human Translation -ms.sourcegitcommit: 4bd90ac423134c67eb35836d417b09053c98f586 -ms.openlocfilehash: 7f761c4fc24b8d22d8d1f8116745ebb3f6583378 +ms.translationtype: HT +ms.sourcegitcommit: 3155295489e1188640dae5aa5bf9fdceb7480ed6 +ms.openlocfilehash: 263662c1c7f22c84e0de14c6480fa9807b46b2f2 ms.contentlocale: ja-jp -ms.lasthandoff: 04/18/2017 +ms.lasthandoff: 08/21/2017 --- - - -# "マネージ コード" とは +# "マネージ コード" とは .NET Framework を使用していると、よく "マネージ コード" という用語を目にすることがあります。 このドキュメントでは、この用語の意味とそれに関する追加の情報について説明します。 @@ -28,11 +26,9 @@ ms.lasthandoff: 04/18/2017 これを、"アンマネージ コード" とも呼ばれる C/C++ プログラムを実行する方法と比較します。 アンマネージ環境では、プログラマがほとんどすべてのことを担当します。 実際のプログラムは、基本的に、オペレーティング システム (OS) がメモリに読み込み、起動するバイナリです。 メモリ管理からセキュリティの考慮事項まで、他のすべてのことをプログラマが担当します。 -マネージ コードは C#、Visual Basic、F# など、.NET プラットフォーム上で実行可能な高水準言語のいずれかで記述されます。 それらの言語で書かれたコードをそれぞれのコンパイラでコンパイルした場合、マシン コードは得られません。 **中間言語**コードが得られ、それをランタイムがコンパイルして実行します。 C++ は、Windows で実行するネイティブなアンマネージ バイナリも生成できるため、この規則の 1 つの例外です。 - - +マネージ コードは C#、Visual Basic、F# など、.NET 上で実行可能な高水準言語のいずれかで記述されます。 それらの言語で書かれたコードをそれぞれのコンパイラでコンパイルした場合、マシン コードは得られません。 **中間言語**コードが得られ、それをランタイムがコンパイルして実行します。 C++ は、Windows で実行するネイティブなアンマネージ バイナリも生成できるため、この規則の 1 つの例外です。 -## 中間言語と実行 +## 中間言語と実行 "中間言語" (または略して IL) とは それは、高水準 .NET 言語で記述されたコードのコンパイルの成果物です。 これらの言語のいずれかで記述されたコードをコンパイルすると、IL で構成されたバイナリが得られます。 IL はランタイムで実行される特定の言語に依存しないことに注意してください。それについて個別の仕様もあるため、参照することができます。 @@ -40,17 +36,13 @@ ms.lasthandoff: 04/18/2017 中間言語は、共通中間言語 (CIL) または Microsoft Intermediate Language (MSIL) と呼ばれることもあります。 - - -## アンマネージ コードの相互運用性 +## アンマネージ コードの相互運用性 もちろん、CLR は、マネージ環境とアンマネージ環境間の境界を越えることができ、[基本クラス ライブラリ](framework-libraries.md)にも、それを行う多くのコードがあります。 これは**相互運用性 (interoperability)** または略して **相互運用 (interop)** と呼ばれます。 これらのプロビジョニングにより、たとえばアンマネージ ライブラリをラップし、それを呼び出すことができます。 ただし、これを実行すると、コードがランタイムの境界を越えたときに、実行の実際の管理が再びアンマネージ コードの担当になるため、同じ制限が課せられることになります。 これと同様に、C# は、実行が CLR によって管理されないコードの一部を指定する**アンセーフ コンテキスト**として知られる機能を使用して、コード内の直接のポインターなど、アンマネージ コンストラクトを使用できる 1 つの言語です。 - - -## その他のリソース +## その他のリソース * [.NET framework の概念の概要](https://msdn.microsoft.com/library/zw4w595w.aspx) * [アンセーフ コードとポインター](https://msdn.microsoft.com/library/t2yzs44b.aspx) diff --git a/docs/standard/managed-execution-process.md b/docs/standard/managed-execution-process.md index 68cd72ebdfc..0f7cc7449e4 100644 --- a/docs/standard/managed-execution-process.md +++ b/docs/standard/managed-execution-process.md @@ -1,29 +1,33 @@ --- -title: "マネージ実行プロセス | Microsoft Docs" -ms.custom: "" -ms.date: "03/30/2017" -ms.prod: ".net" -ms.reviewer: "" -ms.suite: "" -ms.technology: - - "dotnet-standard" -ms.tgt_pltfrm: "" -ms.topic: "article" -helpviewer_keywords: - - "ソース コード言語" - - "コード, マネージ実行プロセス" - - "ランタイム, マネージ実行プロセス" - - "ソース コードのコンパイル, マネージ実行プロセス" - - "マネージ実行プロセス" - - "共通言語ランタイム, マネージ実行プロセス" +title: "マネージ実行プロセス" +ms.custom: +ms.date: 03/30/2017 +ms.prod: .net +ms.reviewer: +ms.suite: +ms.technology: dotnet-standard +ms.tgt_pltfrm: +ms.topic: article +helpviewer_keywords: +- source code language +- code, managed execution process +- runtime, managed execution process +- compiling source code, managed execution process +- managed execution process +- common language runtime, managed execution process ms.assetid: 476b03dc-2b12-49a7-b067-41caeaa2f533 caps.latest.revision: 20 -author: "rpetrusha" -ms.author: "ronpet" -manager: "wpickett" -caps.handback.revision: 20 +author: rpetrusha +ms.author: ronpet +manager: wpickett +ms.translationtype: HT +ms.sourcegitcommit: 306c608dc7f97594ef6f72ae0f5aaba596c936e1 +ms.openlocfilehash: cf4234f36745fdc13635ab2c6394f49aefabf7a8 +ms.contentlocale: ja-jp +ms.lasthandoff: 08/21/2017 + --- -# マネージ実行プロセス +# マネージ実行プロセス マネージ実行プロセスで実行される主な手順を次に示します。詳細については、後で説明します。 1. [コンパイラを選択します](#choosing_a_compiler)。 @@ -32,47 +36,47 @@ caps.handback.revision: 20 2. [コードを MSIL にコンパイルします](#compiling_to_msil)。 - コンパイルを実行するとソース コードが Microsoft Intermediate Language \(MSIL\) に変換され、必要なメタデータが生成されます。 + コンパイルを実行するとソース コードが Microsoft Intermediate Language (MSIL) に変換され、必要なメタデータが生成されます。 3. [MSIL からネイティブ コードにコンパイルします](#compiling_msil_to_native_code)。 - 実行時に、ジャスト イン タイム \(JIT\) コンパイラによって MSIL がネイティブ コードに変換されます。 このコンパイルの実行時に、コードは検証プロセスで確認される必要があります。この検証プロセスでは、MSIL とメタデータが調べられ、コードがタイプ セーフかどうかが確認されます。 + 実行時に、ジャスト イン タイム (JIT) コンパイラによって MSIL がネイティブ コードに変換されます。 このコンパイルの実行時に、コードは検証プロセスで確認される必要があります。この検証プロセスでは、MSIL とメタデータが調べられ、コードがタイプ セーフかどうかが確認されます。 4. [コードを実行します](#running_code)。 共通言語ランタイムは、実行を可能にするインフラストラクチャと実行時に使用できるサービスを提供します。 -## コンパイラの選択 - 共通言語ランタイム \(CLR: Common Language Runtime\) によって提供される機能を活用するには、Visual Basic、C\#、Visual C\+\+、F\# などのランタイムに対応した言語コンパイラか、Eiffel、Perl、COBOL などのサードパーティのコンパイラを使用する必要があります。 +## コンパイラを選択します + 共通言語ランタイム (CLR: Common Language Runtime) によって提供される機能を活用するには、Visual Basic、C#、Visual C++、F# などのランタイムに対応した言語コンパイラか、Eiffel、Perl、COBOL などのサードパーティのコンパイラを使用する必要があります。 - 共通言語ランタイムは多言語実行環境であるため、さまざまなデータ型と言語機能をサポートしています。 使用する言語コンパイラによって、利用できる共通言語ランタイムの機能が決まり、その機能を使用してコードをデザインすることになります。 記述するコードの構文を決定するのは、共通言語ランタイムではなく、使用するコンパイラです。 作成したコンポーネントを他の言語で記述されたコンポーネントでも完全に使用できるようにするためには、そのコンポーネントからエクスポートされた型が、[言語への非依存性、および言語非依存コンポーネント](../../docs/standard/language-independence-and-language-independent-components.md) \(CLS\) に規定されている言語機能だけを公開するようにする必要があります。 属性を使用することにより、コードを確実に CLS に準拠させることができます。 詳細については、「[言語への非依存性、および言語非依存コンポーネント](../../docs/standard/language-independence-and-language-independent-components.md)」を参照してください。 + 共通言語ランタイムは多言語実行環境であるため、さまざまなデータ型と言語機能をサポートしています。 使用する言語コンパイラによって、利用できる共通言語ランタイムの機能が決まり、その機能を使用してコードをデザインすることになります。 記述するコードの構文を決定するのは、共通言語ランタイムではなく、使用するコンパイラです。 作成したコンポーネントを他の言語で記述されたコンポーネントでも完全に使用できるようにするためには、そのコンポーネントからエクスポートされた型が、 [Language Independence and Language-Independent Components](../../docs/standard/language-independence-and-language-independent-components.md) (CLS) に規定されている言語機能だけを公開するようにする必要があります。 属性を使用することにより、コードを確実に CLS に準拠させることができます。 詳細については、「[Language Independence and Language-Independent Components](../../docs/standard/language-independence-and-language-independent-components.md)」を参照してください。 [ページのトップへ](#introduction) -## MSIL へのコンパイル - マネージ コードへのコンパイル時に、コンパイラはソース コードを MSIL \(Microsoft Intermediate Language\) に変換します。MSIL は CPU に依存しない一連の命令で、効率的にネイティブ コードに変換できます。 MSIL には、オブジェクトに対する読み込み、格納、初期化、および呼び出し用の命令の他に、算術演算と論理演算、制御フロー、DMA \(Direct Memory Access\)、例外処理、およびその他の操作のための命令も含まれています。 コードを実行する前に、MSIL を CPU 固有のコードに変換する必要があります。通常、この変換は [Just\-In\-Time \(JIT\) コンパイラ](#compiling_msil_to_native_code)によって行われます。 共通言語ランタイムはサポートするコンピューター アーキテクチャごとに JIT コンパイラを提供しているため、同じ MSIL セットを JIT コンパイルして、サポートされているすべてのアーキテクチャで実行できます。 +## MSIL へのコンパイル + マネージ コードへのコンパイル時に、コンパイラはソース コードを MSIL (Microsoft Intermediate Language) に変換します。MSIL は CPU に依存しない一連の命令で、効率的にネイティブ コードに変換できます。 MSIL には、オブジェクトに対する読み込み、格納、初期化、および呼び出し用の命令の他に、算術演算と論理演算、制御フロー、DMA (Direct Memory Access)、例外処理、およびその他の操作のための命令も含まれています。 コードを実行する前に、MSIL を CPU 固有のコードに変換する必要があります。通常、この変換は [Just-In-Time (JIT) コンパイラ](#compiling_msil_to_native_code)によって行われます。 共通言語ランタイムはサポートするコンピューター アーキテクチャごとに JIT コンパイラを提供しているため、同じ MSIL セットを JIT コンパイルして、サポートされているすべてのアーキテクチャで実行できます。 - コンパイラは、MSIL を生成するときにメタデータも生成します。 メタデータには、コード内の型について、それぞれの型の定義、型のメンバーのシグネチャ、コードが参照するメンバー、共通言語ランタイムが実行時に使用するその他のデータなどが記述されています。 MSIL とメタデータは、実行可能ファイルのファイル形式として使用されてきた従来の Microsoft PE と COFF \(Common Object File Format\) に基づき、それらを拡張した移植可能な実行可能 \(PE: Portable Executable\) ファイルに格納されます。 MSIL、ネイティブ コード、およびメタデータを保存できるこのファイル形式を使用すると、オペレーティング システムが共通言語ランタイムのイメージを認識できるようになります。 MSIL と共にメタデータがこのファイルに格納されるため、コードは自己記述型になります。つまり、タイプ ライブラリまたはインターフェイス定義言語 \(IDL: Interface Definition Language\) は必要ありません。 共通言語ランタイムは、実行時にこのファイルから必要に応じてメタデータを検出および抽出します。 + コンパイラは、MSIL を生成するときにメタデータも生成します。 メタデータには、コード内の型について、それぞれの型の定義、型のメンバーのシグネチャ、コードが参照するメンバー、共通言語ランタイムが実行時に使用するその他のデータなどが記述されています。 MSIL とメタデータは、実行可能ファイルのファイル形式として使用されてきた従来の Microsoft PE と COFF (Common Object File Format) に基づき、それらを拡張した移植可能な実行可能 (PE: Portable Executable) ファイルに格納されます。 MSIL、ネイティブ コード、およびメタデータを保存できるこのファイル形式を使用すると、オペレーティング システムが共通言語ランタイムのイメージを認識できるようになります。 MSIL と共にメタデータがこのファイルに格納されるため、コードは自己記述型になります。つまり、タイプ ライブラリまたはインターフェイス定義言語 (IDL: Interface Definition Language) は必要ありません。 共通言語ランタイムは、実行時にこのファイルから必要に応じてメタデータを検出および抽出します。 [ページのトップへ](#introduction) -## MSIL からネイティブ コードへのコンパイル - Microsoft Intermediate Language \(MSIL\) は、実行する前に、共通言語ランタイムに対して、対象コンピューターのアーキテクチャ用のネイティブ コードにコンパイルしておく必要があります。[!INCLUDE[dnprdnshort](../../includes/dnprdnshort-md.md)] には、この変換を実行する 2 つの方法が用意されています。 +## MSIL からネイティブ コードにコンパイルします + Microsoft Intermediate Language (MSIL) は、実行する前に、共通言語ランタイムに対して、対象コンピューターのアーキテクチャ用のネイティブ コードにコンパイルしておく必要があります。 [!INCLUDE[dnprdnshort](../../includes/dnprdnshort-md.md)] には、この変換を実行する 2 つの方法が用意されています。 -- .NET Framework の Just\-In\-Time \(JIT\) コンパイラ +- .NET Framework の Just-In-Time (JIT) コンパイラ -- .NET Framework [Ngen.exe \(ネイティブ イメージ ジェネレーター\)](../../docs/framework/tools/ngen-exe-native-image-generator.md)。 +- .NET Framework の [Ngen.exe (ネイティブ イメージ ジェネレーター)](../../docs/framework/tools/ngen-exe-native-image-generator.md)。 -### JIT コンパイラによるコンパイル +### JIT コンパイラによるコンパイル JIT コンパイルは、アプリケーション実行時に、アセンブリの内容が読み込まれて実行される際に、オン デマンドで MSIL をネイティブ コードに変換します。 共通言語ランタイムには、サポートされる CPU アーキテクチャごとに JIT コンパイラが用意されているため、開発者は MSIL アセンブリのセットを作成し、それを JIT でコンパイルして、異なるマシン アーキテクチャを持つさまざまなコンピューター上で実行できます。 ただし、マネージ コードがプラットフォーム固有のネイティブ API またはプラットフォーム固有のクラス ライブラリを呼び出す場合、そのコードはそのオペレーティング システムでしか実行されません。 JIT コンパイルは、実行時に呼び出されることがないコードがある可能性を考慮しています。 つまり、PE ファイル内にあるすべての MSIL をネイディブ コードに変換するために時間とメモリを費やす代わりに、実行時に必要とされる MSIL を変換し、結果として生成されるネイティブ コードをメモリに保存することで、そのプロセスのコンテキスト内の後続の呼び出しがこれを利用できるようにします。 型が読み込まれて初期化されるとき、ローダーはスタブを作成し、その型の各メソッドにそれを結び付けます。 メソッドが初めて呼び出されるとき、スタブは JIT コンパイラに制御を渡します。JIT コンパイラはそのメソッド用の MSIL をネイティブ コードに変換して、生成されたネイティブ コードを直接指すようスタブを変更します。 このため、JIT でコンパイルされたメソッドに対する後続の呼び出しでは、ネイティブ コードが直接実行されます。 -### NGen.exe を使用したインストール時のコード生成 - JIT コンパイラは、アセンブリの MSIL を、そのアセンブリで定義されている個々のメソッドが呼び出されるときにネイティブ コードに変換するため、実行時のパフォーマンスが低下します。 ほとんどの場合、このパフォーマンスの低下は許容範囲内です。 より重要な点として、JIT コンパイラが生成したコードは、コンパイルを起動したプロセスにバインドされます。 複数のプロセスの間でこれを共有することはできません。 生成されたコードを、1 つのアプリケーションの複数の呼び出しの間で、または 1 つのアセンブリ セットを共有する複数のプロセスの間で共有できるようにするために、共通言語ランタイムは事前コンパイル モードをサポートします。 この事前コンパイル モードは [Ngen.exe \(ネイティブ イメージ ジェネレーター\)](../../docs/framework/tools/ngen-exe-native-image-generator.md) を使用して、JIT コンパイラと同様に MSIL アセンブリをネイティブ コードに変換します。 ただし、Ngen.exe の動作は、以下の 3 つの点で JIT コンパイラの動作と異なります。 +### NGen.exe を使用したインストール時のコード生成 + JIT コンパイラは、アセンブリの MSIL を、そのアセンブリで定義されている個々のメソッドが呼び出されるときにネイティブ コードに変換するため、実行時のパフォーマンスが低下します。 ほとんどの場合、このパフォーマンスの低下は許容範囲内です。 より重要な点として、JIT コンパイラが生成したコードは、コンパイルを起動したプロセスにバインドされます。 複数のプロセスの間でこれを共有することはできません。 生成されたコードを、1 つのアプリケーションの複数の呼び出しの間で、または 1 つのアセンブリ セットを共有する複数のプロセスの間で共有できるようにするために、共通言語ランタイムは事前コンパイル モードをサポートします。 この Ahead Of Time コンパイル モードでは、[Ngen.exe (ネイティブ イメージ ジェネレーター)](../../docs/framework/tools/ngen-exe-native-image-generator.md) を使用して、JIT コンパイラと同様に MSIL アセンブリをネイティブ コードに変換します。 ただし、Ngen.exe の動作は、以下の 3 つの点で JIT コンパイラの動作と異なります。 - MSIL からネイティブ コードへの変換を、アプリケーション実行中ではなく、実行前に行います。 @@ -80,7 +84,7 @@ caps.handback.revision: 20 - 生成したコードを、ディスク上のファイルとしてネイティブ イメージ キャッシュに保持します。 -### コードの検証 +### コードの検証 コード検証の省略を許可するセキュリティ ポリシーを管理者が設定していない限り、MSIL からネイティブ コードへのコンパイル時に、MSIL コードは検証プロセスを通過する必要があります。 この検証プロセスでは、コードがタイプ セーフかどうかを確認するために、MSIL とメタデータが調べられます。タイプ セーフなコードとは、アクセス権限を与えられているメモリ位置だけにアクセスするコードを意味します。 タイプ セーフは、オブジェクトを相互に分離するため、不注意や悪意による破損からオブジェクトを保護するために役立ちます。 また、コードに対するセキュリティ制限が強制適用されることも保証されます。 共通言語ランタイムは、検証可能なタイプ セーフ コードが次の条件を満たすことを前提としています。 @@ -96,28 +100,29 @@ caps.handback.revision: 20 [ページのトップへ](#introduction) -## コードの実行 +## コードを実行します 共通言語ランタイムは、マネージ実行を可能にするインフラストラクチャと実行時に使用できるサービスを提供します。 メソッドは、実行する前にプロセッサ固有のコードにコンパイルされている必要があります。 対応する MSIL が生成されているメソッドは、初めて呼び出されたときに JIT コンパイルされてから実行されます。 次にこのメソッドが実行されるときには、JIT コンパイル済みの既存のネイティブ コードが実行されます。 JIT コンパイルからコード実行までのプロセスは、実行が完了するまで繰り返されます。 実行時に、マネージ コードは、ガベージ コレクション、セキュリティ、アンマネージ コードとの相互運用性、言語間デバッグ サポート、強化された配置とバージョン管理のサポートなどのさまざまなサービスを利用できます。 - Microsoft [!INCLUDE[winxp](../../includes/winxp-md.md)] および [!INCLUDE[windowsver](../../includes/windowsver-md.md)] では、オペレーティング システム ローダーが COFF ヘッダー内のビットを調べることにより、マネージ モジュールをチェックします。 設定されたビットはマネージ モジュールを意味します。 ローダーがマネージ モジュールを検出すると、mscoree.dll が読み込まれます。マネージ モジュール イメージが読み込まれるときとアンロードされるときには、`_CorValidateImage` および `_CorImageUnloading` がローダーに通知します。`_CorValidateImage` は、次のアクションを実行します。 + Microsoft [!INCLUDE[winxp](../../includes/winxp-md.md)] および [!INCLUDE[windowsver](../../includes/windowsver-md.md)]では、オペレーティング システム ローダーが COFF ヘッダー内のビットを調べることにより、マネージ モジュールをチェックします。 設定されたビットはマネージ モジュールを意味します。 ローダーがマネージ モジュールを検出すると、mscoree.dll が読み込まれます。マネージ モジュール イメージが読み込まれるときとアンロードされるときには、 `_CorValidateImage` および `_CorImageUnloading` がローダーに通知します。 `_CorValidateImage` は、次のアクションを実行します。 1. コードが有効なマネージ コードであることを確認します。 2. イメージのエントリ ポイントをランタイムのエントリ ポイントに変更します。 - 64 ビット Windows では、`_CorValidateImage` は、メモリ内のイメージを PE32 から PE32\+ 形式に変換することによって変更します。 + 64 ビット Windows では、 `_CorValidateImage` は、メモリ内のイメージを PE32 から PE32+ 形式に変換することによって変更します。 [ページのトップへ](#introduction) -## 参照 +## 関連項目 [概要](../../docs/framework/get-started/overview.md) [言語への非依存性、および言語非依存コンポーネント](../../docs/standard/language-independence-and-language-independent-components.md) [メタデータと自己言及的なコンポーネント](../../docs/standard/metadata-and-self-describing-components.md) - [Ilasm.exe \(IL アセンブラー\)](../../docs/framework/tools/ilasm-exe-il-assembler.md) + [Ilasm.exe (IL アセンブラー)](../../docs/framework/tools/ilasm-exe-il-assembler.md) [セキュリティ](../../docs/standard/security/index.md) [アンマネージ コードとの相互運用](../../docs/framework/interop/index.md) - [配置](../../docs/framework/deployment/net-framework-and-applications.md) + [配置](../../docs/framework/deployment/net-framework-applications.md) [共通言語ランタイムのアセンブリ](../../docs/framework/app-domains/assemblies-in-the-common-language-runtime.md) - [アプリケーション ドメイン](../../docs/framework/app-domains/application-domains.md) \ No newline at end of file + [アプリケーション ドメイン](../../docs/framework/app-domains/application-domains.md) + diff --git a/docs/standard/metadata-and-self-describing-components.md b/docs/standard/metadata-and-self-describing-components.md index 38075f38b5c..f46b10ea2d3 100644 --- a/docs/standard/metadata-and-self-describing-components.md +++ b/docs/standard/metadata-and-self-describing-components.md @@ -1,40 +1,44 @@ --- -title: "メタデータと自己言及的なコンポーネント | Microsoft Docs" -ms.custom: "" -ms.date: "03/30/2017" -ms.prod: ".net" -ms.reviewer: "" -ms.suite: "" -ms.technology: - - "dotnet-standard" -ms.tgt_pltfrm: "" -ms.topic: "article" -helpviewer_keywords: - - "共通言語ランタイム, メタデータ" - - "コンポーネント [.NET Framework], メタデータ" - - "言語, 相互運用性" - - "メタデータ, メタデータの概要" - - "PE ファイル, メタデータ" - - "移植可能な実行可能 (PE) ファイル, メタデータ" - - "ランタイム, メタデータ" - - "自己言及的なファイル" +title: "メタデータと自己言及的なコンポーネント" +ms.custom: +ms.date: 03/30/2017 +ms.prod: .net +ms.reviewer: +ms.suite: +ms.technology: dotnet-standard +ms.tgt_pltfrm: +ms.topic: article +helpviewer_keywords: +- runtime, metadata +- languages, interoperability +- portable executable files, metadata +- self-describing files +- metadata, about metadata +- common language runtime, metadata +- PE files, metadata +- components [.NET Framework], metadata ms.assetid: 3dd13c5d-a508-455b-8dce-0a852882a5a7 caps.latest.revision: 10 -author: "rpetrusha" -ms.author: "ronpet" -manager: "wpickett" -caps.handback.revision: 10 +author: rpetrusha +ms.author: ronpet +manager: wpickett +ms.translationtype: HT +ms.sourcegitcommit: 306c608dc7f97594ef6f72ae0f5aaba596c936e1 +ms.openlocfilehash: f5469f649d594553e1567d6d611cfafcd28e2c5b +ms.contentlocale: ja-jp +ms.lasthandoff: 08/21/2017 + --- -# メタデータと自己言及的なコンポーネント -以前は、ある 1 つの言語で記述されたソフトウェア コンポーネント \(.exe または .dll\) で、別の言語で記述されたコンポーネントを使用するのは簡単ではありませんでした。 COM により、この問題が解決するための手段が提供されるようになりました。 .NET Framework では、コンパイラからすべてのモジュールやアセンブリに追加の宣言情報を挿入できるようになり、コンポーネントの相互運用性が大幅に強化されています。 メタデータと呼ばれるこの情報により、コンポーネント間のシームレスな相互作用がサポートされます。 +# メタデータと自己言及的なコンポーネント +以前は、ある 1 つの言語で記述されたソフトウェア コンポーネント (.exe または .dll) で、別の言語で記述されたコンポーネントを使用するのは簡単ではありませんでした。 COM により、この問題が解決するための手段が提供されるようになりました。 .NET Framework では、コンパイラからすべてのモジュールやアセンブリに追加の宣言情報を挿入できるようになり、コンポーネントの相互運用性が大幅に強化されています。 メタデータと呼ばれるこの情報により、コンポーネント間のシームレスな相互作用がサポートされます。 - メタデータはプログラムを説明するバイナリ情報であり、共通言語ランタイムのポータブル実行可能 \(PE\) ファイルまたはメモリのいずれかに格納されます。 コードを PE ファイルとしてコンパイルすると、PE ファイルの特定の部分にメタデータが挿入され、コードは Microsoft Intermediate Language \(MSIL\) に変換されて PE ファイル内の別の部分に挿入されます。 モジュール内またはアセンブリ内で定義され、参照されているすべての型およびメンバーは、メタデータ内部に記述されます。 コードを実行すると、ランタイムはメタデータをメモリに読み込み、コードのクラス、メンバー、継承などの情報を検索するためにメタデータを参照します。 + メタデータはプログラムを説明するバイナリ情報であり、共通言語ランタイムのポータブル実行可能 (PE) ファイルまたはメモリのいずれかに格納されます。 コードを PE ファイルとしてコンパイルすると、PE ファイルの特定の部分にメタデータが挿入され、コードは Microsoft Intermediate Language (MSIL) に変換されて PE ファイル内の別の部分に挿入されます。 モジュール内またはアセンブリ内で定義され、参照されているすべての型およびメンバーは、メタデータ内部に記述されます。 コードを実行すると、ランタイムはメタデータをメモリに読み込み、コードのクラス、メンバー、継承などの情報を検索するためにメタデータを参照します。 - メタデータには、コードに定義されているすべての型およびメンバーが言語に中立的な形で記述されています。 メタデータには、次の情報が格納されいてます。 + メタデータには、コードに定義されているすべての型およびメンバーが言語に中立的な形で記述されています。 メタデータには、次の情報が格納されいてます。 - アセンブリに関する記述 - - ID \(名前、バージョン、カルチャ、公開キー\) + - ID (名前、バージョン、カルチャ、公開キー) - エクスポートされる型 @@ -46,57 +50,57 @@ caps.handback.revision: 10 - 名前、参照可能範囲、基底クラス、および実装されているインターフェイス - - メンバー \(メソッド、フィールド、プロパティ、イベント、入れ子になった型\) + - メンバー (メソッド、フィールド、プロパティ、イベント、入れ子になった型) - 属性。 - 型やメンバーを修飾する追加の記述要素 -## メタデータの利点 - メタデータは、プログラミング モデルを簡素化するうえで重要な役割を果たします。これにより、インターフェイス定義言語 \(IDL: Interface Definition Language\) ファイル、ヘッダー ファイル、およびその他のコンポーネント参照の外部メソッドは一切不要になります。 メタデータを使用すると、.NET Framework の各言語は、開発者やユーザーからは見えない、言語に依存しない形式で自動的に記述されるようになります。 また、属性を使用することにより、メタデータを拡張することもできます。 メタデータの主な利点は、次のとおりです。 +## メタデータの利点 + メタデータは、プログラミング モデルを簡素化するうえで重要な役割を果たします。これにより、インターフェイス定義言語 (IDL: Interface Definition Language) ファイル、ヘッダー ファイル、およびその他のコンポーネント参照の外部メソッドは一切不要になります。 メタデータを使用すると、.NET Framework の各言語は、開発者やユーザーからは見えない、言語に依存しない形式で自動的に記述されるようになります。 また、属性を使用することにより、メタデータを拡張することもできます。 メタデータの主な利点は、次のとおりです。 - 自己言及的なファイル - 共通言語ランタイム モジュールおよびアセンブリは、自己言及的なファイルです。 モジュールのメタデータには、他のモジュールと相互作用するのに必要なすべての情報が含まれています。 メタデータは自動的に COM の IDL の機能を提供するため、ユーザーは 1 つのファイルを定義と実装の両方に使用できます。 また、ランタイム モジュールやアセンブリをオペレーティング システムに登録する必要もありません。 これにより、ランタイムが使用する記述は常にコンパイル済みファイル内の実際のコードに反映されるため、アプリケーションの信頼性が高くなります。 + 共通言語ランタイム モジュールおよびアセンブリは、自己言及的なファイルです。 モジュールのメタデータには、他のモジュールと相互作用するのに必要なすべての情報が含まれています。 メタデータは自動的に COM の IDL の機能を提供するため、ユーザーは 1 つのファイルを定義と実装の両方に使用できます。 また、ランタイム モジュールやアセンブリをオペレーティング システムに登録する必要もありません。 これにより、ランタイムが使用する記述は常にコンパイル済みファイル内の実際のコードに反映されるため、アプリケーションの信頼性が高くなります。 - 言語の相互運用性と簡単なコンポーネント ベースのデザイン - メタデータは、他の言語で記述されている PE ファイルからクラスを継承するのに必要な、コンパイル済みコードについてのすべての情報を提供します。 明示的なマーシャリングや相互運用可能なカスタム コードの使用を考慮せずに、マネージ言語 \(共通言語ランタイムに変換される言語\) で記述された任意のクラスのインスタンスを作成できます。 + メタデータは、他の言語で記述されている PE ファイルからクラスを継承するのに必要な、コンパイル済みコードについてのすべての情報を提供します。 明示的なマーシャリングや相互運用可能なカスタム コードの使用を考慮せずに、マネージ言語 (共通言語ランタイムに変換される言語) で記述された任意のクラスのインスタンスを作成できます。 - 属性。 - .NET Framework を使用すると、コンパイル済みファイル内で "属性" と呼ばれる特定の種類のメタデータを宣言できます。 属性は、.NET Framework 全体で使用され、実行時のプログラムの動作を詳細に制御します。 また、ユーザー定義のカスタム属性によって、独自に作成したメタデータを .NET Framework のファイルに挿入できます。 詳細については、「[属性](../../docs/standard/attributes/index.md)」を参照してください。 + .NET Framework を使用すると、コンパイル済みファイル内で "属性" と呼ばれる特定の種類のメタデータを宣言できます。 属性は、.NET Framework 全体で使用され、実行時のプログラムの動作を詳細に制御します。 また、ユーザー定義のカスタム属性によって、独自に作成したメタデータを .NET Framework のファイルに挿入できます。 詳細については、「[属性](../../docs/standard/attributes/index.md)」を参照してください。 -## メタデータと PE ファイルの構造 - メタデータと Microsoft Intermediate Language \(MSIL\) は、それぞれ、.NET Framework のポータブル実行可能 \(PE\) ファイルの別のセクションに格納されます。 ファイルのメタデータ部分には、一連のテーブルとヒープ データの構造が格納されています。 MSIL 部分には、PE ファイルのメタデータ部分を参照する MSIL とメタデータ トークンが格納されています。 コードの MSIL を表示する [MSIL 逆アセンブラー \(Ildasm.exe\)](../../docs/framework/tools/ildasm-exe-il-disassembler.md) のようなツールを使用すると、メタデータ トークンが表示される場合があります。 +## メタデータと PE ファイルの構造 + メタデータと Microsoft Intermediate Language (MSIL) は、それぞれ、.NET Framework のポータブル実行可能 (PE) ファイルの別のセクションに格納されます。 ファイルのメタデータ部分には、一連のテーブルとヒープ データの構造が格納されています。 MSIL 部分には、PE ファイルのメタデータ部分を参照する MSIL とメタデータ トークンが格納されています。 コードの MSIL を表示する [MSIL 逆アセンブラー (Ildasm.exe)](../../docs/framework/tools/ildasm-exe-il-disassembler.md) のようなツールを使用すると、メタデータ トークンが表示される場合があります。 -### メタデータのテーブルおよびヒープ - 各メタデータ テーブルには、プログラムの要素に関する情報が保持されています。 たとえば、1 つのメタデータ テーブルにはコード内のクラスが記述されており、別のテーブルにはフィールドが記述されています。 コードに 10 個のクラスが存在する場合、クラス テーブルには、各クラスごとに 1 行、つまり 10 行が存在します。 メタデータ テーブルは、他のテーブルおよびヒープを参照します。 たとえば、クラスのメタデータ テーブルは、メソッドのテーブルを参照します。 +### メタデータのテーブルおよびヒープ + 各メタデータ テーブルには、プログラムの要素に関する情報が保持されています。 たとえば、1 つのメタデータ テーブルにはコード内のクラスが記述されており、別のテーブルにはフィールドが記述されています。 コードに 10 個のクラスが存在する場合、クラス テーブルには、各クラスごとに 1 行、つまり 10 行が存在します。 メタデータ テーブルは、他のテーブルおよびヒープを参照します。 たとえば、クラスのメタデータ テーブルは、メソッドのテーブルを参照します。 - また、メタデータは、4 つのヒープ構造 \(文字列、BLOB、ユーザー文字列、および GUID\) に情報を格納します。 型やメンバーに名前を付けるために使用する文字列はすべて、文字列ヒープに格納されています。 たとえば、特定のメソッドの名前はメソッド テーブルに直接は格納されず、メソッド テーブルから文字列ヒープ内に格納されているメソッドの名前を参照します。 + また、メタデータは、4 つのヒープ構造 (文字列、BLOB、ユーザー文字列、および GUID) に情報を格納します。 型やメンバーに名前を付けるために使用する文字列はすべて、文字列ヒープに格納されています。 たとえば、特定のメソッドの名前はメソッド テーブルに直接は格納されず、メソッド テーブルから文字列ヒープ内に格納されているメソッドの名前を参照します。 -### メタデータ トークン - 各メタデータ テーブルのそれぞれの行は、メタデータ トークンによって、PE ファイルの MSIL 部分内で一意に識別されます。 メタデータ トークンは、概念上、ポインターに類似しており、特定のメタデータ テーブルを参照します。 +### メタデータ トークン + 各メタデータ テーブルのそれぞれの行は、メタデータ トークンによって、PE ファイルの MSIL 部分内で一意に識別されます。 メタデータ トークンは、概念上、ポインターに類似しており、特定のメタデータ テーブルを参照します。 - メタデータ トークンは、4 バイトで構成される数値です。 最上位バイトは、特定のトークンの参照先であるメタデータ テーブル \(メソッド、型など\) を表します。 残り 3 バイトは、記述されているプログラミング要素と対応する、メタデータ テーブル内の行を指定します。 たとえば、C\# 言語でメソッドを定義し、そのメソッドを PE ファイルとしてコンパイルすると、PE ファイルの MSIL 部分に次のようなメタデータ トークンが格納されます。 + メタデータ トークンは、4 バイトで構成される数値です。 最上位バイトは、特定のトークンの参照先であるメタデータ テーブル (メソッド、型など) を表します。 残り 3 バイトは、記述されているプログラミング要素と対応する、メタデータ テーブル内の行を指定します。 たとえば、C# 言語でメソッドを定義し、そのメソッドを PE ファイルとしてコンパイルすると、PE ファイルの MSIL 部分に次のようなメタデータ トークンが格納されます。 ``` 0x06000004 ``` - 最上位バイト \(`0x06`\) は、**MethodDef** トークンであることを示します。 下位 3 バイト \(`000004`\) は、**MethodDef** テーブル内の、このメソッドの定義を記述する情報に対応する 4 行目を参照するように、共通言語ランタイムに指示します。 + 最上位バイト (`0x06`) は、**MethodDef** トークンであることを示します。 下位 3 バイト (`000004`) は、**MethodDef** テーブル内の、このメソッドの定義を記述する情報に対応する 4 行目を参照するように、共通言語ランタイムに指示します。 -### PE ファイル内のメタデータ - プログラムを共通言語ランタイムとしてコンパイルすると、プログラムは 3 つの部分で構成される PE ファイルに変換されます。 各部分の内容を説明する表を次に示します。 +### PE ファイル内のメタデータ + プログラムを共通言語ランタイムとしてコンパイルすると、プログラムは 3 つの部分で構成される PE ファイルに変換されます。 各部分の内容を説明する表を次に示します。 |PE セクション|PE セクションの内容| -|--------------|-----------------| +|----------------|----------------------------| |PE ヘッダー|PE ファイルの主要なセクションのインデックスとエントリ ポイントのアドレス。

ランタイムはこの情報に基づいてファイルを PE ファイルとして識別し、実行開始位置と、メモリにプログラムをいつ読み込むかを判断します。| -|MSIL の命令|コードを構成する Microsoft Intermediate Language \(MSIL\) の命令。 ほとんどの MSIL 命令には、メタデータ トークンが付いています。| -|メタデータ|メタデータ テーブルおよびヒープ。 ランタイムはこのセクションを使用してコード内のすべての型およびメンバーに関する情報を記録します。 また、このセクションには、カスタム属性やセキュリティ情報も格納されています。| +|MSIL の命令|コードを構成する Microsoft Intermediate Language (MSIL) の命令。 ほとんどの MSIL 命令には、メタデータ トークンが付いています。| +|メタデータ|メタデータ テーブルおよびヒープ。 ランタイムはこのセクションを使用してコード内のすべての型およびメンバーに関する情報を記録します。 また、このセクションには、カスタム属性やセキュリティ情報も格納されています。| -## 実行時のメタデータの使用 - メタデータと、共通言語ランタイムでのメタデータの役割をより深く理解するために、簡単なプログラムを作成し、メタデータがその有効期間中にどのように機能するかを示します。 `MyApp` と呼ばれるクラス内の 2 つのメソッドを表すコードの例を次に示します。 `Main` メソッドは、プログラムのエントリ ポイントです。`Add` メソッドは、2 つの整数引数の合計値を返します。 +## 実行時のメタデータの使用 + メタデータと、共通言語ランタイムでのメタデータの役割をより深く理解するために、簡単なプログラムを作成し、メタデータがその有効期間中にどのように機能するかを示します。 `MyApp` と呼ばれるクラス内の 2 つのメソッドを表すコードの例を次に示します。 `Main` メソッドは、プログラムのエントリ ポイントです。`Add` メソッドは、2 つの整数引数の合計値を返します。 ```vb Public Class MyApp @@ -130,9 +134,9 @@ public class MyApp } ``` - このコードを実行すると、ランタイムがモジュールをメモリに読み込み、このクラスのメタデータを調べます。 モジュールを読み込んだ後、ランタイムはメソッドの Microsoft Intermediate Language \(MSIL\) ストリームを詳細に分析して、そのストリームを高速のネイティブ機械語命令に変換します。 ランタイムはジャスト イン タイム \(JIT\) コンパイラを使用して、それぞれのメソッドを必要なときに 1 つずつ、MSIL 命令からネイティブ マシン語コードに変換します。 + このコードを実行すると、ランタイムがモジュールをメモリに読み込み、このクラスのメタデータを調べます。 モジュールを読み込んだ後、ランタイムはメソッドの Microsoft Intermediate Language (MSIL) ストリームを詳細に分析して、そのストリームを高速のネイティブ機械語命令に変換します。 ランタイムはジャスト イン タイム (JIT) コンパイラを使用して、それぞれのメソッドを必要なときに 1 つずつ、MSIL 命令からネイティブ マシン語コードに変換します。 - 上記のコードの `Main` 関数によって生成された MSIL の一部の例を次に示します。 MSIL とメタデータは、[MSIL 逆アセンブラー \(Ildasm.exe\)](../../docs/framework/tools/ildasm-exe-il-disassembler.md) を使用することにより、任意の .NET Framework アプリケーションから表示できます。 + 上記のコードの `Main` 関数によって生成された MSIL の一部の例を次に示します。 MSIL とメタデータは、[MSIL 逆アセンブラー (Ildasm.exe)](../../docs/framework/tools/ildasm-exe-il-disassembler.md) を使用することにより、任意の .NET Framework アプリケーションから表示できます。 ``` .entrypoint @@ -151,24 +155,25 @@ IL_000c: ldloc.1 IL_000d: call int32 ConsoleApplication.MyApp::Add(int32,int32) /* 06000003 */ ``` - JIT コンパイラはこのメソッド全体の MSIL を読み取って詳細に分析し、このメソッドの効率的なネイティブ命令を生成します。 `IL_000d`で、`Add` メソッドのメタデータ トークン \(`/*` `06000003 */`\) が検出されます。ランタイムは、このトークンを使用して **MethodDef** テーブルの 3 行目を調べます。 + JIT コンパイラはこのメソッド全体の MSIL を読み取って詳細に分析し、このメソッドの効率的なネイティブ命令を生成します。 `IL_000d` で、`Add` メソッドのメタデータ トークン (`/*` `06000003 */`) が検出されます。ランタイムは、このトークンを使用して **MethodDef** テーブルの 3 行目を調べます。 - **メソッドが記述されているメタデータ トークンによって参照される、`Add`MethodDef** テーブルの一部の例を次の表に示します。 このアセンブリにはほかにもメタデータ テーブルが存在し、それぞれ独自の値を持っていますが、ここでは、このテーブルだけを参照します。 + **メソッドが記述されているメタデータ トークンによって参照される、**MethodDef`Add` テーブルの一部の例を次の表に示します。 このアセンブリにはほかにもメタデータ テーブルが存在し、それぞれ独自の値を持っていますが、ここでは、このテーブルだけを参照します。 -|行|Relative Virtual Address \(RVA\)|ImplFlags|フラグ|名前

\(文字列ヒープを指す\)|Signature \(BLOB ヒープを指す\)| -|-------|--------------------------------------|---------------|---------|--------------------------|-------------------------------| -|1|0x00002050|IL

マネージ|パブリック

ReuseSlot

SpecialName

RTSpecialName

.ctor|.ctor \(コンストラクター\)|| +|行|Relative Virtual Address (RVA)|ImplFlags|フラグ|名前

(文字列ヒープを指す)|Signature (BLOB ヒープを指す)| +|---------|--------------------------------------|---------------|-----------|-----------------------------------------|----------------------------------------| +|1|0x00002050|IL

マネージ|パブリック

ReuseSlot

SpecialName

RTSpecialName

.ctor|.ctor (コンストラクター)|| |2|0x00002058|IL

マネージ|パブリック

スタティック

ReuseSlot|Main|文字列| |3|0x0000208c|IL

マネージ|パブリック

スタティック

ReuseSlot|追加|int, int, int| - このテーブルの各列には、コードについての重要な情報が格納されています。 ランタイムは **RVA**列を使用して、このメソッドを定義する MSIL の開始メモリ アドレスを計算します。 **ImplFlags** および **Flags** 列には、このメソッドを記述するビットマスク \(たとえば、メソッドがパブリックかプライベートかを記述するビットマスク\) が格納されています。 **Name** 列は、文字列ヒープからメソッドの名前へのインデックスとなります。 **Signature** 列は、BLOB ヒープ内のメソッドのシグネチャ定義へのインデックスとなります。 + このテーブルの各列には、コードについての重要な情報が格納されています。 ランタイムは **RVA** 列を使用して、このメソッドを定義する MSIL の開始メモリ アドレスを計算します。 **ImplFlags** および **Flags** 列には、このメソッドを記述するビットマスク (たとえば、メソッドがパブリックかプライベートかを記述するビットマスク) が格納されています。 **Name** 列は、文字列ヒープからメソッドの名前へのインデックスとなります。 **Signature** 列は、BLOB ヒープ内のメソッドのシグネチャ定義へのインデックスとなります。 - ランタイムは 3 行目の **RVA** 列から必要なオフセット アドレスを計算し、計算したオフセット アドレスを JIT コンパイラに返します。JIT コンパイラは計算された新しいアドレスに移動します。 JIT コンパイラは、新しいアドレスから、別のメタデータ トークンを検出するまで MSIL の処理を続行し、処理を繰り返します。 + ランタイムは 3 行目の **RVA** 列から必要なオフセット アドレスを計算し、計算したオフセット アドレスを JIT コンパイラに返します。JIT コンパイラは計算された新しいアドレスに移動します。 JIT コンパイラは、新しいアドレスから、別のメタデータ トークンを検出するまで MSIL の処理を続行し、処理を繰り返します。 - ランタイムは、メタデータを使用することにより、コードを読み込み、ネイティブ機械語命令に変換するのに必要なすべての情報にアクセスできます。 このように、メタデータによって自己言及的なファイルが使用可能になり、メタデータと共通型システムを組み合わせて使用することで、言語間で継承が可能になります。 + ランタイムは、メタデータを使用することにより、コードを読み込み、ネイティブ機械語命令に変換するのに必要なすべての情報にアクセスできます。 このように、メタデータによって自己言及的なファイルが使用可能になり、メタデータと共通型システムを組み合わせて使用することで、言語間で継承が可能になります。 -## 関連トピック +## 関連トピック |タイトル|説明| -|----------|--------| -|[属性](../../docs/standard/attributes/index.md)|属性の適用方法、カスタム属性の記述方法、および属性に格納されている情報の取得方法を説明します。| \ No newline at end of file +|-----------|-----------------| +|[属性](../../docs/standard/attributes/index.md)|属性の適用方法、カスタム属性の記述方法、および属性に格納されている情報の取得方法を説明します。| + diff --git a/docs/standard/native-interop.md b/docs/standard/native-interop.md index d982d2470a8..1b811b8505a 100644 --- a/docs/standard/native-interop.md +++ b/docs/standard/native-interop.md @@ -1,6 +1,6 @@ --- title: "ネイティブ相互運用性" -description: "ネイティブ相互運用性" +description: ".Net のネイティブ コンポーネントとやり取りする方法を説明します。" keywords: .NET, .NET Core author: blackdwarf ms.author: ronpet @@ -10,16 +10,17 @@ ms.prod: .net ms.technology: dotnet-standard ms.devlang: dotnet ms.assetid: 3c357112-35fb-44ba-a07b-6a1c140370ac -translationtype: Human Translation -ms.sourcegitcommit: d18b21b67c154c4a8cf8211aa5d1473066c53656 -ms.openlocfilehash: 13a4e4e7a588d55e82c5c4cde8f825c3b4502bb4 -ms.lasthandoff: 03/02/2017 +ms.translationtype: HT +ms.sourcegitcommit: 3155295489e1188640dae5aa5bf9fdceb7480ed6 +ms.openlocfilehash: 9652986491f087b8fa175e2b4041063c71211178 +ms.contentlocale: ja-jp +ms.lasthandoff: 08/21/2017 --- # ネイティブ相互運用性 -このドキュメントでは、.NET プラットフォームで使用可能な "ネイティブ相互運用性" を実行する&3; つのすべての方法についてもう少し深く掘り下げます。 +このドキュメントでは、.NET で使用可能な "ネイティブ相互運用性" を実行する 3 つのすべての方法についてもう少し深く掘り下げます。 ネイティブ コードを呼び出す理由はいくつかあります。 @@ -30,11 +31,11 @@ ms.lasthandoff: 03/02/2017 もちろん、上の一覧は、開発者がネイティブ コンポーネントとやり取りしたいと考える、またはその必要があるすべての可能性のある状況やシナリオを取り上げていません。 たとえば、.NET クラス ライブラリは、ネイティブ相互運用性サポートを使用して、コンソールのサポートと操作、ファイル システムのアクセスなど、そのかなりの数の API を実装しています。 ただし、それを必要とする場合に、オプションがあることに注意することが重要です。 > [!NOTE] -> このドキュメントのほとんどの例は、.NET Core でサポートされる&3; つすべてのプラットフォーム (Windows、Linux、macOS) について提示しています。 ただし、短い解説的な例については、Windows ファイル名と拡張子 (つまり、ライブラリの場合は "dll") を使用する&1; つのサンプルだけを示します。 これは、それらの機能が Linux や macOS で使用できないわけではなく、単に便宜上のためにのみそうしています。 +> このドキュメントのほとんどの例は、.NET Core でサポートされる 3 つすべてのプラットフォーム (Windows、Linux、macOS) について提示しています。 ただし、短い解説的な例については、Windows ファイル名と拡張子 (つまり、ライブラリの場合は "dll") を使用する 1 つのサンプルだけを示します。 これは、それらの機能が Linux や macOS で使用できないわけではなく、単に便宜上のためにのみそうしています。 ## プラットフォーム呼び出し (P/Invoke) -P/invoke は、アンマネージ ライブラリ内の構造体、コールバック、および関数をマネージ コードからアクセスできるようにするテクノロジです。 P/Invoke API のほとんどは、`System` と `System.Runtime.InteropServices` の&2; つの名前空間に含まれます。 これらの&2; つの名前空間を使用して、ネイティブ コンポーネントと通信する方法を記述する属性にアクセスできます。 +P/invoke は、アンマネージ ライブラリ内の構造体、コールバック、および関数をマネージ コードからアクセスできるようにするテクノロジです。 P/Invoke API のほとんどは、`System` と `System.Runtime.InteropServices` の 2 つの名前空間に含まれます。 これらの 2 つの名前空間を使用して、ネイティブ コンポーネントと通信する方法を記述する属性にアクセスできます。 最も一般的な例から始めましょう。これはマネージ コードでアンマネージ関数を呼び出します。 コマンドライン アプリケーションからメッセージ ボックスを表示してみましょう。 @@ -53,7 +54,6 @@ public class Program { MessageBox(IntPtr.Zero, "Command-line message box", "Attention!", 0); } } - ``` 上の例はとても簡単ですが、マネージ コードからアンマネージ関数を呼び出すために必要なことを示しています。 この例の手順を説明します。 @@ -84,7 +84,6 @@ namespace PInvokeSamples { } } } - ``` これはもちろん Linux でも似ています。 `getpid(2)` は [POSIX](https://en.wikipedia.org/wiki/POSIX) システム コールであるため、関数名が同じです。 @@ -107,7 +106,6 @@ namespace PInvokeSamples { } } } - ``` ### アンマネージ コードからのマネージ コードの呼び出し @@ -130,7 +128,7 @@ namespace ConsoleApplication1 { // Import user32.dll (containing the function we need) and define // the method corresponding to the native function. [DllImport("user32.dll")] - static extern int EnumWindows(EnumWC hWnd, IntPtr lParam); + static extern int EnumWindows(EnumWC lpEnumFunc, IntPtr lParam); // Define the implementation of the delegate; here, we simply output the window handle. static bool OutputWindow(IntPtr hwnd, IntPtr lParam) { @@ -144,7 +142,6 @@ namespace ConsoleApplication1 { } } } - ``` 例の手順に従う前に、使用する必要があるアンマネージ関数のシグネチャについて見直しておくのはよいことです。 すべてのウィンドウを列挙するために呼び出す関数は、次のシグネチャを持ちます。`BOOL EnumWindows (WNDENUMPROC lpEnumFunc, LPARAM lParam);` @@ -158,7 +155,7 @@ namespace ConsoleApplication1 { * 13 ～ 16 行目は、デリゲートを実装しています。 この簡単な例では、ハンドルだけコンソールに出力します。 * 最後に、19 行目で、外部メソッドを呼び出し、デリゲートを渡しています。 -Linux と macOS の例を、以下に示します。 それらの場合、`libc` C ライブラリに見つかる `ftw` 関数を使用します。 この関数は、ディレクトリ階層をスキャンするために使用し、そのパラメーターの&1; つとして、関数へのポインターを受け取ります。 上記のメソッドのシグネチャは次のとおりです。`int (*fn) (const char *fpath, const struct stat *sb, int typeflag)` +Linux と macOS の例を、以下に示します。 それらの場合、`libc` C ライブラリに見つかる `ftw` 関数を使用します。 この関数は、ディレクトリ階層をスキャンするために使用し、そのパラメーターの 1 つとして、関数へのポインターを受け取ります。 上記のメソッドのシグネチャは次のとおりです。`int (*fn) (const char *fpath, const struct stat *sb, int typeflag)` ```csharp using System; @@ -208,7 +205,6 @@ namespace PInvokeSamples { public long TimeLastStatusChange; } } - ``` macOS の例では、同じ関数を使用していますが、唯一の違いは `DllImport` 属性への引数です。macOS は `libc` を別の場所で保持しているためです。 @@ -261,7 +257,6 @@ namespace PInvokeSamples { public long TimeLastStatusChange; } } - ``` 上記の例のどちらも、パラメーターに依存し、どちらの場合もパラメーターは、マネージ型として指定されています。 ランタイムは、"正しいこと" を実行し、これらを他方の側で同等のものに処理します。 このプロセスでは、高品質なネイティブ相互運用コードを記述することがきわめて重要であるため、ランタイムが型を_マーシャリング_する際に何が起こるかを見てみましょう。 @@ -273,9 +268,8 @@ namespace PInvokeSamples { マーシャリングが必要な理由は、マネージ コードとアンマネージ コード内の型が異なるためです。 マネージ コードで、たとえば、`String` があるとします。アンマネージ環境では、文字列は Unicode ("ワイド")、Unicode 以外、Null 終了、ASCII などです。既定で、P/Invoke サブシステムは既定の動作に基づいて "正しいこと" をしようと試みますが、それらについては [MSDN](https://msdn.microsoft.com/library/zah6xy75.aspx) で確認できます。 ただし、特別な制御が必要な場合、`MarshalAs` 属性を採用して、アンマネージ側で期待する型を指定します。 たとえば、文字列を NULL で終わる ANSI 文字列として送信させる場合は、次のように指定できます。 ```csharp -[DllImport("somenativelibrary.dll"] +[DllImport("somenativelibrary.dll")] static extern int MethodA([MarshalAs(UnmanagedType.LPStr)] string parameter); - ``` ### クラスと構造体のマーシャリング @@ -303,10 +297,9 @@ public static void Main(string[] args) { GetSystemTime(st); Console.WriteLine(st.Year); } - ``` -上の例は、`GetSystemTime()` 関数を呼び出す簡単な例を示しています。 興味深い部分は 4 行目にあります。\.この属性は、他方 (アンマネージ) の側でクラスのフィールドを構造体に順番にマップする必要があることを指定します。 このことは、下に示すアンマネージ構造体に対応する必要があるため、フィールドの名前付けは重要でなく、それらの順番だけが重要であることを意味します。 +上の例は、`GetSystemTime()` 関数を呼び出す簡単な例を示しています。 興味深いビットは 4 行目にあります。 この属性は、他方 (アンマネージ) の側でクラスのフィールドを構造体に順番にマップする必要があることを指定します。 このことは、下に示すアンマネージ構造体に対応する必要があるため、フィールドの名前付けは重要でなく、それらの順番だけが重要であることを意味します。 ```c typedef struct _SYSTEMTIME { @@ -319,7 +312,6 @@ typedef struct _SYSTEMTIME { WORD wSecond; WORD wMilliseconds; } SYSTEMTIME, *PSYSTEMTIME*; - ``` 前の例で、これの Linux と macOS の例について既に説明しました。 下にもう一度示します。 @@ -341,7 +333,6 @@ public class StatClass { public long TimeLastModification; public long TimeLastStatusChange; } - ``` `StatClass` クラスは、UNIX システムで `stat` システム コールによって返される構造体を表します。 これは、指定したファイルに関する情報を表します。 上のクラスは、マネージ コードでの stat 構造体表現です。 ここでも、クラス内のフィールドはネイティブ構造体と同じ順番である必要があり (これらについては、任意の UNIX 実装の man ページを調べて参照できます)、基になる型が同じである必要があります。 diff --git a/docs/standard/net-standard.md b/docs/standard/net-standard.md index 959fc05a10e..635b0240a23 100644 --- a/docs/standard/net-standard.md +++ b/docs/standard/net-standard.md @@ -1,43 +1,42 @@ --- title: .NET Standard | Microsoft Docs -description: ".NET Standard の概要、そのバージョン、サポートされている .NET プラットフォームについて説明します。" +description: ".NET Standard、そのバージョン、.NET Standard をサポートする .NET 実装について説明します。" keywords: .NET Standard, PCL, .NET -author: richlander +author: mairaw ms.author: mairaw -ms.date: 03/17/2017 +ms.date: 08/13/2017 ms.topic: article ms.prod: .net ms.technology: dotnet-standard ms.devlang: dotnet ms.assetid: c044882c-af15-45f2-96d1-534557a5ee9b -ms.translationtype: Machine Translation -ms.sourcegitcommit: a580e33f756bfb5eb96daeb9decb4acfe3ef2f52 -ms.openlocfilehash: 970c70af2d8e5524e022f38d1ad93697a62985f8 +ms.translationtype: HT +ms.sourcegitcommit: b47d4c74a01b99d743b69328c201096bc8d89794 +ms.openlocfilehash: eaae98ce0f7a1b49669098812193ae1b629584a4 ms.contentlocale: ja-jp -ms.lasthandoff: 05/11/2017 - ---- +ms.lasthandoff: 08/21/2017 +--- # .NET Standard -[.NET Standard](https://github.com/dotnet/standard) は、すべての .NET ランタイムで使用できるようにすることを目的とした .NET API の正式な仕様です。 .NET Standard の背後にある意図は、.NET エコシステムの高度な統一性を確立することです。 [ECMA 335](https://github.com/dotnet/coreclr/blob/master/Documentation/project-docs/dotnet-standards.md) は引き続き .NET ランタイムの動作の統一性を確立しますが、.NET ライブラリの実装用の .NET 基底クラス ライブラリ (BCL) に同様の仕様はありません。 +[.NET Standard](https://github.com/dotnet/standard) は、すべての .NET 実装で使用できるようにすることを目的とした .NET API の正式な仕様です。 .NET Standard の背後にある意図は、.NET エコシステムの高度な統一性を確立することです。 [ECMA 335](https://github.com/dotnet/coreclr/blob/master/Documentation/project-docs/dotnet-standards.md) は引き続き .NET 実装の動作の統一性を確立しますが、.NET ライブラリの実装用の .NET 基底クラス ライブラリ (BCL) に同様の仕様はありません。 .NET Standard により、次の主なシナリオが可能になります。 -- ワークロードに関係なく、すべての .NET プラットフォーム用に統一された BCL API のセットを定義し、実装する。 -- 開発者が、この同じ API のセットを使用して、.NET ランタイム間で使用可能なポータブル ライブラリを生成できるようにする。 -- .NET API による共有ソースの条件付きコンパイルを削減するか、できればなくし、OS API に対してのみにする。 +- ワークロードに関係なく、すべての .NET 実装用に統一された BCL API のセットを定義し、実装する。 +- 開発者が、この同じ API のセットを使用して、.NET 実装間で使用可能なポータブル ライブラリを生成できるようにする。 +- .NET API による共有ソースの条件付きコンパイルを削減あるいはなくして、OS API に対してのみにする。 -さまざまな .NET ランタイムが、.NET Standard の特定のバージョンを実装します。 各 .NET ランタイム バージョンは、それがサポートしている最高の .NET Standard バージョンをアドバタイズし、そのことは以前のバージョンもサポートしていることを意味します。 たとえば、.NET Framework 4.6 は .NET Standard 1.3 を実装しており、このことは、.NET Standard のバージョン 1.0 ～ 1.3 で定義されているすべての API を公開していることを意味します。 同様に、.NET Framework 4.6.1 は .NET Standard 1.5 を実装し、.NET Core 1.0 は .NET Standard 1.6 を実装しています。 +さまざまな .NET 実装が、.NET Standard の特定のバージョンを対象とします。 各 .NET 実装バージョンは、それがサポートしている最高の .NET Standard バージョンをアドバタイズし、そのことは以前のバージョンもサポートしていることを意味します。 たとえば、.NET Framework 4.6 は .NET Standard 1.3 を実装しており、このことは、.NET Standard のバージョン 1.0 ～ 1.3 で定義されているすべての API を公開していることを意味します。 同様に、.NET Framework 4.6.1 は .NET Standard 1.4 を実装し、.NET Core 1.0 は .NET Standard 1.6 を実装しています。 -## .NET Platform のサポート +## .NET 実装のサポート 次の表は、.NET Standard のすべてのバージョンとサポートされているプラットフォームの一覧です。 [!INCLUDE [net-standard-table](~/includes/net-standard-table.md)] 対象にすることができる最高バージョンの .NET Standard を確認するには、次の手順を実行します。 -1. 実行する .NET プラットフォームを示す行を探します。 +1. 実行する .NET 実装を示す行を探します。 2. この行内で、右から左の方向に、バージョンを示す列を探します。 3. 列見出しは、ターゲットがサポートしている .NET Standard バージョンです (そのバージョン以下の .NET Standard バージョンでもサポートされます)。 4. 対象にするプラットフォームごとに、この手順を繰り返します。 複数のターゲット プラットフォームがある場合は、その中から低いバージョンを選択することをお勧めします。 たとえば、.NET Framework 4.5 と .NET Core 1.0 で実行する場合、使用できる .NET Standard の最高のバージョンは .NET Standard 1.1 です。 @@ -58,11 +57,11 @@ ms.lasthandoff: 05/11/2017 バージョン管理規則は主に 2 つあります。 - 追加式。.NET Standard バージョンは論理的に同心円形です。高位のバージョンには、旧バージョンのすべての API が組み込まれています。 バージョン間に互換性に影響する変更はありません。 -- 不変。 出荷後、.NET Standard のバージョンは固定されます。 新しい API は、特定の .NET プラットフォーム (.NET Core など) でまず使用できるようになります。 .NET Standard の審査会が、新しい API を全ユーザーに使用できるようにした方がよいと判断すると、新しい .NET Standard バージョンに追加されます。 +- 不変。 出荷後、.NET Standard のバージョンは固定されます。 新しい API は、特定の .NET 実装 (.NET Core など) でまず使用できるようになります。 .NET Standard の審査会が、新しい API を全ユーザーに使用できるようにした方がよいと判断すると、新しい .NET Standard バージョンに追加されます。 ## ポータブル クラス ライブラリとの比較 -.NET Standard は、次世代の[ポータブル クラス ライブラリ (PCL)](https://msdn.microsoft.com/library/gg597391.aspx) と考えることができます。 .NET Standard は、標準 BCL を精選し、結果として、.NET ランタイム間で高度な統一性を確立することによって、ポータブル ライブラリの作成の方法を向上しています。 .NET Standard を対象とするライブラリは、PCL つまり ".NET Standard ベースの PCL" です。 既存の PCL は、"プロファイルベースの PCL" です。 +.NET Standard は、[ポータブル クラス ライブラリ (PCL)](./cross-platform/cross-platform-development-with-the-portable-class-library.md) に代わるものです。 .NET Standard は、標準 BCL を精選し、結果として、.NET 実装間で高度な統一性を確立することによって、ポータブル ライブラリの作成の方法を向上しています。 .NET Standard を対象とするライブラリは、PCL つまり ".NET Standard ベースの PCL" です。 既存の PCL は、"プロファイルベースの PCL" です。 .NET Standard と PCL プロファイルは、似たような目的で作成されましたが、主な点が異なります。 @@ -78,13 +77,13 @@ ms.lasthandoff: 05/11/2017 ## 指定 -.NET Standard の仕様は、標準化された API のセットです。 この仕様は、.NET ランタイムの実装、具体的には Microsoft (.NET Framework、.NET Core、Mono を含む) と Unity によって管理されています。 [GitHub](https://github.com/dotnet/standard) 経由の新しい .NET Standard のバージョンの構築の一環として、公開フィードバック プロセスが使われています。 +.NET Standard の仕様は、標準化された API のセットです。 この仕様は、.NET 実装、具体的には Microsoft (.NET Framework、.NET Core、Mono を含む) と Unity によって管理されています。 [GitHub](https://github.com/dotnet/standard) 経由の新しい .NET Standard のバージョンの構築の一環として、公開フィードバック プロセスが使われています。 ### 正式な成果物 -正式な仕様は標準に含まれる API を定義する一連の .cs ファイルです。 各[コンポーネント](https://github.com/dotnet/corefx/tree/master/src) の [ref ディレクトリ](https://github.com/dotnet/corefx/tree/master/src/System.Runtime/ref) に.NET Standard API が定義されています。 ref 成果物は [CoreFX リポジトリ](https://github.com/dotnet/corefx)内に存在しますが、それらは .NET Core 固有ではありません。 +正式な仕様は標準に含まれる API を定義する一連の .cs ファイルです。 [dotnet/standard リポジトリ](https://github.com/dotnet/corefx/tree/master/src)の [ref](https://github.com/dotnet/standard/tree/master/netstandard/ref) ディレクトリに.NET Standard API が定義されています。 -[NETStandard.Library](https://www.nuget.org/packages/NETStandard.Library) メタパッケージ ([ソース](https://github.com/dotnet/standard/blob/master/netstandard/pkg/NETStandard.Library.dependencies.props)) は、1 つ以上の .NET Standard Library のバージョンを定義する (一部) ライブラリのセットについて説明しています。 +[NETStandard.Library](https://www.nuget.org/packages/NETStandard.Library) メタパッケージ ([ソース](https://github.com/dotnet/standard/blob/master/netstandard/pkg/NETStandard.Library.dependencies.props)) は、1 つ以上の .NET Standard のバージョンを定義する (一部) ライブラリのセットについて説明しています。 System.Runtime などの特定のコンポーネントは、次のように説明されています。 @@ -98,7 +97,7 @@ System.Runtime などの特定のコンポーネントは、次のように説 ### パッケージ表現 -.NET Standard 参照アセンブリの主要な配布手段は [NuGet パッケージ](../core/packages.md)です。 実装は、各 .NET ランタイムに適切なさまざまな方法で配布されます。 +.NET Standard 参照アセンブリの主要な配布手段は [NuGet パッケージ](../core/packages.md)です。 実装は、各 .NET 実装に適切なさまざまな方法で配布されます。 NuGet パッケージは 1 つまたは複数の[フレームワーク](frameworks.md)を対象にしています。 .NET Standard パッケージは、".NET Standard" フレームワークを対象にしています。 `netstandard` [compact TFM](frameworks.md) (`netstandard1.4` など) を使用して、.NET Standard Framework を対象にすることができます。 複数のランタイムでの実行を意図したライブラリは、このフレームワークを対象とする必要があります。 @@ -108,9 +107,9 @@ NuGet パッケージは 1 つまたは複数の[フレームワーク](framewor 仕様は 1 つだけではありませんが、段階的に拡張され、直線的にバージョン管理された API のセットです。 標準の最初のバージョンは、API のベースライン セットを構築しています。 それ以降のバージョンでは、API が追加され、以前のバージョンによって定義された API を継承しています。 標準から API を削除するために確立された取り決めはありません。 -.NET Standard は、1 つの .NET ランタイムに固有ではなく、それらのランタイムのいずれかのバージョン管理スキームに一致することもありません。 +.NET Standard は、1 つの .NET 実装に固有ではなく、それらの実装のいずれかのバージョン管理スキームに一致することもありません。 -いずれかのランタイム (.NET Framework、.NET Core、Mono など) に追加された API は、本質的に基本的であると考えられる場合に、仕様に追加される候補とみなされる可能性があります。 新しい[.NET Standard のバージョン](https://github.com/dotnet/standard/blob/master/docs/versions.md) は、.NET ランタイムのリリースに基づいて作成されるので、.NET Standard PCL から新しい API を対象にすることができます。 バージョン管理メカニズムの詳細は、「[.NET Core Versioning](../core/versions/index.md)」(.NET Core のバージョン管理) で説明されています。 +いずれかの実装 (.NET Framework、.NET Core、Mono など) に追加された API は、本質的に基本的であると考えられる場合に、仕様に追加される候補とみなされる可能性があります。 新しい[.NET Standard のバージョン](https://github.com/dotnet/standard/blob/master/docs/versions.md) は、.NET 実装のリリースに基づいて作成されるので、.NET Standard PCL から新しい API を対象にすることができます。 バージョン管理メカニズムの詳細は、「[.NET Core Versioning](../core/versions/index.md)」(.NET Core のバージョン管理) で説明されています。 .NET Standard のバージョン管理は、使用する場合に重要です。 .NET Standard のバージョンが指定されている場合、それと同じか以下のバージョンを対象とするライブラリを使用できます。 次の方法では、.NET Standard の対象設定に固有の、.NET Standard PCL の使用のワークフローを説明します。 diff --git a/docs/standard/parallel-processing-and-concurrency.md b/docs/standard/parallel-processing-and-concurrency.md index 95c7e457015..4df40e70bf3 100644 --- a/docs/standard/parallel-processing-and-concurrency.md +++ b/docs/standard/parallel-processing-and-concurrency.md @@ -1,44 +1,49 @@ --- -title: "Parallel Processing and Concurrency in the .NET Framework | Microsoft Docs" -ms.custom: "" -ms.date: "03/30/2017" -ms.prod: ".net" -ms.reviewer: "" -ms.suite: "" -ms.technology: - - "dotnet-standard" -ms.tgt_pltfrm: "" -ms.topic: "article" -helpviewer_keywords: - - ".NET Framework, parallel processing" - - "parallel processing [.NET Framework]" - - "concurrency [.NET Framework]" - - ".NET Framework, concurrency" +title: ".NET Framework の並列処理と同時実行" +ms.custom: +ms.date: 03/30/2017 +ms.prod: .net +ms.reviewer: +ms.suite: +ms.technology: dotnet-standard +ms.tgt_pltfrm: +ms.topic: article +helpviewer_keywords: +- .NET Framework, parallel processing +- parallel processing [.NET Framework] +- concurrency [.NET Framework] +- .NET Framework, concurrency ms.assetid: e573faa8-0212-44b1-a850-ce85dc54f47f caps.latest.revision: 7 -author: "rpetrusha" -ms.author: "ronpet" -manager: "wpickett" -caps.handback.revision: 7 +author: rpetrusha +ms.author: ronpet +manager: wpickett +ms.translationtype: HT +ms.sourcegitcommit: 306c608dc7f97594ef6f72ae0f5aaba596c936e1 +ms.openlocfilehash: 589bb8fc36d95a48930e4b51a096e7db18905397 +ms.contentlocale: ja-jp +ms.lasthandoff: 08/21/2017 + --- -# Parallel Processing and Concurrency in the .NET Framework +# .NET Framework の並列処理と同時実行 .NET Framework には、ユーザーのコンピューターのパフォーマンスを最大化しながら、アプリケーションのユーザーに対する応答性を維持するために、複数の実行スレッドを使用する方法がいくつか用意されています。 -## このセクションの内容 - [Threading](../../docs/standard/threading/index.md) +## このセクションの内容 + [スレッド化](../../docs/standard/threading/index.md) .NET Framework に用意されている基本的な同時実行および同期のための機構について説明します。 - [Asynchronous Programming Patterns](../../docs/standard/asynchronous-programming-patterns/index.md) + [非同期プログラミングのパターン](../../docs/standard/asynchronous-programming-patterns/index.md) .NET Framework でサポートされている 3 種類の非同期パターンのプログラミングの概要が記載されています。 -- [Asynchronous Programming Model \(APM\)](../../docs/standard/asynchronous-programming-patterns/asynchronous-programming-model-apm.md) \(レガシ\) +- [非同期プログラミング モデル (APM)](../../docs/standard/asynchronous-programming-patterns/asynchronous-programming-model-apm.md) (レガシ) -- [Event\-based Asynchronous Pattern \(EAP\)](../../docs/standard/asynchronous-programming-patterns/event-based-asynchronous-pattern-eap.md) \(レガシ\) +- [イベント ベースの非同期パターン (EAP)](../../docs/standard/asynchronous-programming-patterns/event-based-asynchronous-pattern-eap.md) (レガシ) -- [Task\-based Asynchronous Pattern \(TAP\)](../../docs/standard/asynchronous-programming-patterns/task-based-asynchronous-pattern-tap.md) \(新規開発に推奨\) +- [タスク ベースの非同期パターン (TAP)](../../docs/standard/asynchronous-programming-patterns/task-based-asynchronous-pattern-tap.md) (新規の開発に推奨) - [Parallel Programming](../../docs/standard/parallel-programming/index.md) - 並行開発を簡素化し、スレッドやスレッド プールを直接操作することなく、効率的で詳細かつスケーラブルな並列コードを自然な表現方法で記述できるようになるタスク ベースのプログラミング モデルについて説明します。 + [並列プログラミング](../../docs/standard/parallel-programming/index.md) + 並行開発を簡素化するタスクベースのプログラミング モデルについて説明します。このモデルにより、スレッドやスレッド プールを直接操作することなく、効率的で詳細な、拡張性のある並列コードを自然な表現方法で記述できるようになります。 -## 参照 - [開発ガイド](../../docs/framework/development-guide.md) \ No newline at end of file +## 関連項目 + [開発ガイド](../../docs/framework/development-guide.md) + diff --git a/docs/standard/tour.md b/docs/standard/tour.md index ec2ecf68af6..e2d5fef788f 100644 --- a/docs/standard/tour.md +++ b/docs/standard/tour.md @@ -1,53 +1,48 @@ --- -title: ".NET のツアー" -description: ".NET プラットフォームのいくつかの優れた機能についてのガイド付きツアーです。" +title: ".NET のツアー | Microsoft Docs" +description: ".NET のいくつかの優れた機能についてのガイド付きツアーです。" keywords: ".NET, .NET Core, ツアー, プログラミング言語, アンセーフ, メモリ管理, タイプ セーフ, 非同期" author: cartermp ms.author: wiwagn -ms.date: 02/09/2016 +ms.date: 05/22/2017 ms.topic: article ms.prod: .net ms.technology: dotnet-standard ms.devlang: dotnet ms.assetid: bbfe6465-329d-4982-869d-472e7ef85d93 -ms.translationtype: Machine Translation -ms.sourcegitcommit: d00f2096e0799107a8a2ff1d12274c6026d4c27a -ms.openlocfilehash: 50e5b333f892cf469e9f3fe57a0325ac6d8e641f +ms.translationtype: HT +ms.sourcegitcommit: 2762cdc983465979a530192716c33de7044dd1ed +ms.openlocfilehash: c64a3113cf4e9e9ff203ed2cf449359f67ee9d10 ms.contentlocale: ja-jp -ms.lasthandoff: 05/22/2017 +ms.lasthandoff: 08/21/2017 --- # .NET のツアー -.NET は、汎用的な開発プラットフォームです。 .NET には、複数のプラットフォームでのさまざまなシナリオを可能にする、複数のプログラミング言語、非同期および同時実行のプログラミング モデル、ネイティブな相互運用性など、重要な機能がいくつかあります。 +.NET は、汎用的な開発プラットフォームです。 .NET には、複数のプラットフォームでのさまざまなシナリオを可能にする、複数のプログラミング言語、非同期および同時実行のプログラミング モデル、ネイティブな相互運用性のサポートなど、重要な機能がいくつかあります。 -この記事は、.NET プラットフォームのいくつかの重要な機能についてのガイド付きツアーです。 - -.NET アーキテクチャの "構成要素" とそれらの用途については、「[.NET アーキテクチャ コンポーネント](components.md)」をご覧ください。 +この記事は、.NET のいくつかの重要な機能についてのガイド付きツアーです。 .NET アーキテクチャの構成要素とそれらの用途については、「[.NET アーキテクチャ コンポーネント](components.md)」をご覧ください。 ## コード サンプルの実行方法 -コード サンプルを実行できるように開発環境を設定する方法については、「[Getting Started](get-started.md)」 (概要) をご覧ください。 このページのコード サンプルをコピーして環境に貼り付け、実行することができます。 - -> [!NOTE] -将来的には、このドキュメント サイトからブラウザーでコード サンプルを実行できるようにします。 +コード サンプルを実行できるように開発環境を設定する方法については、「[Getting Started](get-started.md)」 (はじめに) をご覧ください。 このページのコード サンプルをコピーして環境に貼り付けて実行します。 ## プログラミング言語 -.NET は複数のプログラミング言語をサポートしています。 .NET ランタイムでは、[共通言語基盤 (CLI)](https://www.visualstudio.com/license-terms/ecma-c-common-language-infrastructure-standards/) が実装されています。CLI では特に、言語に依存しないランタイムと言語の相互運用性が指定されています。 つまり、任意の .NET 言語を選んで、.NET でアプリとサービスを作成できます。 +.NET は複数のプログラミング言語をサポートしています。 .NET 実装では、[共通言語基盤 (CLI)](https://www.visualstudio.com/license-terms/ecma-c-common-language-infrastructure-standards/) が実装されています。CLI では特に、言語に依存しないランタイムと言語の相互運用性が指定されています。 つまり、任意の .NET 言語を選んで、.NET でアプリとサービスを作成します。 -Microsoft が開発とサポートに力を注いでいる .NET 言語は、C#、F#、Visual Basic .NET の 3 つです。 +Microsoft が開発とサポートに力を注いでいる .NET 言語は、C#、F#、Visual Basic (VB) の 3 つです。 -* C# はシンプル、強力、タイプセーフ、そしてオブジェクト指向でありながらも、C スタイル言語の表現力と簡潔さが維持されています。 C や類似の言語を使い慣れている人であれば、ほとんど問題なく C# に適応できるでしょう。 C# について詳しくは、「[C# Guide](../csharp/index.md)」 (C# ガイド) をご覧ください。 +* C# はシンプル、強力、タイプセーフ、そしてオブジェクト指向でありながらも、C スタイル言語の表現力と簡潔さが維持されています。 C や類似の言語を使い慣れている人であれば、ほとんど問題なく C# に適応できます。 C# について詳しくは、「[C# Guide](../csharp/index.md)」 (C# ガイド) をご覧ください。 -* F# はクロスプラットフォームの関数型プログラミング言語ですが、従来のオブジェクト指向および命令型プログラミングもサポートしています。 F# について詳しくは、「[F# Guide](../fsharp/index.md)」 (F# ガイド) をご覧ください。 +* F# はクロスプラットフォームの関数型プログラミング言語ですが、従来のオブジェクト指向および命令型プログラミングもサポートしています。 F# について詳しくは、「[F# Guide](../fsharp/index.md)」 (F# ガイド) をご覧ください。 -* Visual Basic は、学習しやすい言語で、.NET 上で実行されるさまざまなアプリケーションの構築に使用できます。 +* Visual Basic は、学習しやすい言語で、.NET 上で実行されるさまざまなアプリの構築に使用します。 .NET 言語の中で VB の構文は通常の人間の言語に最も近いため、ソフトウェア開発の経験のないユーザーでも使いやすい言語です。 ## 自動メモリ管理 -.NET は、[ガベージ コレクション](garbagecollection/index.md)を使ってプログラムの自動メモリ管理を行います。 GC はメモリ管理に対する遅延アプローチで動作します。この場合、メモリの即時収集よりもアプリケーションのスループットが優先されます。 .NET GC について詳しくは、「[ガベージ コレクションの基礎](garbagecollection/fundamentals.md)」をご覧ください。 +.NET は、[ガベージ コレクション (GC) ](garbagecollection/index.md)を使ってプログラムの自動メモリ管理を行います。 GC はメモリ管理に対する遅延アプローチで動作します。この場合、メモリの即時収集よりもアプリのスループットが優先されます。 .NET GC について詳しくは、「[ガベージ コレクションの基礎](garbagecollection/fundamentals.md)」をご覧ください。 以下の 2 つの行はどちらもメモリを割り当てています。 @@ -55,7 +50,7 @@ Microsoft が開発とサポートに力を注いでいる .NET 言語は、C# ガベージ コレクターがスケジュールされた実行によってメモリを解放する際に割り当て解除が自動的に行われるため、メモリの割り当てを解除するための類似したキーワードはありません。 -ガベージ コレクターは、*メモリの安全性*の確保に役立つサービスの 1 つにすぎません。 メモリの安全性の不変性は非常に単純です。プログラムが割り当てられている (そして解放されていない) メモリのみにアクセスする場合、そのプログラムはメモリ セーフです。 たとえば、ランタイムによってプログラムが配列の最後にインデックス処理を行ったり、オブジェクトの最後にある実在しないフィールドにアクセスしたりすることがなくなります。 +ガベージ コレクターは、"*メモリの安全性*" の確保に役立つサービスの 1 つです。 割り当てられているメモリのみにプログラムがアクセスする場合、そのプログラムはメモリ セーフです。 たとえば、ランタイムでは、配列の範囲を超えた割り当てられていないメモリにアプリがアクセスしていないことを確認します。 次の例では、メモリの安全性を確保するため、ランタイムにより `InvalidIndexException` 例外がスローされます。 @@ -63,95 +58,95 @@ Microsoft が開発とサポートに力を注いでいる .NET 言語は、C# ## アンマネージ リソースの操作 -一部のオブジェクトは、*アンマネージ リソース*を参照します。 アンマネージ リソースは、.NET ランタイムで自動的に維持されないリソースです。 たとえば、ファイル ハンドルは、アンマネージ リソースです。 @System.IO.FileStream オブジェクトはマネージ オブジェクトですが、アンマネージドのファイル ハンドルを参照します。 FileStream の使用が終わったら、ファイル ハンドルを解放する必要があります。 +一部のオブジェクトは、*アンマネージ リソース*を参照します。 アンマネージ リソースは、.NET ランタイムで自動的に維持されないリソースです。 たとえば、ファイル ハンドルは、アンマネージ リソースです。 オブジェクトはマネージ オブジェクトですが、アンマネージドのファイル ハンドルを参照します。 の使用が終わったら、ファイル ハンドルを解放する必要があります。 -.NET では、アンマネージ リソースを参照するオブジェクトは @System.IDisposable インターフェイスを実装します。 オブジェクトの使用が終わったら、すべてのアンマネージ リソースを解放する、オブジェクトの @System.IDisposable.Dispose メソッドを呼び出します。 そのようなオブジェクトに対し、.NET 言語では次の例のように便利な `using` 構文が提供されています。 +.NET では、アンマネージ リソースを参照するオブジェクトは インターフェイスを実装します。 オブジェクトの使用が終わったら、すべてのアンマネージ リソースを解放する、オブジェクトの メソッドを呼び出します。 そのようなオブジェクトに対し、.NET 言語では次の例に示すように便利な `using` 構文が提供されています。 [!code-csharp[UnmanagedResources](../../samples/csharp/snippets/tour/UnmanagedResources.csx#L1-L6)] -`using` ブロックが完了すると、.NET ランタイムがファイル ハンドルを開放する `stream` オブジェクトの @System.IDisposable.Dispose メソッドを自動的に呼び出します。 これは、例外によってコントロールがブロックを離れた場合にも行われます。 +`using` ブロックが完了すると、.NET ランタイムがファイル ハンドルを開放する `stream` オブジェクトの メソッドを自動的に呼び出します。 これは、例外によってコントロールがブロックを離れた場合にも行われます。 -詳細については、次のページを参照してください。 +詳しくは、次のトピックをご覧ください。 -* C# の場合: [using ステートメント](../csharp/language-reference/keywords/using-statement.md) -* F# の場合: [リソースの管理: `use` キーワード](../fsharp/language-reference/resource-management-the-use-keyword.md) -* Visual Basic の場合: [Using ステートメント](../visual-basic/language-reference/statements/using-statement.md) +* C# の場合は、「[using ステートメント (C# リファレンス)](../csharp/language-reference/keywords/using-statement.md)」を参照してください。 +* F# の場合は、「[リソースの管理: use キーワード](../fsharp/language-reference/resource-management-the-use-keyword.md)」を参照してください。 +* VB の場合は、「[Using Statement (Visual Basic)](../visual-basic/language-reference/statements/using-statement.md)」 (using ステートメント (Visual Basic)) を参照してください。 ## タイプ セーフ -オブジェクトには、型が割り当てられます。 指定のオブジェクトが許可される操作、および使用するメモリは、その型から決まります。 `Dog` 型には `Jump` と `WagTail` メソッドを含むことができますが、`SumTotal` メソッドが含まれることはないでしょう。 プログラムは、指定された型の宣言されたメソッドのみを呼び出すことができます。 それ以外のどの呼び出しを行っても、コンパイル時エラーまたはランタイム例外が発生します (動的機能または `object` を使用した場合)。 +オブジェクトは特定の型のインスタンスです。 指定のオブジェクトが許可される操作は、その型から決まります。 `Dog` 型には `Jump` と `WagTail` メソッドを含むことができますが、`SumTotal` メソッドを含むことはできません。 プログラムは、特定の型に属するメソッドのみを呼び出します。 それ以外のどの呼び出しを行っても、コンパイル時エラーまたはランタイム例外が発生します (動的機能または `object` を使用した場合)。 -.NET 言語は、オブジェクト指向で、基本クラスと派生クラスの階層を含みます。 .NET ランタイムではオブジェクトの階層に応じたオブジェクトのキャストと呼び出しのみが許可されます。 .NET 言語で定義されているすべての型が、基本の `object` 型から派生していることを覚えておいてください。 +.NET 言語は、オブジェクト指向で、基本クラスと派生クラスの階層を含みます。 .NET ランタイムではオブジェクトの階層に応じたオブジェクトのキャストと呼び出しのみが許可されます。 .NET 言語で定義されているすべての型が、基本の 型から派生していることを覚えておいてください。 -[!code-csharp[TypeSafety](../../samples/csharp/snippets/tour/TypeSafety.csx#L18-L23)] +[!code-csharp[TypeSafety](../../samples/csharp/snippets/tour/TypeSafety.csx#L19-L23)] タイプ セーフは、アクセサー キーワードの忠実性を保証することで、カプセル化の支援を行うためにも使用されます。 アクセサー キーワードは、指定した型のメンバーへのアクセスを他のコードによって制御する成果物です。 これらは通常、その動作を管理するために使用される型に含まれる、さまざまな種類のデータに使用されます。 [!code-csharp[TypeSafety](../../samples/csharp/snippets/tour/TypeSafety.csx#L3-L3)] -C#、Visual Basic、F# は、ローカルな**型推論**をサポートします。 型推論は、コンパイラが右側にある式から左側にある式の型を推論するという意味です。 タイプ セーフの破損、または回避を意味するわけではありません。 結果の型には、推論されるすべてを含む厳密な型が**含まれます**。 前の例の最初の 2 行を、型推論を示すように書き換えてみましょう。 例の残りの部分はまったく同じであることに注意してください。 +C#、VB、F# では、ローカルな "*型推論*" をサポートします。 型推論は、コンパイラが右側にある式から左側にある式の型を推論するという意味です。 タイプ セーフの破損、または回避を意味するわけではありません。 結果の型には、推論されるすべてを含む厳密な型が含まれます。 前の例の `dog` と `cat` を書き換えて型の推論を導入し、残りの部分はそのままとします。 [!code-csharp[TypeSafety](../../samples/csharp/snippets/tour/TypeSafety.csx#L28-L34)] -F# は、C# や Visual Basic のメソッド ローカルな型推論よりさらに進んだ型推論機能を備えています。 詳しくは、「[Type Inference](../fsharp/language-reference/type-inference.md)」 (型推論) をご覧ください。 +F# は、C# や VB のメソッド ローカル型推論よりさらに進んだ型推論機能を備えています。 詳しくは、「[Type Inference](../fsharp/language-reference/type-inference.md)」 (型推論) をご覧ください。 ## デリゲートとラムダ -デリゲートは C++ の関数ポインターに似ていますが、大きな違いはタイプ セーフであることです。 CLR 型システム内で接続されていないメソッドの一種です。 通常のメソッドはクラスに接続されており、静的な、またはインスタンスが呼び出す規則によってのみ直接呼び出すことができます。 +デリゲートは、メソッド シグネチャで表されます。 そのシグネチャを持つ任意のメソッドをデリゲートに割り当てることができます。割り当てたメソッドは、デリゲートが呼び出されると実行されます。 -デリゲートは、.NET の世界のさまざまな API や場所で使用されます。このうち、特に使用されるのが、LINQ の要となるラムダ式です。 +デリゲートは、C++ の関数ポインターに似ています。ただし、タイプ セーフであるという点は異なります。 CLR 型システム内で接続されていないメソッドの一種です。 通常のメソッドはクラスに接続されており、静的な、またはインスタンスが呼び出す規則によってのみ直接呼び出すことができます。 -詳細については、「[Delegates and lambdas](delegates-lambdas.md)」(デリゲートとラムダ) のドキュメントを参照してください。 +.NET では、デリゲートはイベント ハンドラー (非同期の操作を定義するとき) やラムダ式 (LINQ の基軸である) でよく使用されます。 詳細について、「[デリゲートとラムダ](delegates-lambdas.md)」を参照してください。 ## ジェネリック -ジェネリックは、.NET Framework 2.0 で追加された機能です。 簡単に言えば、ジェネリックを使用することで、プログラマがクラスを設計する際に "型パラメーター" を導入することができ、これによってクライアント コード (その型のユーザー) が型パラメーターの代わりに使用する正確な型を指定できるようになります。 +ジェネリックを使用することで、プログラマーがクラスを設計する際に "*型パラメーター*" を導入することができ、これによってクライアント コード (その型のユーザー) が型パラメーターの代わりに使用する正確な型を指定できるようになります。 -ジェネリックは、プログラマが汎用的なデータ構造を実装するために追加されました。 それ以前は、たとえば `List` 型をジェネリックにするには、`object` 型の要素を使用する必要がありました。 これにより、軽微なランタイム エラーの可能性があることは言うまでもなく、パフォーマンスやセマンティックのさまざまな問題が発生することがありました。 セマンティックに関して特に問題だったのは、データ構造にたとえば整数と文字列の両方が含まれる場合にリストのメンバーを操作すると `InvalidCastException` がスローされるということです。 +ジェネリックは、プログラマが汎用的なデータ構造を実装するために追加されました。 それ以前は、`List` などの型をジェネリックにするには、`object` 型の要素を使用する必要がありました。 これにより、軽微なランタイム エラーの可能性があることは言うまでもなく、パフォーマンスやセマンティックのさまざまな問題が発生することがありました。 セマンティックに関して特に問題だったのは、データ構造にたとえば整数と文字列の両方が含まれる場合にリストのメンバーを操作すると `InvalidCastException` がスローされるということです。 -以下のサンプルに、@System.Collections.Generic.List%601 型のインスタンスを使用して実行される基本的なプログラムを示します。 +以下のサンプルに、 型のインスタンスを使用して実行される基本的なプログラムを示します。 [!code-csharp[GenericsShort](../../samples/csharp/snippets/tour/GenericsShort.csx)] -詳細については、「[Generic types (Generics) overview](generics.md)」(ジェネリック型 (ジェネリック) の概要) の記事を参照してください。 +詳細については、トピック「[ジェネリック型 (ジェネリック) の概要](generics.md)」を参照してください。 ## 非同期プログラミング 非同期プログラミングは、ランタイムでの非同期サポート、フレームワーク ライブラリ、.NET 言語構成要素が含まれる、.NET のファースト クラスの概念です。 内部は、オペレーティング システムを利用して可能な限り効率的に I/O バウンドなジョブを実行する、(`Task` などの) オブジェクトに基づいています。 -.NET の非同期プログラミングの詳細を理解するには、最初に「[Async overview](async.md)」(非同期の概要) を参照してください。 +.NET の非同期プログラミングの詳細を理解するには、最初にトピック「[非同期の概要](async.md)」を参照してください。 ## 統合言語クエリ (LINQ) LINQ は、データ操作のための単純な宣言型コードを記述できる、C# および VB の強力な一連の機能です。 データは (メモリ内オブジェクト、SQL データベース、XML ドキュメントなどの) さまざまな形式にすることができますが、記述する LINQ コードは通常、どのデータ ソースでも違いがないように見えます。 -詳細および一部のサンプルを確認するには、「[LINQ (Language Integrated Query)](using-linq.md)」(LINQ (統合言語クエリ)) を参照してください。 +詳細および一部のサンプルを確認するには、トピック「[LINQ (統合言語クエリ)](using-linq.md)」を参照してください。 ## ネイティブ相互運用性 -現在使用されているどのオペレーティング システムでも、さまざまなプログラミング タスクのための多くのプラットフォーム サポートを提供しています。 .NET には、その API を利用するためのいくつかの方法が用意されています。 このサポートをまとめて「ネイティブ相互運用性」と呼びます。このセクションでは、.NET のマネージ コードからネイティブの API にアクセスする方法を説明します。 +どのオペレーティング システムにも、システム サービスを提供するアプリケーション プログラミング インターフェイス (API) が含まれています。 .NET には、その API を呼び出すためのいくつかの方法が用意されています。 -ネイティブの相互運用を行う主な方法が、"プラットフォーム呼び出し" (略してP/Invoke) を使用するものです。 .NET Core におけるこのサポートは Linux と Windows プラットフォーム間で使用できます。 また、Windows 限定でネイティブの相互運用を行う方法が "COM 相互運用" です。これは、マネージ コードで [COM コンポーネント](https://msdn.microsoft.com/library/bwa2bx93.aspx)を操作する場合に使用します。 これは、P/Invoke インフラストラクチャ上に構築されますが、動作は少し異なります。 +ネイティブの相互運用を行う主な方法が、"プラットフォーム呼び出し" (略して P/Invoke) を使用するものです。これは、Linux および Windows のプラットフォームに渡ってサポートされています。 Windows 限定でネイティブの相互運用を行う方法が "COM 相互運用" です。これは、マネージ コードで [COM コンポーネント](https://msdn.microsoft.com/library/bwa2bx93.aspx)を操作する場合に使用します。 これは、P/Invoke インフラストラクチャ上に構築されますが、動作は少し異なります。 Java および Objective-C に対する Mono (つまり Xamarin) の相互運用性サポートの多くが同じようにして構築されています。つまり、同じ原則を使用しているということです。 -詳細については、「[Native interoperability](native-interop.md)」(ネイティブ相互運用性) のドキュメントを参照してください。 +詳細については、トピック「[ネイティブ相互運用性](native-interop.md)」を参照してください。 ## アンセーフ コード -CLR の`unsafe` コードによって、ネイティブ メモリにアクセスしたり、ポインターの算術演算を実行したりできるようになります。 この操作は、特定のアルゴリズムおよびシステム相互運用性のために必要です。 アンセーフ コードの使用は強力ですが、システム API との相互運用を行ったり、最も効率的なアルゴリズムを実装したりする必要がなければ、推奨されません。 アンセーフ コードは、環境が異なると同じように実行されない可能性があり、さらにガベージ コレクターとタイプ セーフの利点が得られない場合があります。 可能な限りアンセーフ コードのみに制限し、そのコードを徹底的にテストすることをお勧めします。 +言語サポートに応じて、CLR の `unsafe` コードによって、ネイティブ メモリにアクセスしたりポインターの算術演算を実行したりできるようになります。 この操作は、特定のアルゴリズムおよびシステム相互運用性のために必要です。 アンセーフ コードの使用は強力ですが、システム API との相互運用を行ったり、最も効率的なアルゴリズムを実装したりする必要がなければ、推奨されません。 アンセーフ コードは、環境が異なると同じように実行されない可能性があり、さらにガベージ コレクターとタイプ セーフの利点が得られない場合があります。 可能な限りアンセーフ コードのみに制限し、そのコードを徹底的にテストすることをお勧めします。 -`StringBuilder` クラスから `ToString()` メソッドを変更した例を次に示します。 次のように `unsafe` コードを使用してメモリのチャンクを直接移動して、アルゴリズムを効率的に実装する方法を示しています。 +`StringBuilder` クラスから `ToString()` メソッドを変更した例を次に示します。 次のように `unsafe` コードを使用してメモリのチャンクを直接移動して、アルゴリズムを効率的に実装する方法を示しています。 [!code-csharp[Unsafe](../../samples/csharp/snippets/tour/Unsafe.csx)] -## 次の手順 +## 次のステップ C# の機能については、「[C# のツアー](../csharp/tour-of-csharp/index.md)」をご覧ください。 F# の機能については、「[F# のツアー](../fsharp/tour.md)」をご覧ください。 -独自のコードの記述を開始する場合は、「[作業の開始](get-started.md)」をご覧ください。 +独自のコードの記述を開始する場合は、「[Getting Started](get-started.md)」 (はじめに) をご覧ください。 .NET の重要なコンポーネントについては、「[.NET アーキテクチャ コンポーネント](components.md)」をご覧ください。 diff --git a/docs/standard/using-linq.md b/docs/standard/using-linq.md index 84a1bd8bdfd..005da2c628a 100644 --- a/docs/standard/using-linq.md +++ b/docs/standard/using-linq.md @@ -1,6 +1,6 @@ --- title: "LINQ (統合言語クエリ)" -description: "LINQ (統合言語クエリ)" +description: "LINQ が言語レベルのクエリ機能と、表現力豊かな宣言コードを記述する方法として C# および VB に API を提供する方法を説明します。" keywords: .NET, .NET Core author: cartermp ms.author: wiwagn @@ -10,10 +10,11 @@ ms.prod: .net ms.technology: dotnet-standard ms.devlang: dotnet ms.assetid: c00939e1-59e3-4e61-8fe9-08ad6b3f1295 -translationtype: Human Translation -ms.sourcegitcommit: 90fe68f7f3c4b46502b5d3770b1a2d57c6af748a -ms.openlocfilehash: 6d9c163255939c3732177ecccb373479ab610447 -ms.lasthandoff: 03/02/2017 +ms.translationtype: HT +ms.sourcegitcommit: ef6d1bf9a7153f7adf635d13b4dcfb7647ed2e33 +ms.openlocfilehash: 1478b5dc5844cef0abfea44eba88a12801d32bd4 +ms.contentlocale: ja-jp +ms.lasthandoff: 08/21/2017 --- @@ -29,7 +30,6 @@ LINQ では、言語レベルのクエリ機能と、表現力豊かな宣言コ var linqExperts = from p in programmers where p.IsNewToLINQ select new LINQExpert(p); - ``` 上記を `IEnumerable` API を使用して表した場合の例: @@ -37,7 +37,6 @@ var linqExperts = from p in programmers ```csharp var linqExperts = programmers.Where(p => IsNewToLINQ) .Select(p => new LINQExpert(p)); - ``` ## LINQ は表現力が豊か @@ -53,7 +52,6 @@ foreach (var pet in pets) { petLookup.Add(pet.RFID, pet); } - ``` コードの目的は、新しい `Dictionary` を作成し、ループを使用して追加することではなく、既存のリストを辞書に変換することです。 LINQ ではこの目的が維持されますが、命令型コードでは維持されません。 @@ -62,7 +60,6 @@ foreach (var pet in pets) ```csharp var petLookup = pets.ToDictionary(pet => pet.RFID); - ``` プログラマーとして考えると、目的とコードを同等にするため、LINQ を使用するコードのほうが有益です。 また、コードが簡潔であるという利点があります。 上記のように、コードベースの大部分を 3 分の 1 に減らせることを考えれば、 賢明な選択です。 @@ -81,7 +78,6 @@ public static IEnumerable FindAllElementsWithAttribute(XElement docume where (string)el.Element(attributeName) == value select el; } - ``` コードを記述して XML ドキュメントを手動でスキャンし、このタスクを実行するのはとても難しいことです。 @@ -94,7 +90,6 @@ XML との対話が、LINQ プロバイダーでできる唯一のことでは ```csharp var filteredItems = myItems.Where(item => item.Foo); - ``` 上の構文は下の構文よりもずっと簡潔です。 @@ -103,7 +98,6 @@ var filteredItems = myItems.Where(item => item.Foo); var filteredItems = from item in myItems where item.Foo select item; - ``` API 構文は単に、クエリ構文を実行するより簡潔な方法であるだけでしょうか? @@ -151,7 +145,6 @@ var queryCats = from dog in dogs // Summing then lengths of a set of strings int seed = 0; int sumOfStrings = strings.Aggregate(seed, (s1, s2) => s1.Length + s2.Length); - ``` * リストをまとめてフラット化する場合: @@ -159,7 +152,6 @@ int sumOfStrings = strings.Aggregate(seed, (s1, s2) => s1.Length + s2.Length); ```csharp // Transforms the list of kennels into a list of all their dogs. var allDogsFromKennels = kennels.SelectMany(kennel => kennel.Dogs); - ``` * 2 つのセットの和集合 (カスタム比較子を含む): @@ -195,7 +187,6 @@ public class DogHairLengthComparer : IEqualityComparer // Gets all the short-haired dogs between two different kennels var allShortHairedDogs = kennel1.Dogs.Union(kennel2.Dogs, new DogHairLengthComparer()); - ``` * 2 つのセットの積集合: @@ -204,7 +195,6 @@ var allShortHairedDogs = kennel1.Dogs.Union(kennel2.Dogs, new DogHairLengthCompa // Gets the volunteers who spend share time with two humane societies. var volunteers = humaneSociety1.Volunteers.Intersect(humaneSociety2.Volunteers, new VolunteerTimeComparer()); - ``` * 並べ替え: @@ -214,10 +204,9 @@ var volunteers = humaneSociety1.Volunteers.Intersect(humaneSociety2.Volunteers, var results = DirectionsProcessor.GetDirections(start, end) .OrderBy(direction => direction.HasNoTolls) .ThenBy(direction => direction.EstimatedTime); - ``` -* 最後に、より高度なサンプルを以下に示します。同じ型の&2; つのインスタンスのプロパティ値が等しいかどうかを判断します ([この StackOverflow の投稿](http://stackoverflow.com/a/844855)から借用し、変更したもの)。 +* 最後に、より高度なサンプルを以下に示します。同じ型の 2 つのインスタンスのプロパティ値が等しいかどうかを判断します ([この StackOverflow の投稿](http://stackoverflow.com/a/844855)から借用し、変更したもの)。 ```csharp public static bool PublicInstancePropertiesEqual(this T self, T to, params string[] ignore) where T : class @@ -239,7 +228,6 @@ public static bool PublicInstancePropertiesEqual(this T self, T to, params st return self == to; } - ``` ## PLINQ @@ -260,7 +248,6 @@ public static string GetAllFacebookUserLikesMessage(IEnumerable fa return facebookUsers.AsParallel() .Aggregate(seed, threadAccumulator, threadResultAccumulator, resultSelector); } - ``` このコードでは、必要に応じてシステム スレッドにまたがる `facebookUsers` をパーティション分割し、各スレッドの "いいね!" の数を合計し、スレッドごとの計算結果を合計して、その結果を適切な文字列に投影します。