.NET Framework の新機能What's new in .NET Framework

この記事は、.NET Framework の次のバージョンにおける主な新機能と機能強化の概要を示します。This article summarizes key new features and improvements in the following versions of the .NET Framework:

この記事は、各新機能の包括的な情報を説明するものではありません。また、この内容は変更される可能性があります。This article does not provide comprehensive information about each new feature and is subject to change. .NET Framework の概要については、「.NET Framework の概要」をご覧ください。For general information about the .NET Framework, see Getting Started. サポートされているプラットフォームについては、「.NET Framework システム要件」を参照してください。For supported platforms, see System Requirements. ダウンロード リンクとインストール手順については、「.NET Framework のインストール」を参照してください。For download links and installation instructions, see Installation Guide.


また .NET Framework チームは、NuGet により OOB 機能をリリースすることによって、プラットフォーム サポートを拡張し、新しい機能 (変更できないコレクションや SIMD 対応ベクター型など) を提供しています。The .NET Framework team also releases features out of band with NuGet to expand platform support and to introduce new functionality, such as immutable collections and SIMD-enabled vector types. 詳細については、「その他のクラス ライブラリと API」および.NET Framework と OOB リリースに関するページを参照してください。For more information, see Additional Class Libraries and APIs and The .NET Framework and Out-of-Band Releases. .NET Framework 用の NuGet パッケージの完全な一覧を参照してください。See a complete list of NuGet packages for the .NET Framework.

.NET Framework 4.8 の概要Introducing .NET Framework 4.8

.NET Framework 4.8 は、.NET Framework 4.x の以前のバージョンを基に、多数の新しい修正といくつかの新機能を追加したものであり、これまでと同様に非常に安定した製品です。.NET Framework 4.8 builds on previous versions of the .NET Framework 4.x by adding many new fixes and several new features while remaining a very stable product.

.NET Framework 4.8 のダウンロードとインストールDownloading and installing .NET Framework 4.8

.NET Framework 4.8 は、次の場所からダウンロードできます。You can download .NET Framework 4.8 from the following locations:

.NET Framework 4.8 は、Windows 10、Windows 8.1、Windows 7 SP1、および Windows Server 2008 R2 SP1 以降に相当するサーバー プラットフォームにインストールできます。.NET Framework 4.8 can be installed on Windows 10, Windows 8.1, Windows 7 SP1, and the corresponding server platforms starting with Windows Server 2008 R2 SP1. .NET Framework 4.8 は、Web インストーラーまたはオフライン インストーラーを使用してインストールできます。You can install .NET Framework 4.8 by using either the web installer or the offline installer. ほとんどのユーザーにお勧めする方法は、Web インストーラーの使用です。The recommended way for most users is to use the web installer.

.NET Framework 4.8 Developer Pack をインストールすれば、Visual Studio 2012 以降で、.NET Framework 4.8 をインストール対象に設定できます。You can target .NET Framework 4.8 in Visual Studio 2012 or later by installing the .NET Framework 4.8 Developer Pack.

.NET Framework 4.8 の新機能What's new in .NET Framework 4.8

.NET Framework 4.8 には、次の領域の新機能が導入されています。.NET Framework 4.8 introduces new features in the following areas:

アプリケーションで支援技術のユーザーに適切なエクスペリエンスを提供できるようにするアクセシビリティ機能の向上は、.NET Framework 4.8 でも引き続き大きな注目点です。Improved accessibility, which allows an application to provide an appropriate experience for users of Assistive Technology, continues to be a major focus of .NET Framework 4.8. .NET Framework 4.8 でのアクセシビリティ機能の改善について詳しくは、「.NET Framework のアクセシビリティの新機能」をご覧ください。For information on accessibility improvements in .NET Framework 4.8, see What's new in accessibility in the .NET Framework.

基底クラスBase classes

暗号での FIPS への影響の低下Reduced FIPS impact on Cryptography. 以前のバージョンの .NET Framework では、システムの暗号化ライブラリが "FIPS モード" で構成されていると、SHA256Managed などのマネージド暗号化プロバイダー クラスで CryptographicException がスローされます。In previous versions of the .NET Framework, managed cryptographic provider classes such as SHA256Managed throw a CryptographicException when the system cryptographic libraries are configured in “FIPS mode”. これらの例外がスローされるのは、暗号化プロバイダー クラスのマネージド バージョンは、システムの暗号化ライブラリとは異なり、FIPS (Federal Information Processing Standards) 140-2 の認定を受けていないためです。These exceptions are thrown because the managed versions of the cryptographic provider classes, unlike the system cryptographic libraries, have not undergone FIPS (Federal Information Processing Standards) 140-2 certification. 開発用コンピューターを FIPS モードにしている開発者はほとんどいないため、例外は一般に運用システムでスローされます。Because few developers have their development machines in FIPS mode, the exceptions are commonly thrown in production systems.

.NET Framework 4.8 を対象とするアプリケーションの既定の設定では、この場合に次のマネージド暗号化クラスで CryptographicException がスローされることはなくなりました。By default in applications that target .NET Framework 4.8, the following managed cryptography classes no longer throw a CryptographicException in this case:

代わりに、これらのクラスでは、暗号化操作はシステムの暗号化ライブラリにリダイレクトされます。Instead, these classes redirect cryptographic operations to a system cryptography library. この変更により、開発者環境と運用環境での混乱を招く可能性のある違いは実質的になくなり、ネイティブ コンポーネントとマネージド コンポーネントは同じ暗号化ポリシーの下で動作するようになります。This change effectively removes a potentially confusing difference between developer environments and production environments and makes native components and managed components operate under the same cryptographic policy. これらの例外に依存するアプリケーションでは、AppContext スイッチ Switch.System.Security.Cryptography.UseLegacyFipsThrowtrue に設定することで、以前の動作に戻すことができます。Applications that depend on these exceptions can restore the previous behavior by setting the AppContext switch Switch.System.Security.Cryptography.UseLegacyFipsThrow to true. 詳しくは、「Managed cryptography classes do not throw a CryptographyException in FIPS mode (FIPS モードのマネージド暗号クラスで CryptographyException がスローされない)」をご覧ください。For more information, see Managed cryptography classes do not throw a CryptographyException in FIPS mode.

ZLib の更新バージョンの使用Use of updated version of ZLib

.NET Framework 4.5 以降の clrcompression.dll アセンブリでは、deflate アルゴリズムの実装を提供するため、データ圧縮用のネイティブ外部ライブラリである ZLib が使われています。Starting with .NET Framework 4.5, the clrcompression.dll assembly uses ZLib, a native external library for data compression, in order to provide an implementation for the deflate algorithm. .NET Framework 4.8 の clrcompression.dll は、いくつかの重要な機能強化と修正を含む ZLib バージョン 1.2.11 を使用するように更新されています。The .NET Framework 4.8, clrcompression.dll is updated to use ZLib Version 1.2.11, which includes several key improvements and fixes.

Windows Communication Foundation (WCF)Windows Communication Foundation (WCF)

ServiceHealthBehavior の導入Introduction of ServiceHealthBehavior

正常性エンドポイントは、正常性の状態に基づいてサービスを管理するため、オーケストレーション ツールで広く使用されています。Health endpoints are widely used by orchestration tools to manage services based on their health status. 正常性チェックは、サービスの可用性とパフォーマンスを追跡して通知を提供するため、監視ツールでも使用できます。Health checks can also be used by monitoring tools to track and provide notifications about the availability and performance of a service.

ServiceHealthBehavior は、IServiceBehavior を拡張する WCF サービスの動作です。ServiceHealthBehavior is a WCF service behavior that extends IServiceBehavior. ServiceDescription.Behaviors コレクションに追加すると、サービスの動作は次のようになります。When added to the ServiceDescription.Behaviors collection, a service behavior does the following:

  • HTTP 応答コードでサービスの正常性状態が返されます。Returns service health status with HTTP response codes. HTTP/GET 正常性プローブ要求に対する HTTP 状態コードを、クエリ文字列で指定できます。You can specify in a query string the HTTP status code for a HTTP/GET health probe request.

  • サービスの正常性に関する情報が公開されます。Publishes information about service health. サービスの状態、スロットルの数、容量などのサービス固有の詳細を、?health クエリ文字列を含む HTTP/GET 要求を使用して表示できます。Service-specific details, including service state, throttle counts, and capacity can be displayed by using an HTTP/GET request with the ?health query string. 動作がおかしい WCF サービスのトラブルシューティングを行うときは、このような情報に簡単にアクセスできることが重要です。Ease of access to such information is important when troubleshooting a misbehaving WCF service.

正常性エンドポイントを公開し、WCF サービスの正常性情報を公開するには、2 つの方法があります。There are two ways to expose the health endpoint and publish WCF service health information:

  • コードの使用。Through code. 次に例を示します。For example:

    ServiceHost host = new ServiceHost(typeof(Service1),
                       new Uri("http://contoso:81/Service1"));
    ServiceHealthBehavior healthBehavior =
    healthBehavior ??= new ServiceHealthBehavior();
    Dim host As New ServiceHost(GetType(Service1),
                New Uri("http://contoso:81/Service1"))
    Dim healthBehavior As ServiceHealthBehavior =
       host.Description.Behaviors.Find(Of ServiceHealthBehavior)()
    If healthBehavior Is Nothing Then
       healthBehavior = New ServiceHealthBehavior()
    End If
  • 構成ファイルの使用。By using a configuration file. 次に例を示します。For example:

        <behavior name="DefaultBehavior">
          <serviceHealth httpsGetEnabled="true"/>

OnServiceFailureOnDispatcherFailureOnListenerFailureOnThrottlePercentExceeded などのクエリ パラメーターを使用して、サービスの正常性状態のクエリを実行することができ、各クエリ パラメーターに対して HTTP 応答コードを指定できます。A service's health status can be queried by using query parameters such as OnServiceFailure, OnDispatcherFailure, OnListenerFailure, OnThrottlePercentExceeded), and an HTTP response code can be specified for each query parameter. クエリ パラメーターで HTTP 応答コードを省略すると、503 HTTP 応答コードが既定で使われます。If the HTTP response code is omitted for a query parameter, a 503 HTTP response code is used by default. 次に例を示します。For example:

  • OnServiceFailure: https://contoso:81/Service1?health&OnServiceFailure=450OnServiceFailure: https://contoso:81/Service1?health&OnServiceFailure=450

    ServiceHost.StateCommunicationState.Opened より大きい場合、450 HTTP 応答状態コードが返されます。A 450 HTTP response status code is returned when ServiceHost.State is greater than CommunicationState.Opened. クエリ パラメーターと例:Query parameters and examples:

  • OnDispatcherFailure: https://contoso:81/Service1?health&OnDispatcherFailure=455OnDispatcherFailure: https://contoso:81/Service1?health&OnDispatcherFailure=455

    いずれかのチャネル ディスパッチャーの状態が CommunicationState.Opened より大きい場合、455 HTTP 応答状態コードが返されます。A 455 HTTP response status code is returned when the state of any of the channel dispatchers is greater than CommunicationState.Opened.

  • OnListenerFailure: https://contoso:81/Service1?health&OnListenerFailure=465OnListenerFailure: https://contoso:81/Service1?health&OnListenerFailure=465

    いずれかのチャネル リスナーの状態が CommunicationState.Opened より大きい場合、465 HTTP 応答状態コードが返されます。A 465 HTTP response status code is returned when the state of any of the channel listeners is greater than CommunicationState.Opened.

  • OnThrottlePercentExceeded: https://contoso:81/Service1?health&OnThrottlePercentExceeded= 70:350,95:500OnThrottlePercentExceeded: https://contoso:81/Service1?health&OnThrottlePercentExceeded= 70:350,95:500

    応答をトリガーする割合 {1 – 100} とその HTTP 応答コード {200 – 599} を指定します。Specifies the percentage {1 – 100} that triggers the response and its HTTP response code {200 – 599}. この例では、次のように記述されています。In this example:

    • 割合が 95 より大きい場合、500 HTTP 応答コードが返されます。If the percentage is greater than 95, a 500 HTTP response code is returned.

    • 割合が 70 – 95 の場合は、350 が返されます。If the percentage or between 70 and 95, 350 is returned.

    • それ以外の場合は、200 が返されます。Otherwise, 200 is returned.

サービスの正常性状態は、HTML (https://contoso:81/Service1?health のようなクエリ文字列を指定) または XML (https://contoso:81/Service1?health&Xml のようなクエリ文字列を指定) で表示できます。The service health status can be displayed either in HTML by specifying a query string like https://contoso:81/Service1?health or in XML by specifying a query string like https://contoso:81/Service1?health&Xml. https://contoso:81/Service1?health&NoContent のようなクエリ文字列では、空の HTML ページが返されます。A query string like https://contoso:81/Service1?health&NoContent returns an empty HTML page.

Windows Presentation Foundation (WPF)Windows Presentation Foundation (WPF)

高 DPI の機能強化High DPI enhancements

.NET Framework 4.8 では、WPF でモニターごとの V2 DPI の認識および混合モードの DPI スケーリングのサポートが追加されています。In .NET Framework 4.8, WPF adds support for Per-Monitor V2 DPI Awareness and Mixed-Mode DPI scaling. 高 DPI の開発に関する追加情報については、「High DPI Desktop Application Development on Windows (Windows での高 DPI デスクトップ アプリケーション開発)」をご覧ください。See High DPI Desktop Application Development on Windows for additional information about high DPI development.

.NET framework 4.8 では、混合モードの DPI スケーリングをサポートするプラットフォーム上の高 DPI WPF アプリケーションでのホステッド HWND と Windows フォームの相互運用のためのサポートが向上しています (Windows 10 April 2018 Update 以降)。.NET Framework 4.8 improves support for hosted HWNDs and Windows Forms interoperation in High-DPI WPF applications on platforms that support Mixed-Mode DPI scaling (starting with Windows 10 April 2018 Update). SetThreadDpiHostingBehavior および SetThreadDpiAwarenessContext を呼び出すことによって、ホステッド HWND または Windows フォームのコントロールを混合モードの DPI スケーリングされたウィンドウとして作成すると、それらはモニターごとの V2 WPF アプリケーション内でホストでき、適切にサイズ設定およびスケーリングされます。When hosted HWNDs or Windows Forms controls are created as Mixed-Mode DPI-scaled windows by calling SetThreadDpiHostingBehavior and SetThreadDpiAwarenessContext, they can be hosted in a Per-Monitor V2 WPF application and are sized and scaled appropriately. そのようなホステッド コンテンツは、ネイティブ DPI ではレンダリングされず、代わりにオペレーティング システムによって適切なサイズにスケーリングされます。Such hosted content is not rendered at the native DPI; instead, the operating system scales the hosted content to the appropriate size. モニターごとの v2 DPI 認識モードのサポートにより、高 DPI アプリケーションのネイティブ ウィンドウで WPF コントロールをホストする (つまり、子にする) こともできます。The support for Per-Monitor v2 DPI awareness mode also allows WPF controls to be hosted (i.e., parented) in a native window in a high-DPI application.

混合モードの高 DPI スケーリングのサポートを有効にするには、アプリケーション構成ファイルで次の AppContext スイッチを設定します。To enable support for Mixed-Mode High DPI scaling, you can set the following AppContext switches the application configuration file:

   <AppContextSwitchOverrides value = "Switch.System.Windows.DoNotScaleForDpiChanges=false; Switch.System.Windows.DoNotUsePresentationDpiCapabilityTier2OrGreater=false"/>

共通言語ランタイムCommon language runtime

NET Framework 4.8 のランタイムには、次の変更と強化が含まれます。The runtime in .NET Framework 4.8 includes the following changes and improvements:

JIT コンパイラの機能強化Improvements to the JIT compiler. .NET Framework 4.8 の Just-In-Time (JIT) コンパイラは、.NET Core 2.1 の JIT コンパイラが基になっていいます。The Just-in-time (JIT) compiler in .NET Framework 4.8 is based on the JIT compiler in .NET Core 2.1. .NET Core 2.1 の JIT コンパイラに対して行われた最適化の多くとすべてのバグ修正が、.NET Framework 4.8 の JIT コンパイラに含まれます。Many of the optimizations and all of the bug fixes made to the .NET Core 2.1 JIT compiler are included in the .NET Framework 4.8 JIT compiler.

NGEN の機能強化NGEN improvements. ランタイムでは、ネイティブ イメージ ジェネレーター (NGEN) のイメージに対するメモリ管理が改善され、NGEN イメージからマップされているデータがメモリに常駐しないようになっています。The runtime has improved its memory management for Native Image Generator (NGEN) images so that data mapped from NGEN images are not memory-resident. これにより、実行されるメモリを変更することによって任意のコードを実行しようとする攻撃に利用可能な領域が減ります。This reduces the surface area available to attacks that attempt to execute arbitrary code by modifying memory that will be executed.

すべてのアセンブリに対するマルウェア対策スキャンAntimalware scanning for all assemblies. 以前のバージョンの .NET Framework のランタイムでは、Windows Defender またはサード パーティのマルウェア対策ソフトウェアを使用して、ディスクから読み込まれたすべてのアセンブリがスキャンされます。In previous versions of the .NET Framework, the runtime scans all assemblies loaded from disk using either Windows Defender or third-party antimalware software. しかし、Assembly.Load(Byte[]) メソッドなどの他のソースから読み込まれたアセンブリはスキャンされず、検出されていないマルウェアが含まれる可能性があります。However, assemblies loaded from other sources, such as by the Assembly.Load(Byte[]) method, are not scanned and can potentially contain undetected malware. Windows 10 で実行される .NET Framework 4.8 以降のランタイムでは、Antimalware Scan Interface (AMSI) を実装するマルウェア対策ソリューションによるスキャンがトリガーされます。Starting with .NET Framework 4.8 running on Windows 10, the runtime triggers a scan by antimalware solutions that implement the Antimalware Scan Interface (AMSI).

.NET Framework 4.7.2 の新機能What's new in .NET Framework 4.7.2

.NET Framework 4.7.2 には、次の領域における新機能が含まれています。.NET Framework 4.7.2 includes new features in the following areas:

.NET Framework 4.7.2 では引き続きアクセシビリティ機能の向上が重視されており、それによりアプリケーションでは支援技術のユーザーに適切なエクスペリエンスを提供できます。A continuing focus in .NET Framework 4.7.2 is improved accessibility, which allows an application to provide an appropriate experience for users of Assistive Technology. .NET Framework 4.7.2 でのアクセシビリティ機能の改善について詳しくは、「.NET Framework のアクセシビリティの新機能」をご覧ください。For information on accessibility improvements in .NET Framework 4.7.2, see What's new in accessibility in the .NET Framework.

基底クラスBase classes

.NET Framework 4.7.2 は、大量の暗号化の機能強化、ZIP アーカイブの圧縮解除サポートの向上、および追加のコレクションの API を備えています。.NET Framework 4.7.2 features a large number of cryptographic enhancements, better decompression support for ZIP archives, and additional collection APIs.

RSA.Create および DSA.Create の新しいオーバーロードNew overloads of RSA.Create and DSA.Create

DSA.Create(DSAParameters) および RSA.Create(RSAParameters) メソッドを使うと、新しい DSA または RSA キーをインスタンス化するときにキーのパラメーターを指定できます。The DSA.Create(DSAParameters) and RSA.Create(RSAParameters) methods let you supply key parameters when instantiating a new DSA or RSA key. 次のようなコードを置き換えることができます。They allow you to replace code like the following:

// Before .NET Framework 4.7.2
using (RSA rsa = RSA.Create())
   // Other code to execute using the RSA instance.
' Before .NET Framework 4.7.2
Using rsa = RSA.Create()
   ' Other code to execute using the rsa instance.
End Using

次のようなコードに置き換えます。with code like this:

// Starting with .NET Framework 4.7.2
using (RSA rsa = RSA.Create(rsaParameters))
   // Other code to execute using the rsa instance.
' Starting with .NET Framework 4.7.2
Using rsa = RSA.Create(rsaParameters)
   ' Other code to execute using the rsa instance.
End Using

DSA.Create(Int32) および RSA.Create(Int32) メソッドでは、特定のキー サイズを指定して、新しい DSA または RSA キーを生成することができます。The DSA.Create(Int32) and RSA.Create(Int32) methods let you generate new DSA or RSA keys with a specific key size. 次に例を示します。For example:

using (DSA dsa = DSA.Create(2048))
   // Other code to execute using the dsa instance.
Using dsa = DSA.Create(2048)
   ' Other code to execute using the dsa instance.
End Using

Rfc2898DeriveBytes コンストラクターは、ハッシュ アルゴリズムの名前を受け入れるRfc2898DeriveBytes constructors accept a hash algorithm name

Rfc2898DeriveBytes クラスには、3 つの新しいコンストラクターがあり、キーを派生するときに使用する HMAC アルゴリズムを識別する HashAlgorithmName パラメーターを使用します。The Rfc2898DeriveBytes class has three new constructors with a HashAlgorithmName parameter that identifies the HMAC algorithm to use when deriving keys. SHA-1 を使用する代わりに、開発者は、次の例に示すように SHA-256 などの SHA-2 ベースの HMAC を使用する必要があります。Instead of using SHA-1, developers should use a SHA-2-based HMAC like SHA-256, as shown in the following example:

private static byte[] DeriveKey(string password, out int iterations, out byte[] salt,
                                out HashAlgorithmName algorithm)
   iterations = 100000;
   algorithm = HashAlgorithmName.SHA256;

   const int SaltSize = 32;
   const int DerivedValueSize = 32;

   using (Rfc2898DeriveBytes pbkdf2 = new Rfc2898DeriveBytes(password, SaltSize,
                                                             iterations, algorithm))
      salt = pbkdf2.Salt;
      return pbkdf2.GetBytes(DerivedValueSize);
Private Shared Function DeriveKey(password As String, ByRef iterations As Integer,
                                  ByRef salt AS Byte(), ByRef algorithm As HashAlgorithmName) As Byte()
   iterations = 100000
   algorithm = HashAlgorithmName.SHA256

   Const SaltSize As Integer = 32
   Const  DerivedValueSize As Integer = 32

   Using pbkdf2 = New Rfc2898DeriveBytes(password, SaltSize, iterations, algorithm)
      salt = pbkdf2.Salt
      Return pbkdf2.GetBytes(DerivedValueSize)
   End Using
End Function

一時的なキーのサポートSupport for ephemeral keys

PFX のインポートでは、必要に応じてハード ドライブをバイパスして、メモリから直接秘密キーを読み込むことができます。PFX import can optionally load private keys directly from memory, bypassing the hard drive. 新しい X509KeyStorageFlags.EphemeralKeySet フラグが、X509Certificate2 コンストラクターまたは X509Certificate2.Import メソッドのいずれかのオーバーロードで指定されているときには、一時的なキーとして秘密キーが読み込まれます。 When the new X509KeyStorageFlags.EphemeralKeySet flag is specified in an X509Certificate2 constructor or one of the overloads of the X509Certificate2.Import method, the private keys will be loaded as ephemeral keys. これにより、キーがディスク上に表示されることを防ぎます。This prevents the keys from being visible on the disk. ただし、However:

  • キーは、ディスク上に持続しないので、このフラグで読み込まれた証明書は、X509Store に追加する適切な候補ではありません。Since the keys are not persisted to disk, certificates loaded with this flag are not good candidates to add to an X509Store.

  • この方法で読み込まれたキーは、ほとんどの場合、Windows CNG を使用して読み込まれます。Keys loaded in this manner are almost always loaded via Windows CNG. そのため呼び出し元は、cert.GetRSAPrivateKey() などの拡張メソッドを呼び出すことによって秘密キーにアクセスする必要があります。Therefore, callers must access the private key by calling extension methods, such as cert.GetRSAPrivateKey(). X509Certificate2.PrivateKey プロパティは機能しません。The X509Certificate2.PrivateKey property does not function.

  • 従来の X509Certificate2.PrivateKey プロパティは、証明書では機能しないので、開発者は、一時的なキーに切り替える前に厳格なテストを実行する必要があります。Since the legacy X509Certificate2.PrivateKey property does not work with certificates, developers should perform rigorous testing before switching to ephemeral keys.

PKCS #10 証明書署名要求と X.509 公開キー証明書のプログラムによる作成Programmatic creation of PKCS#10 certification signing requests and X.509 public key certificates

.NET Framework 4.7.2 以降、ワークロードは、証明書署名要求 (CSR) を生成できるようになりました。これにより、証明書要求の生成を既存のツールにステージングすることができます。Starting with .NET Framework 4.7.2, workloads can generate certificate signing requests (CSRs), which allows certificate request generation to be staged into existing tooling. これは、テストのシナリオでよく役に立ちます。This is frequently useful in test scenarios.

詳細およびコードの例については、.NET ブログの「Programmatic creation of PKCS#10 certification signing requests and X.509 public key certificates」(PKCS #10 証明書署名要求と X.509 公開キー証明書のプログラムによる作成) を参照してください。For more information and code examples, see "Programmatic creation of PKCS#10 certification signing requests and X.509 public key certificates" in the .NET Blog.

新しい SignerInfo メンバーNew SignerInfo members

.NET Framework 4.7.2 以降、SignerInfo クラスでは署名についてさらに多くの詳細が公開されます。Starting with .NET Framework 4.7.2, the SignerInfo class exposes more information about the signature. System.Security.Cryptography.Pkcs.SignerInfo.SignatureAlgorithm プロパティの値を取得して、署名者によって使用される署名アルゴリズムを判断することができます。You can retrieve the value of the System.Security.Cryptography.Pkcs.SignerInfo.SignatureAlgorithm property to determine the signature algorithm used by the signer. SignerInfo.GetSignature を呼び出して、この署名者の暗号化署名のコピーを取得することができます。SignerInfo.GetSignature can be called to get a copy of the cryptographic signature for this signer.

CryptoStream が破棄された後にラップされたストリームを開いたままにするLeaving a wrapped stream open after CryptoStream is disposed

.NET Framework 4.7.2 以降、CryptoStream クラスの追加のコンストラクターを使用して、Dispose でラップされたストリームを開いたままにすることができます。Starting with .NET Framework 4.7.2, the CryptoStream class has an additional constructor that allows Dispose to not close the wrapped stream. CryptoStream のインスタンスが破棄された後でラップされたストリームを開いたままにするには、次のように新しい CryptoStream コンストラクターを作成します。 To leave the wrapped stream open after the CryptoStream instance is disposed, call the new CryptoStream constructor as follows:

var cStream = new CryptoStream(stream, transform, mode, leaveOpen: true);
Dim cStream = New CryptoStream(stream, transform, mode, leaveOpen:=true)

DeflateStream の圧縮解除の変更Decompression changes in DeflateStream

.NET Framework 4.7.2 以降では、DeflateStream クラスの圧縮解除操作の実装の際に、既定でネイティブの Windows API を使用するように変更されました。Starting with .NET Framework 4.7.2, the implementation of decompression operations in the DeflateStream class has changed to use native Windows APIs by default. 通常は、これによりパフォーマンスが大幅に改善されます。Typically, this results in a substantial performance improvement.

Windows API を使用した圧縮解除のサポートは .NET Framework 4.7.2 を対象とするアプリケーションで既定で有効です。Support for decompression by using Windows APIs is enabled by default for applications that target .NET Framework 4.7.2. 以前のバージョンの .NET Framework を対象とするアプリケーションが .NET Framework 4.7.2 未満で実行される場合は、次の AppContext スイッチをアプリケーション構成ファイルに追加することで、この動作を選択できます。Applications that target earlier versions of .NET Framework but are running under .NET Framework 4.7.2 can opt into this behavior by adding the following AppContext switch to the application configuration file:

<AppContextSwitchOverrides value="Switch.System.IO.Compression.DoNotUseNativeZipLibraryForDecompression=false" />

追加のコレクション APIAdditional collection APIs

.NET Framework 4.7.2 でいくつかの新しい API が SortedSet<T> および HashSet<T> 型に追加されました。.NET Framework 4.7.2 adds a number of new APIs to the SortedSet<T> and HashSet<T> types. 次の設定があります。These include:

ConcurrentDictionary<TKey,TValue> クラスには、AddOrUpdate および GetOrAdd メソッドの新しいオーバーロードが含まれています、これにより、ディクショナリから値を取得したり、またはそれが見つからない場合にそれを追加したり、値が既に存在する場合に、値をディクショナリに追加するか更新したりすることができます。The ConcurrentDictionary<TKey,TValue> class includes new overloads of the AddOrUpdate and GetOrAdd methods to retrieve a value from the dictionary or to add it if it is not found, and to add a value to the dictionary or to update it if it already exists.

public TValue AddOrUpdate<TArg>(TKey key, Func<TKey, TArg, TValue> addValueFactory, Func<TKey, TValue, TArg, TValue> updateValueFactory, TArg factoryArgument)

public TValue GetOrAdd<TArg>(TKey key, Func<TKey, TArg, TValue> valueFactory, TArg factoryArgument)
Public AddOrUpdate(Of TArg)(key As TKey, addValueFactory As Func(Of TKey, TArg, TValue), updateValueFactory As Func(Of TKey, TValue, TArg, TValue), factoryArgument As TArg) As TValue

Public GetOrAdd(Of TArg)(key As TKey, valueFactory As Func(Of TKey, TArg, TValue), factoryArgument As TArg) As TValue


Web フォームでの依存関係挿入のサポートSupport for dependency injection in Web Forms

依存性挿入 (DI) は、オブジェクトとその依存関係を分離し、依存関係の変更だけを理由としてオブジェクトのコードを変更する必要がないようにします。Dependency injection (DI) decouples objects and their dependencies so that an object's code no longer needs to be changed just because a dependency has changed. .NET Framework 4.7.2 を対象とする ASP.NET アプリケーションを開発するときに次のことができます。When developing ASP.NET applications that target .NET Framework 4.7.2, you can:

同じサイトの cookie のサポートSupport for same-site cookies

SameSite は、ブラウザーがサイト間の要求と共に cookie を送信するのを防ぎます。SameSite prevents a browser from sending a cookie along with a cross-site request. .NET Framework 4.7.2 では、System.Web.SameSiteMode 列挙型のメンバーの値を持つ HttpCookie.SameSite プロパティが追加されました。.NET Framework 4.7.2 adds a HttpCookie.SameSite property whose value is a System.Web.SameSiteMode enumeration member. 値が SameSiteMode.Strict または SameSiteMode.Lax の場合、ASP.NET は SameSite 属性を set-cookie ヘッダーに追加します。If its value is SameSiteMode.Strict or SameSiteMode.Lax, ASP.NET adds the SameSite attribute to the set-cookie header. SameSite のサポートは、HttpCookie オブジェクト、および FormsAuthenticationSystem.Web.SessionState cookie に適用されます。SameSite support applies to HttpCookie objects, as well as to FormsAuthentication and System.Web.SessionState cookies.

HttpCookie オブジェクトの SameSite を次のように設定できます。You can set SameSite for an HttpCookie object as follows:

var c = new HttpCookie("secureCookie", "same origin");
c.SameSite = SameSiteMode.Lax;
Dim c As New HttpCookie("secureCookie", "same origin")
c.SameSite = SameSiteMode.Lax

Web.config ファイルを変更して、アプリケーション レベルで SameSite cookie を構成することもできます。You can also configure SameSite cookies at the application level by modifying the web.config file:

   <httpCookies sameSite="Strict" />

web config ファイルを変更することによって、FormsAuthentication および System.Web.SessionState cookie の SameSite を追加することができます。You can add SameSite for FormsAuthentication and System.Web.SessionState cookies by modifying the web config file:

   <authentication mode="Forms">
      <forms cookieSameSite="Lax">
         <!-- ...   -->
   <authentication />
   <sessionState cookieSameSite="Lax"></sessionState>


HttpClientHandler プロパティの実装Implementation of HttpClientHandler properties

.NET Framework 4.7.1 で 8 個のプロパティが、System.Net.Http.HttpClientHandler クラスに追加されました。.NET Framework 4.7.1 added eight properties to the System.Net.Http.HttpClientHandler class. ただし、2 つは PlatformNotSupportedException をスローしていました。However, two threw a PlatformNotSupportedException. .NET Framework 4.7.2 では、それらのプロパティの実装が提供されるようになりました。.NET Framework 4.7.2 now provides an implementation for these properties. 次のプロパティです。The properties are:


Azure Active Directory のユニバーサル認証と多要素認証のサポートSupport for Azure Active Directory Universal Authentication and Multi-Factor authentication

コンプライアンスとセキュリティのニーズが高まったために、多くのお客様が多要素認証 (MFA) を使用しています。Growing compliance and security demands require that many customers use multi-factor authentication (MFA). さらに、現在のベスト プラクティスでは、接続文字列内に直接ユーザーのパスワードを含めることは推奨されません。In addition, current best practices discourage including user passwords directly in connection strings. これらの変更をサポートするため、.NET Framework 4.7.2 では SQLClient 接続文字列が拡張され、MFA および Azure AD Authentication をサポートするための既存の "Authentication" キーワードに新しい値 "Active Directory Interactive" が追加されています。To support these changes, .NET Framework 4.7.2 extends SQLClient connection strings by adding a new value, "Active Directory Interactive", for the existing "Authentication" keyword to support MFA and Azure AD Authentication. 新しい対話型メソッドでは、ネイティブおよびフェデレーションの Azure AD ユーザーだけでなく Azure AD ゲスト ユーザーをサポートします。The new interactive method supports native and federated Azure AD users as well as Azure AD guest users. このメソッドを使用する場合は、Azure AD によって課される MFA 認証が SQL データベースに対してサポートされます。When this method is used, the MFA authentication imposed by Azure AD is supported for SQL databases. さらに、認証プロセスは、セキュリティのベスト プラクティスに準拠するためにユーザーのパスワードを要求します。In addition, the authentication process requests a user password to adhere to security best practices.

以前のバージョンの .NET Framework では、SQL 接続は、SqlAuthenticationMethod.ActiveDirectoryPasswordSqlAuthenticationMethod.ActiveDirectoryIntegrated のオプションのみをサポートしていました。In previous versions of the .NET Framework, SQL connectivity supported only the SqlAuthenticationMethod.ActiveDirectoryPassword and SqlAuthenticationMethod.ActiveDirectoryIntegrated options. これらはどちらも非対話型の ADAL プロトコル の一部で、MFA はサポートされていません。Both of these are part of the non-interactive ADAL protocol, which does not support MFA. 新しい SqlAuthenticationMethod.ActiveDirectoryInteractive オプションを使用して、SQL 接続は MFA および既存の認証方法 (パスワードや統合認証) をサポートします。これにより、ユーザーが接続文字列でパスワードを永続化せずに、対話形式でパスワードを入力することができます。With the new SqlAuthenticationMethod.ActiveDirectoryInteractive option, SQL connectivity supports MFA as well as existing authentication methods (password and integrated authentication), which allows users to enter user passwords interactively without persisting passwords in the connection string.

詳細および例については、.NET ブログの「SQL -- Azure AD Universal and Multi-factor Authentication Support」(SQL--Azure AD ユニバーサルおよび多要素認証のサポート) を参照してください。For more information and an example, see "SQL -- Azure AD Universal and Multi-factor Authentication Support" in the .NET Blog.

Always Encrypted バージョン 2 のサポートSupport for Always Encrypted version 2

NET Framework 4.7.2 では、エンクレーブ ベースの Always Encrypted のサポートが追加されました。NET Framework 4.7.2 adds supports for enclave-based Always Encrypted. Always Encrypted の元のバージョンは、暗号化キーがクライアントから離れないクライアント側暗号化テクノロジです。The original version of Always Encrypted is a client-side encryption technology in which encryption keys never leave the client. エンクレーブ ベースの Always Encrypted では、クライアントが、オプションで暗号化キーをセキュアなエンクレーブに送信することができます。エンクレーブは、SQL Server の一部と見なされても SQL Server のコードを改ざんできないセキュアなコンピューティング エンティティです。In enclave-based Always Encrypted, the client can optionally send the encryption keys to a secure enclave, which is a secure computational entity that can be considered part of SQL Server but that SQL Server code cannot tamper with. エンクレーブ ベースの Always Encrypted をサポートするために、.NET Framework 4.7.2 では、次の型とメンバーが System.Data.SqlClient 名前空間に追加されています。To support enclave-based Always Encrypted, .NET Framework 4.7.2 adds the following types and members to the System.Data.SqlClient namespace:

アプリケーション構成ファイルで、エンクレーブ プロバイダーの機能を提供する抽象 System.Data.SqlClient.SqlColumnEncryptionEnclaveProvider クラスの完全な実装を指定します。The application configuration file then specifies a concrete implementation of the abstract System.Data.SqlClient.SqlColumnEncryptionEnclaveProvider class that provides the functionality for the enclave provider. 次に例を示します。For example:

    <section name="SqlColumnEncryptionEnclaveProviders" type="System.Data.SqlClient.SqlColumnEncryptionEnclaveProviderConfigurationSection,System.Data,Version=,Culture=neutral,PublicKeyToken=b77a5c561934e089"/> 
      <add name="Azure" type="Microsoft.SqlServer.Management.AlwaysEncrypted.AzureEnclaveProvider,MyApp"/>
      <add name="HGS" type="Microsoft.SqlServer.Management.AlwaysEncrypted.HGSEnclaveProvider,MyApp" />
  </SqlColumnEncryptionEnclaveProviders >

エンクレーブ ベースの Always Encrypted の基本的な流れを示します。The basic flow of enclave-based Always Encrypted is:

  1. ユーザーが、エンクレーブ ベースの Always Encrypted をサポートしていた SQL Server への AlwaysEncrypted 接続を作成します。The user creates an AlwaysEncrypted connection to SQL Server that supported enclave-based Always Encrypted. ドライバーが、構成証明サービスにアクセスし、正しいエンクレーブに接続されていることを確認します。The driver contacts the attestation service to ensure that it is connecting to right enclave.

  2. エンクレーブが証明されると、ドライバーが、SQL Server でホストされているセキュリティで保護されたエンクレーブとのセキュリティで保護されたチャネルを確立します。Once the enclave has been attested, the driver establishes a secure channel with the secure enclave hosted on SQL Server.

  3. ドライバーは、SQL 接続の間にセキュリティで保護されたエンクレーブとクライアントによって承認された暗号化キーを共有します。The driver shares encryption keys authorized by the client with the secure enclave for the duration of the SQL connection.

Windows Presentation FoundationWindows Presentation Foundation

ソースによる ResourceDictionaries の検索Finding ResourceDictionaries by Source

.NET Framework 4.7.2 以降、診断アシスタントでは、特定のソース URI から作成された  ResourceDictionaries を見つけることができます。Starting with .NET Framework 4.7.2, a diagnostic assistant can locate the ResourceDictionaries that have been created from a given source Uri. (この機能は、実稼働アプリケーションではなく診断アシスタントによって使用されます)。Visual Studio の "エディット コンティニュ" 機能などの診断アシスタントでは、ユーザーが、実行中のアプリケーションに変更を適用する目的で ResourceDictionary を編集できます。 (This feature is for use by diagnostic assistants, not by production applications.) A diagnostic assistant such as Visual Studio’s “Edit-and-Continue” facility lets its user edit a ResourceDictionary with the intent that the changes be applied to the running application. これを実現するための 1 つの手順は、実行中のアプリケーションが編集されているディクショナリから作成したすべての ResourceDictionaries を見つけることです。One step in achieving this is finding all the ResourceDictionaries that the running application has created from the dictionary that’s being edited. たとえば、アプリケーションは、コンテンツが特定のソース URI からコピーされる ResourceDictionary を宣言できます。For example, an application can declare a ResourceDictionary whose content is copied from a given source URI:

<ResourceDictionary Source="MyRD.xaml">

MyRD.xaml  の元のマークアップを編集する診断アシスタントでは、ディクショナリを検索する新しい機能を使用できます。A diagnostic assistant that edits the original markup in MyRD.xaml can use the new feature to locate the dictionary. この機能は、新しい静的メソッド ResourceDictionaryDiagnostics.GetResourceDictionariesForSource によって実装されます。 The feature is implemented by a new static method, ResourceDictionaryDiagnostics.GetResourceDictionariesForSource. 診断のアシスタントは、次のコードに示すように、元のマークアップを識別する絶対 URI を使用して新しいメソッドを呼び出します。The diagnostic assistant calls the new method using an absolute Uri that identifies the original markup, as illustrated by the following code:

IEnumerable<ResourceDictionary> dictionaries = ResourceDictionaryDiagnostics.GetResourceDictionariesForSource(new Uri("pack://application:,,,/MyApp;component/MyRD.xaml"));
Dim dictionaries As IEnumerable(Of ResourceDictionary) = ResourceDictionaryDiagnostics.GetResourceDictionariesForSource(New Uri("pack://application:,,,/MyApp;component/MyRD.xaml"))

このメソッドは、 VisualDiagnostics が有効で、かつ ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO  環境変数が設定されている場合を除き、空白の列挙を返します。The method returns an empty enumerable unless VisualDiagnostics is enabled and the ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO environment variable is set.

ResourceDictionary 所有者の検索Finding ResourceDictionary owners

.NET Framework 4.7.2 以降、診断アシスタントでは、特定の ResourceDictionary の所有者を見つけることができます。Starting with .NET Framework 4.7.2, a diagnostic assistant can locate the owners of a given ResourceDictionary. (この機能は、実稼働アプリケーションではなく診断アシスタントによって使用されます。)ResourceDictionary の変更が行われたときに、WPF が、変更の影響を受ける可能性があるすべての DynamicResource の参照を自動的に見つけます。 (The feature is for use by diagnostic assistants and not by production applications.) Whenever a change is made to a ResourceDictionary, WPF automatically finds all DynamicResource references that might be affected by the change.

Visual Studio の "エディット コンティニュ" 機能などの診断アシスタントでは、場合によっては StaticResource 参照を処理するためにこれを拡張する必要があります。A diagnostic assistant such as Visual Studio's "Edit-and-Continue" facility may want to extend this to handle StaticResource references. このプロセスの最初の手順は、ディクショナリの所有者を検索することです。つまり、Resources プロパティがディクショナリを (直接または ResourceDictionary.MergedDictionaries プロパティを使用して間接的に) 参照しているすべてのオブジェクトを見つけます。The first step in this process is to find the owners of the dictionary; that is, to find all the objects whose Resources property refers to the dictionary (either directly, or indirectly via the ResourceDictionary.MergedDictionaries property). System.Windows.Diagnostics.ResourceDictionaryDiagnostics クラスに実装された 3 つの新しい静的メソッドは、Resources プロパティを持つ各基本データ型ごとに 1 つずつあり、次の手順をサポートします。Three new static methods implemented on the System.Windows.Diagnostics.ResourceDictionaryDiagnostics class, one for each of the base types that has a Resources property, support this step:

これらのメソッドは、 VisualDiagnostics が有効で、かつ ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO  環境変数が設定されている場合を除き、空白の列挙を返します。These methods return an empty enumerable unless VisualDiagnostics is enabled and the ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO environment variable is set.

StaticResource 参照の検索Finding StaticResource references

診断アシスタントで、StaticResource 参照が解決されるたびに通知を受け取ることができるようになりました。A diagnostic assistant can now receive a notification whenever a StaticResource reference is resolved. (この機能は、実稼働アプリケーションではなく診断アシスタントによって使用されます。)Visual Studio の "エディット コンティニュ" 機能などの診断アシスタントは、場合によっては ResourceDictionary の値が変更されたときにリソースのすべての使用を更新する必要があります。 (The feature is for use by diagnostic assistants, not by production applications.) A diagnostic assistant such as Visual Studio’s “Edit-and-Continue” facility may want to update all uses of a resource when its value in a ResourceDictionary changes. WPF は、DynamicResource 参照に関してこれを自動的に実行しますが、StaticResource 参照に関しては意図的に実行しません。WPF does this automatically for DynamicResource references, but it intentionally does not do so for StaticResource references. .NET Framework 4.7.2 以降、診断アシスタントは、静的リソースのそれらの使用を検索するのにこれらの通知を使用できます。Starting with .NET Framework 4.7.2, the diagnostic assistant can use these notifications to locate those uses of the static resource.

通知は、新しい ResourceDictionaryDiagnostics.StaticResourceResolved イベントによって実装されます。The notification is implemented by the new ResourceDictionaryDiagnostics.StaticResourceResolved event:

public static event EventHandler<StaticResourceResolvedEventArgs> StaticResourceResolved;
Public Shared Event StaticResourceResolved As EventHandler(Of StaticResourceResolvedEventArgs)

このイベントは、ランタイムが StaticResource 参照を解決するたびに発生します。This event is raised whenever the runtime resolves a StaticResource reference. StaticResourceResolvedEventArgs 引数によって解決が記述され、StaticResource 参照をホストするオブジェクトとプロパティ、および解決に使用される  ResourceDictionary とキーが示されます。 The StaticResourceResolvedEventArgs arguments describe the resolution, and indicate the object and property that host the StaticResource reference and the ResourceDictionary and key used for the resolution:

public class StaticResourceResolvedEventArgs : EventArgs
   public Object TargetObject { get; }

   public Object TargetProperty { get; }

   public ResourceDictionary ResourceDictionary { get; }

   public object ResourceKey { get; }
Public Class StaticResourceResolvedEventArgs : Inherits EventArgs
   Public ReadOnly Property TargetObject As Object
   Public ReadOnly Property TargetProperty As Object
   Public ReadOnly Property ResourceDictionary As ResourceDictionary
   Public ReadOnly Property ResourceKey As Object
End Class

 VisualDiagnostics が有効で、かつ ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO  環境変数が設定されていない限り、イベントを発生しません (その add アクセサーは無視されます)。The event is not raised (and its add accessor is ignored) unless VisualDiagnostics is enabled and the ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO environment variable is set.


ClickOnce を使用して、Windows フォームの HDPI 対応アプリケーション、Windows Presentation Foundation (WPF)、および Visual Studio Tools for Office (VSTO) のすべてを配置できます。HDPI-aware applications for Windows Forms, Windows Presentation Foundation (WPF), and Visual Studio Tools for Office (VSTO) can all be deployed by using ClickOnce. 次のエントリがアプリケーション マニフェストに見つかった場合、.NET Framework 4.7.2 で展開が成功します。If the following entry is found in the application manifest, deployment will succeed under .NET Framework 4.7.2:

   <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>

Windows フォーム アプリケーションの場合、DPI 認識をアプリケーション マニフェストではなくアプリケーション構成ファイルで設定するという以前の回避策は、ClickOnce 展開を成功させるために必要ではなくなりました。For Windows Forms application, the previous workaround of setting DPI awareness in the application configuration file rather than the application manifest is no longer necessary for ClickOnce deployment to succeed.

.NET Framework 4.7.1 の新機能What's new in .NET Framework 4.7.1

.NET Framework 4.7.1 には、次の領域における新機能が含まれています。.NET Framework 4.7.1 includes new features in the following areas:

さらに、.NET Framework 4.7.1 ではアクセシビリティ機能の向上が重視されており、それによりアプリケーションでは支援技術のユーザーに適切なエクスペリエンスを提供できます。In addition, a major focus in .NET Framework 4.7.1 is improved accessibility, which allows an application to provide an appropriate experience for users of Assistive Technology. .NET Framework 4.7.1 でのアクセシビリティ機能の改善について詳しくは、「.NET Framework のアクセシビリティの新機能」をご覧ください。For information on accessibility improvements in .NET Framework 4.7.1, see What's new in accessibility in the .NET Framework.

基底クラスBase classes

.NET Standard 2.0 のサポートSupport for .NET Standard 2.0

.NET Standard は、そのバージョンの標準をサポートする各 .NET 実装で使用する必要がある API のセットを定義します。.NET Standard defines a set of APIs that must be available on each .NET implementation that supports that version of the standard. .NET Framework 4.7.1 では、.NET Standard 2.0 が完全にサポートされており、.NET Standard 2.0 で定義されていて .NET Framework 4.6.1、4.6.2、および 4.7 にはなかった約 200 の API が追加されています。.NET Framework 4.7.1 fully supports .NET Standard 2.0 and adds about 200 APIs that are defined in .NET Standard 2.0 and are missing from .NET Framework 4.6.1, 4.6.2, and 4.7. (これらのバージョンの .NET Framework は、追加の .NET Standard サポート ファイルもターゲット システムにも展開されている場合にのみ .NET Standard 2.0 をサポートします)。詳細については、「.NET Framework 4.7.1 Runtime and Compiler Features」(.NET Framework 4.7.1 ランタイムとコンパイラの機能) ブログ投稿の「BCL - .NET Standard 2.0 Support」(BCL - .NET Standard 2.0 のサポート) を参照してください。(Note that these versions of the .NET Framework support .NET Standard 2.0 only if additional .NET Standard support files are also deployed on the target system.) For more information, see "BCL - .NET Standard 2.0 Support" in the .NET Framework 4.7.1 Runtime and Compiler Features blog post.

構成ビルダーのサポートSupport for configuration builders

構成ビルダーを使用して、開発者が、実行時にアプリケーションの構成設定を動的に注入およびビルドすることができます。Configuration builders allow developers to inject and build configuration settings for applications dynamically at run time. カスタム構成ビルダーを使用して、構成セクションの既存のデータを変更したり、最初から完全に構成セクション全体をビルドしたりすることができます。Custom configuration builders can be used to modify existing data in a configuration section or to build a configuration section entirely from scratch. 構成ビルダーを使用しない場合は、構成ファイルは静的であり、それらの設定はアプリケーションが起動されるしばらく前に定義されます。Without configuration builders, .config files are static, and their settings are defined some time before an application is launched.

カスタム構成ビルダーを作成するには、抽象 ConfigurationBuilder クラスからビルダーを派生させ、その ConfigurationBuilder.ProcessConfigurationSectionConfigurationBuilder.ProcessRawXml をオーバーライドします。To create a custom configuration builder, you derive your builder from the abstract ConfigurationBuilder class and override its ConfigurationBuilder.ProcessConfigurationSection and ConfigurationBuilder.ProcessRawXml. また、.config ファイルでもビルダーを定義します。You also define your builders in your .config file. 詳細については、「.NET Framework 4.7.1 ASP.NET and Configuration Features 」(.NET Framework 4.7.1 ASP.NET と構成機能) ブログ投稿の「Configuration Builders」(構成ビルダー) セクションを参照してください。For more information, see the "Configuration Builders" section in the .NET Framework 4.7.1 ASP.NET and Configuration Features blog post.

実行時の機能の検出Run-time feature detection

System.Runtime.CompilerServices.RuntimeFeature クラスは、コンパイル時または実行時に特定の .NET の実装上で事前に定義された機能がサポートされているかどうかを判断するためのメカニズムを提供します。The System.Runtime.CompilerServices.RuntimeFeature class provides a mechanism for determine whether a predefined feature is supported on a given .NET implementation at compile time or run time. コンパイラは、コンパイル時に、指定されたフィールドが存在するかどうかを確認し、その機能がサポートされているかどうかを判断します。サポートされている場合は、その機能を利用するコードを生成できます。At compile time, a compiler can check whether a specified field exists to determine whether the feature is supported; if so, it can emit code that takes advantage of that feature. 実行時に、アプリケーションは、コードを生成する前に RuntimeFeature.IsSupported メソッドを呼び出すことができます。At run time, an application can call the RuntimeFeature.IsSupported method before emitting code at runtime. 詳細については、「Add helper method to describe features supported by the runtime」(ランタイムでサポートされる機能を記述するヘルパー メソッドを追加する) を参照してください。For more information, see Add helper method to describe features supported by the runtime.

値のタプル型はシリアル化できるValue tuple types are serializable

.NET Framework 4.7.1 以降、System.ValueTuple および関連するジェネリック型は、Serializable としてマークされ、バイナリのシリアル化ができるようになりました。Starting with .NET Framework 4.7.1, System.ValueTuple and its associated generic types are marked as Serializable, which allows binary serialization. これにより、Tuple<T1,T2,T3>Tuple<T1,T2,T3,T4> などのタプル型を簡単に値のタプル型に移行できます。This should make migrating Tuple types, such as Tuple<T1,T2,T3> and Tuple<T1,T2,T3,T4>, to value tuple types easier. 詳細については、「.NET Framework 4.7.1 Runtime and Compiler Features」(.NET Framework 4.7.1 ランタイムとコンパイラの機能) ブログ投稿の「Compiler -- ValueTuple is Serializable」(コンパイラ -- 値タプルはシリアル化できる) を参照してください。For more information, see "Compiler -- ValueTuple is Serializable" in the .NET Framework 4.7.1 Runtime and Compiler Features blog post.

読み取り専用の参照のサポートSupport for read-only references

.NET Framework 4.7.1 では、System.Runtime.CompilerServices.IsReadOnlyAttribute が追加されました。.NET Framework 4.7.1 adds the System.Runtime.CompilerServices.IsReadOnlyAttribute. この属性は、読み取り専用の ref 戻り値型またはパラメーターを持つメンバーをマークする言語コンパイラで使用します。This attribute is used by language compilers to mark members that have read-only ref return types or parameters. 詳細については、「.NET Framework 4.7.1 Runtime and Compiler Features」(.NET Framework 4.7.1 ランタイムとコンパイラの機能) ブログ投稿の「Compiler - Support for ReadOnlyReferences」(コンパイラ - ReadOnlyReferences のサポート) を参照してください。For more information, see "Compiler -- Support for ReadOnlyReferences" in the .NET Framework 4.7.1 Runtime and Compiler Features blog post. 参照戻り値の詳細については、参照戻り値と参照ローカル変数 (C# Guide)および参照戻り値 (Visual Basic)に関するページを参照してください。For information on ref return values, see Ref return values and ref locals (C# Guide) and Ref return values (Visual Basic).

共通言語ランタイム (CLR)Common language runtime (CLR)

ガベージ コレクションのパフォーマンス改善Garbage collection performance improvements

.NET Framework 4.7.1 でのガベージ コレクション (GC) に対する変更により、特に大きなオブジェクト ヒープ (LOH) の割り当ての場合に全体的なパフォーマンスが向上します。Changes to garbage collection (GC) in .NET Framework 4.7.1 improve overall performance, especially for large object heap (LOH) allocations. .NET Framework 4.7.1 では、小さなオブジェクト ヒープ (SOH) と LOH の割り当てに個別のロックが使用されます。これにより、バックグラウンド GC で SOH をスイープするときに、LOH を割り当てることができます。In .NET Framework 4.7.1, separate locks are used for small object heap (SOH) and LOH allocations, which allows LOH allocations to occur when background GC is sweeping the SOH. その結果、多数の LOH の割り当てを行うアプリケーションでは、割り当てのロックの競合が減少し、パフォーマンスが向上します。As a result, applications that make a large number of LOH allocations should see a reduction in allocation lock contention and improved performance. 詳細については、「.NET Framework 4.7.1 Runtime and Compiler Features」(.NET Framework 4.7.1 ランタイムとコンパイラの機能) ブログ投稿の「Runtime -- GC Performance Improvements」(ランタイム - GC のパフォーマンスの向上) セクションを参照してください。For more information, see the "Runtime -- GC Performance Improvements" section in the .NET Framework 4.7.1 Runtime and Compiler Features blog post.


Message.HashAlgorithm 用の SHA-2 のサポートSHA-2 support for Message.HashAlgorithm

.NET Framework 4.7 およびそれ以前のバージョンの Message.HashAlgorithm プロパティでは、値 HashAlgorithm.Md5 および HashAlgorithm.Sha のみがサポートされていました。In .NET Framework 4.7 and earlier versions, the Message.HashAlgorithm property supported values of HashAlgorithm.Md5 and HashAlgorithm.Sha only. .NET Framework 4.7.1 以降では、HashAlgorithm.Sha256HashAlgorithm.Sha384HashAlgorithm.Sha512 もサポートされます。Starting with .NET Framework 4.7.1, HashAlgorithm.Sha256, HashAlgorithm.Sha384, and HashAlgorithm.Sha512 are also supported. Message インスタンス自体は、ハッシュは行わず、MSMQ に値を渡すだけですなので、この値が実際に使用されるかどうかは MSMQ によって異なります。Whether this value is actually used depends on MSMQ, since the Message instance itself does no hashing but simply passes on values to MSMQ. 詳細については、「.NET Framework 4.7.1 ASP.NET and Configuration Features 」(.NET Framework 4.7.1 ASP.NET と構成機能) ブログ投稿の「SHA-2 support for Message.HashAlgorithm」(Message.HashAlgorithm 用の SHA-2 のサポート) セクションを参照してください。For more information, see the "SHA-2 support for Message.HashAlgorithm" section in the .NET Framework 4.7.1 ASP.NET and Configuration features blog post.


ASP.NET アプリケーションの実行ステップExecution steps in ASP.NET applications

ASP.NET は、23 のイベントを含む定義済みのパイプラインで要求を処理します。ASP.NET processes requests in a predefined pipeline that includes 23 events. ASP.NET は、実行ステップとして、各イベント ハンドラーを実行します。ASP.NET executes each event handler as an execution step. .NET Framework 4.7 までの ASP.NET のバージョンでは、ASP.NET は、ネイティブ スレッドとマネージド スレッドの切り替えのために、実行コンテキストをフローすることはできません。In versions of ASP.NET up to .NET Framework 4.7, ASP.NET can't flow the execution context due to switching between native and managed threads. 代わりに、ASP.NET は、HttpContext のみを選択的にフローします。Instead, ASP.NET selectively flows only the HttpContext. .NET Framework 4.7.1 以降、HttpApplication.OnExecuteRequestStep(Action<HttpContextBase,Action>) メソッドでは、モジュールがアンビエント データを復元することもできます。Starting with .NET Framework 4.7.1, the HttpApplication.OnExecuteRequestStep(Action<HttpContextBase,Action>) method also allows modules to restore ambient data. この機能は、アプリケーションの実行フローを考慮する、トレース、プロファイリング、診断、トランザクションなどに関連するライブラリを対象とします。This feature is targeted at libraries concerned with tracing, profiling, diagnostics, or transactions, for example, that care about the execution flow of the application. 詳細については、「.NET Framework 4.7.1 ASP.NET and Configuration Features 」(.NET Framework 4.7.1 ASP.NET と構成機能) ブログ投稿の「ASP.NET Execution Step Feature」(ASP.NET 実行ステップの機能) を参照してください。For more information, see the "ASP.NET Execution Step Feature" in the .NET Framework 4.7.1 ASP.NET and Configuration Features blog post.

ASP.NET HttpCookie 解析ASP.NET HttpCookie parsing

.NET Framework 4.7.1 には、新しいメソッド HttpCookie.TryParse が含まれています。これは、文字列から HttpCookie オブジェクトを作成し、有効期限日やパスなどの cookie の値を正確に割り当てるための標準化された方法を提供します。.NET Framework 4.7.1 includes a new method, HttpCookie.TryParse, that provides a standardized way to create an HttpCookie object from a string and accurately assign cookie values such as expiration date and path. 詳細については、「.NET Framework 4.7.1 ASP.NET and Configuration Features 」(.NET Framework 4.7.1 ASP.NET と構成機能) ブログ投稿の「ASP.NET HttpCookie parsing」(ASP.NET HttpCookie の解析) を参照してください。For more information, see "ASP.NET HttpCookie parsing" in the .NET Framework 4.7.1 ASP.NET and Configuration Features blog post.

ASP.NET フォーム認証資格情報の SHA-2 ハッシュ オプションSHA-2 hash options for ASP.NET forms authentication credentials

.NET Framework 4.7 およびそれ以前のバージョンの ASP.NET では、開発者は、MD5 または SHA1 を使用して、ユーザーの資格情報とハッシュされたパスワードを構成ファイルに格納できました。In .NET Framework 4.7 and earlier versions, ASP.NET allowed developers to store user credentials with hashed passwords in configuration files using either MD5 or SHA1. .NET Framework 4.7.1 以降の ASP.NET では、SHA256、SHA384、SHA512 などの新しい安全な SHA-2 ハッシュ オプションもサポートされるようになっています。Starting with .NET Framework 4.7.1, ASP.NET also supports new secure SHA-2 hash options such as SHA256, SHA384, and SHA512. SHA1 は既定のまま残り、Web 構成ファイルで既定以外のハッシュ アルゴリズムを定義することができます。SHA1 remains the default, and a non-default hash algorithm can be defined in the web configuration file. 次に例を示します。For example:

    <authentication mode="Forms">
        <forms loginUrl="~/login.aspx">
          <credentials passwordFormat="SHA512">
            <user name="jdoe" password="6D003E98EA1C7F04ABF8FCB375388907B7F3EE06F278DB966BE960E7CBBD103DF30CA6D61F7E7FD981B2E4E3A64D43C836A4BEDCA165C33B163E6BCDC538A664" />

.NET Framework 4.7 の新機能What's new in .NET Framework 4.7

.NET Framework 4.7 には、次の領域における新機能が含まれています。.NET Framework 4.7 includes new features in the following areas:

.NET Framework 4.7 に追加された新しい API の一覧については、GitHub で .NET Framework 4.7 API の変更点に関するページをご覧ください。For a list of new APIs added to .NET Framework 4.7, see .NET Framework 4.7 API Changes on GitHub. .NET Framework 4.7 における機能の改善とバグ修正の一覧については、GitHub で「.NET Framework 4.7 List of Changes (.NET Framework 4.7 の変更点の一覧)」を参照してください。For a list of feature improvements and bug fixes in .NET Framework 4.7, see .NET Framework 4.7 List of Changes on GitHub. 詳細については、.NET ブログの「.NET Framework 4.7 の発表」を参照してください。For more information, see Announcing the .NET Framework 4.7 in the .NET blog.

基底クラスBase classes

.NET Framework 4.7 では、DataContractJsonSerializer によるシリアル化が改善されています。.NET Framework 4.7 improves serialization by the DataContractJsonSerializer:

楕円曲線暗号 (ECC) による機能強化*Enhanced functionality with Elliptic Curve Cryptography (ECC)*

.NET Framework 4.7 では、ImportParameters(ECParameters) メソッドが ECDsa クラスと ECDiffieHellman クラスに追加され、既に確立されたキーをオブジェクトで表すことができるようになりました。In .NET Framework 4.7, ImportParameters(ECParameters) methods were added to the ECDsa and ECDiffieHellman classes to allow for an object to represent an already-established key. 明示的な曲線パラメーターを使ってキーをエクスポートするための ExportParameters(Boolean) メソッドも追加されました。An ExportParameters(Boolean) method was also added for exporting the key using explicit curve parameters.

また、.NET Framework 4.7 では、その他の曲線 (Brainpool 曲線スイートなど) のサポートと、新しい Create および Create ファクトリ メソッドによる作成しやすい事前定義も追加されました。.NET Framework 4.7 also adds support for additional curves (including the Brainpool curve suite), and has added predefined definitions for ease-of-creation through the new Create and Create factory methods.

GitHub で .NET Framework 4.7 の暗号化の向上の例を見ることができます。You can see an example of .NET Framework 4.7 cryptography improvements on GitHub.

DataContractJsonSerializer による制御文字のサポートの向上Better support for control characters by the DataContractJsonSerializer

.NET Framework 4.7 の DataContractJsonSerializer では、ECMAScript 6 標準に準拠して制御文字がシリアル化されます。In .NET Framework 4.7, the DataContractJsonSerializer serializes control characters in conformity with the ECMAScript 6 standard. この動作は、.NET Framework 4.7 を対象とするアプリケーションでは既定で有効になり、.NET Framework 4.7 で実行していても対象が以前のバージョンの .NET Framework であるアプリケーションの場合はオプトイン機能です。This behavior is enabled by default for applications that target .NET Framework 4.7, and is an opt-in feature for applications that are running under .NET Framework 4.7 but target a previous version of the .NET Framework. 詳細については、「.NET Framework 4.7 における再ターゲットの変更点」をご覧ください。For more information, see Retargeting Changes in the .NET Framework 4.7.


.NET Framework 4.7 では、次のネットワーク関連機能が追加されています。.NET Framework 4.7 adds the following network-related feature:

TLS プロトコルの既定のオペレーティング システム サポート*Default operating system support for TLS protocols*

System.Net.Security.SslStream および HTTP、FTP、SMTP などの上位スタック コンポーネントによって使われる TLS スタックにより、開発者はオペレーティング システムによってサポートされる既定の TLS プロトコルを使うことができます。The TLS stack, which is used by System.Net.Security.SslStream and up-stack components such as HTTP, FTP, and SMTP, allows developers to use the default TLS protocols supported by the operating system. TLS バージョンをハード コーディングする必要はなくなりました。Developers need no longer hard-code a TLS version.


.NET Framework 4.7 の ASP.NET には、次の新機能が含まれます。In .NET Framework 4.7, ASP.NET includes the following new features:

オブジェクト キャッシュの拡張性Object Cache Extensibility

.NET Framework 4.7 以降では、ASP.NET で追加された新しい API セットを使うことで、開発者は、メモリ内オブジェクト キャッシュとメモリ監視に関する既定の ASP.NET の実装を置き換えることができます。Starting with .NET Framework 4.7, ASP.NET adds a new set of APIs that allow developers to replace the default ASP.NET implementations for in-memory object caching and memory monitoring. ASP.NET の実装が適切ではない場合、次の 3 つのコンポーネントを置き換えることができるようになりました。Developers can now replace any of the following three components if the ASP.NET implementation is not adequate:

  • オブジェクト キャッシュ ストアObject Cache Store. 新しいキャッシュ プロバイダー構成セクションを使うことで、開発者は、新しい ICacheStoreProvider インターフェイスを使って、ASP.NET アプリケーション用のオブジェクト キャッシュの新しい実装をプラグインできます。By using the new cache providers configuration section, developers can plug in new implementations of an object cache for an ASP.NET application by using the new ICacheStoreProvider interface.

  • メモリ監視Memory monitoring. ASP.NET の既定のメモリ モニターは、アプリケーションがプロセスに構成されているプライベート バイト制限に近づくと、またはコンピューターの使用可能な合計物理 RAM が低下すると、アプリケーションに通知します。The default memory monitor in ASP.NET notifies applications when they are running close to the configured private bytes limit for the process, or when the machine is low on total available physical RAM. これらの制限に近づくと、通知が発生します。When these limits are near, notifications are fired. 一部のアプリケーションでは、通知の発生が構成されている制限に近すぎるため、有効な対応を取れません。For some applications, notifications are fired too close to the configured limits to allow for useful reactions. 開発者は、ApplicationMonitors.MemoryMonitor プロパティを使用して既定値を置き換える独自のメモリ モニターを作成できるようになりました。Developers can now write their own memory monitors to replace the default by using the ApplicationMonitors.MemoryMonitor property.

  • メモリ制限への対応Memory Limit Reactions. 既定では、プライベート バイト プロセス制限が近づくと、ASP.NET はオブジェクト キャッシュの削減を試み、GC.Collect を定期的に呼び出します。By default, ASP.NET attempts to trim the object cache and periodically call GC.Collect when the private byte process limit is near. アプリケーションによっては、GC.Collect の呼び出し頻度またはトリミングされるキャッシュ量が非効率になります。For some applications, the frequency of calls to GC.Collect or the amount of cache that is trimmed are inefficient. 開発者は、アプリケーションのメモリ モニターに IObserver の実装をサブスクライブすることにより、既定の動作を置換または補完できます。Developers can now replace or supplement the default behavior by subscribing IObserver implementations to the application's memory monitor.

Windows Communication Foundation (WCF)Windows Communication Foundation (WCF)

Windows Communication Foundation (WCF) では以下の機能が追加または変更されました。Windows Communication Foundation (WCF) adds the following features and changes:

既定のメッセージ セキュリティ設定を TLS1.1 または TLS1.2 に構成する機能。Ability to configure the default message security settings to TLS 1.1 or TLS 1.2

.NET Framework 4.7 以降の WCF では、既定のメッセージ セキュリティ プロトコルとして、SSL 3.0 と TSL 1.0 に加えて、TSL 1.1 または TLS 1.2 を構成できます。Starting with .NET Framework 4.7, WCF allows you to configure TSL 1.1 or TLS 1.2 in addition to SSL 3.0 and TSL 1.0 as the default message security protocol. これはオプトイン設定です。有効にするには、アプリケーション構成ファイルに次のエントリを追加する必要があります。This is an opt-in setting; to enable it, you must add the following entry to your application configuration file:

   <AppContextSwitchOverrides value="Switch.System.ServiceModel.DisableUsingServicePointManagerSecurityProtocols=false;Switch.System.Net.DontEnableSchUseStrongCrypto=false" />

WCF アプリケーションと WCF シリアル化の信頼性の向上Improved reliability of WCF applications and WCF serialization

WCF に競合状態を除去する複数のコード変更が追加され、シリアル化オプションの信頼性とパフォーマンスが向上しています。WCF includes a number of code changes that eliminate race conditions, thereby improving performance and the reliability of serialization options. 次の設定があります。These include:

  • SocketConnection.BeginRead および SocketConnection.Read の呼び出しでの非同期コードと同期コードの併用のサポートの向上。Better support for mixing asynchronous and synchronous code in calls to SocketConnection.BeginRead and SocketConnection.Read.
  • SharedConnectionListener および DuplexChannelBinder で接続を中止するときの信頼性の向上。Improved reliability when aborting a connection with SharedConnectionListener and DuplexChannelBinder.
  • FormatterServices.GetSerializableMembers(Type) メソッドの呼び出し時のシリアル化操作の信頼性を向上しました。Improved reliability of serialization operations when calling the FormatterServices.GetSerializableMembers(Type) method.
  • ChannelSynchronizer.RemoveWaiter メソッドを呼び出して待機を削除するときの信頼性の向上。Improved reliability when removing a waiter by calling the ChannelSynchronizer.RemoveWaiter method.

Windows フォームWindows Forms

.NET Framework 4.7 では、Windows フォームによる高 DPI モニターのサポートが向上しました。In .NET Framework 4.7, Windows Forms improves support for high DPI monitors.

高 DPI のサポートHigh DPI support

.NET Framework 4.7 を対象とするアプリケーションでは、Windows フォーム アプリケーションに対して高 DPI および動的 DPI がサポートされるようになっています。Starting with applications that target .NET Framework 4.7, the .NET Framework features high DPI and dynamic DPI support for Windows Forms applications. 高 DPI のサポートにより、フォームのレイアウトと外観および高 DPI モニターでのコントロールが向上します。High DPI support improves the layout and appearance of forms and controls on high DPI monitors. 動的 DPI は、ユーザーが実行中のアプリケーションの DPI または表示倍率を変更すると、フォームのレイアウトと外観およびコントロールを変更します。Dynamic DPI changes the layout and appearance of forms and controls when the user changes the DPI or display scale factor of a running application.

高 DPI のサポートはオプトイン機能であり、アプリケーション構成ファイルの <System.Windows.Forms.ConfigurationSection> セクションを定義することで構成します。High DPI support is an opt-in feature that you configure by defining a <System.Windows.Forms.ConfigurationSection> section in your application configuration file. Windows フォーム アプリケーションへの高 DPI サポートおよび動的 DPI サポート追加の詳細については、「Windows フォームの高 DPI サポート」をご覧ください。For more information on adding high DPI support and dynamic DPI support to your Windows Forms application, see High DPI Support in Windows Forms.

Windows Presentation Foundation (WPF)Windows Presentation Foundation (WPF)

.NET Framework 4.7 では、WPF の機能が次のように強化されています。In .NET Framework 4.7, WPF includes the following enhancements:

Windows WM_POINTER メッセージに基づくタッチ/スタイラス スタックのサポートSupport for a touch/stylus stack based on Windows WM_POINTER messages

Windows Ink Services Platform (WISP) の代わりに WM_POINTER メッセージに基づいてタッチ/スタイラス スタックを使うオプションが追加されました。You now have the option of using a touch/stylus stack based on WM_POINTER messages instead of the Windows Ink Services Platform (WISP). これは、.NET Framework のオプトイン機能です。This is an opt-in feature in the .NET Framework. 詳細については、「.NET Framework 4.7 における再ターゲットの変更点」をご覧ください。For more information, see Retargeting Changes in the .NET Framework 4.7.

WPF 印刷 API の新しい実装New implementation for WPF printing APIs

System.Printing.PrintQueue クラスの WPF 印刷 API は、非推奨になった XPS 印刷 API ではなく Windows ドキュメント印刷パッケージ API を呼び出します。WPF's printing APIs in the System.Printing.PrintQueue class call the Windows Print Document Package API instead of the deprecated XPS Print API. アプリケーションの互換性に対するこの変更の影響については、「.NET Framework 4.7 における再ターゲットの変更点」をご覧ください。For the impact of this change on application compatibility, see Retargeting Changes in the .NET Framework 4.7.

.NET Framework 4.6.2 の新機能What's new in .NET Framework 4.6.2

.NET Framework 4.6.2 には、次の領域における新機能が含まれています。The .NET Framework 4.6.2 includes new features in the following areas:

.NET Framework 4.6.2 に追加された新しい API の一覧については、GitHub で「.NET Framework 4.6.2 API Changes (.NET Framework 4.6.2 API の変更点)」をご覧ください。For a list of new APIs added to .NET Framework 4.6.2, see .NET Framework 4.6.2 API Changes on GitHub. .NET Framework 4.6.2 における機能の改善とバグ修正の一覧については、GitHub で「.NET Framework 4.6.2 List of Changes (.NET Framework 4.6.2 の変更点の一覧)」を参照してください。For a list of feature improvements and bug fixes in .NET Framework 4.6.2, see .NET Framework 4.6.2 List of Changes on GitHub. 詳細については、.NET ブログの「.NET Framework 4.6.2 の発表」を参照してください。For more information, see Announcing .NET Framework 4.6.2 in the .NET blog.


.NET Framework 4.6.2 では、ASP.NET の機能が次のように強化されています。In the .NET Framework 4.6.2, ASP.NET includes the following enhancements:

データ注釈検証コントロールのローカライズされたエラー メッセージのサポート強化Improved support for localized error messages in data annotation validators

データ注釈検証コントロールを使用して、1 つ以上の属性をクラス プロパティに追加して検証を行うことができます。Data annotation validators enable you to perform validation by adding one or more attributes to a class property. 属性の ValidationAttribute.ErrorMessage 要素は、検証が失敗した場合にエラー メッセージのテキストを定義します。The attribute's ValidationAttribute.ErrorMessage element defines the text of the error message if validation fails. .NET Framework 4.6.2 以降では、ASP.NET でエラー メッセージを簡単にローカライズできます。Starting with the .NET Framework 4.6.2, ASP.NET makes it easy to localize error messages. エラー メッセージは次のような場合にローカライズされます。Error messages will be localized if:

  1. ValidationAttribute.ErrorMessage が検証属性で指定されている。The ValidationAttribute.ErrorMessage is provided in the validation attribute.

  2. リソース ファイルが App_LocalResources フォルダーに格納されている。The resource file is stored in the App_LocalResources folder.

  3. ローカライズされたリソース ファイル名の形式が DataAnnotation.Localization.{名前}.resx (この名前は、languageCode-country/regionCode または languageCode 形式のカルチャ名) である。The name of the localized resources file has the form DataAnnotation.Localization.{name}.resx, where name is a culture name in the format languageCode-country/regionCode or languageCode.

  4. リソースのキー名が ValidationAttribute.ErrorMessage 属性に割り当てられている文字列で、その値がローカライズされたエラー メッセージである。The key name of the resource is the string assigned to the ValidationAttribute.ErrorMessage attribute, and its value is the localized error message.

たとえば、次のデータ注釈属性では、無効な評価の場合に表示する、既定のカルチャのエラー メッセージを定義します。For example, the following data annotation attribute defines the default culture's error message for an invalid rating.

public class RatingInfo
   [Required(ErrorMessage = "The rating must be between 1 and 10.")]
   [Display(Name = "Your Rating")]
   public int Rating { get; set; }
Public Class RatingInfo
   <Required(ErrorMessage = "The rating must be between 1 and 10.")>
   <Display(Name = "Your Rating")>
   Public Property Rating As Integer = 1
End Class

キーがエラー メッセージ文字列であり、その値がローカライズされたエラー メッセージであるようにリソース ファイル DataAnnotation.Localization.fr.resx を作成します。You can then create a resource file, DataAnnotation.Localization.fr.resx, whose key is the error message string and whose value is the localized error message. ファイルは App.LocalResources フォルダーになければいけません。The file must be found in the App.LocalResources folder. たとえば下記は、キーとその値で、値はローカライズされたフランス語 (fr) のエラー メッセージです。For example, the following is the key and its value in a localized French (fr) language error message:

名前Name [値]Value
評価は、1 から 10 の範囲である必要があります。The rating must be between 1 and 10. La note doit être comprise entre 1 et 10.La note doit être comprise entre 1 et 10.

また、データ注釈ローカリゼーションを拡張することができます。In addition, data annotation localization is extensible. 開発者は、IStringLocalizerProvider インターフェイスを実装してリソース ファイル以外の場所にローカリゼーション文字列を格納することで、独自の文字列ローカライザー プロバイダーにプラグインできます。Developers can plug in their own string localizer provider by implementing the IStringLocalizerProvider interface to store localization string somewhere other than in a resource file.

セッション状態ストア プロバイダーでの非同期サポートAsync support with session-state store providers

ASP.NET では、セッション状態ストア プロバイダーでタスクを返すメソッドを使用できるようになりました。これにより、ASP.NET アプリで非同期のスケーラビリティのメリットが得られます。ASP.NET now allows task-returning methods to be used with session-state store providers, thereby allowing ASP.NET apps to get the scalability benefits of async. セッション状態ストア プロバイダーでの非同期操作をサポートするために、ASP.NET には新しいインターフェイスである System.Web.SessionState.ISessionStateModule が含まれています。これは IHttpModule から継承され、開発者はこれを使用して独自のセッション状態モジュールと非同期セッション ストア プロバイダーを実装することができます。To supports asynchronous operations with session state store providers, ASP.NET includes a new interface, System.Web.SessionState.ISessionStateModule, which inherits from IHttpModule and allows developers to implement their own session-state module and async session store providers. このインターフェイスは次のように定義されます。The interface is defined as follows:

public interface ISessionStateModule : IHttpModule {
    void ReleaseSessionState(HttpContext context);
    Task ReleaseSessionStateAsync(HttpContext context);
Public Interface ISessionStateModule : Inherits IHttpModule
   Sub ReleaseSessionState(context As HttpContext)
   Function ReleaseSessionStateAsync(context As HttpContext) As Task
End Interface

また、SessionStateUtility クラスには IsSessionStateReadOnly および IsSessionStateRequired という 2 つの新しいメソッドが含まれています。これらを使用して、非同期操作をサポートできます。In addition, the SessionStateUtility class includes two new methods, IsSessionStateReadOnly and IsSessionStateRequired, that can be used to support asynchronous operations.

出力キャッシュ プロバイダーの非同期サポートAsync support for output-cache providers

.NET Framework 4.6.2 以降では、タスクを返すメソッドを出力キャッシュ プロバイダーで使って、非同期のスケーラビリティのメリットを得ることができます。Starting with the .NET Framework 4.6.2, task-returning methods can be used with output-cache providers to provide the scalability benefits of async. これらのメソッドを実装するプロバイダーは、Web サーバー上のスレッド ブロックを減らし、ASP.NET サービスのスケーラビリティを向上させます。Providers that implement these methods reduce thread-blocking on a web server and improve the scalability of an ASP.NET service.

非同期出力キャッシュ プロバイダーをサポートするために、次の API が追加されました。The following APIs have been added to support asynchronous output-cache providers:

文字カテゴリCharacter categories

.NET Framework 4.6.2 の文字は Unicode Standard バージョン 8.0.0 に基づいて分類されます。Characters in the .NET Framework 4.6.2 are classified based on the Unicode Standard, Version 8.0.0. .NET Framework 4.6 と .NET Framework 4.6.1 では、文字は Unicode 6.3 文字のカテゴリに基づいて分類されました。In .NET Framework 4.6 and .NET Framework 4.6.1, characters were classified based on Unicode 6.3 character categories.

Unicode 8.0 のサポートは、CharUnicodeInfo クラスによる文字列の分類およびそれに依存する型とメソッドに限定されます。Support for Unicode 8.0 is limited to the classification of characters by the CharUnicodeInfo class and to types and methods that rely on it. これらには、StringInfo クラス、オーバーロードされた Char.GetUnicodeCategory メソッド、および .NET Framework の正規表現エンジンによって認識される文字クラスが含まれます。These include the StringInfo class, the overloaded Char.GetUnicodeCategory method, and the character classes recognized by the .NET Framework regular expression engine. 文字や文字列の比較と並べ替えは、この変更の影響を受けることなく、引き続き基となるオペレーティング システムに依存します (Windows 7 システムの場合は、.NET Framework で提供される文字データに依存)。Character and string comparison and sorting is unaffected by this change and continues to rely on the underlying operating system or, on Windows 7 systems, on character data provided by the .NET Framework.

Unicode 6.0 から Unicode 7.0 への文字カテゴリの変更については、Unicode Consortium Web サイトの Unicode Standard バージョン 7.0.0 に関する記述を参照してください。For changes in character categories from Unicode 6.0 to Unicode 7.0, see The Unicode Standard, Version 7.0.0 at The Unicode Consortium website. Unicode 7.0 から Unicode 8.0 への変更については、Unicode Consortium の Web サイトの Unicode Standard バージョン 8.0.0 に関する記述を参照してください。For changes from Unicode 7.0 to Unicode 8.0, see The Unicode Standard, Version 8.0.0 at The Unicode Consortium website.


FIPS 186-3 DSA を含む X509 証明書のサポートSupport for X509 certificates containing FIPS 186-3 DSA

.NET Framework 4.6.2 には、FIPS 186-2 の 1024 ビットという制限を超えるキーを持つ、DSA (Digital Signature Algorithm) X509 証明書のサポートが追加されています。The .NET Framework 4.6.2 adds support for DSA (Digital Signature Algorithm) X509 certificates whose keys exceed the FIPS 186-2 1024-bit limit.

より大きな FIPS 186-3 のキー サイズのサポートに加えて、.NET Framework 4.6.2 では、SHA-2 ファミリのハッシュ アルゴリズム (SHA256、SHA384、SHA512) によるシグネチャ計算も可能です。In addition to supporting the larger key sizes of FIPS 186-3, the .NET Framework 4.6.2 allows computing signatures with the SHA-2 family of hash algorithms (SHA256, SHA384, and SHA512). FIPS 186-3 のサポートは新しい System.Security.Cryptography.DSACng クラスで提供されます。FIPS 186-3 support is provided by the new System.Security.Cryptography.DSACng class.

.NET Framework 4.6 の RSA クラスと .NET Framework 4.6.1 の ECDsa クラスの最近の変更に合わせて、.NET Framework 4.6.2 の DSA 抽象基本クラスには追加のメソッドがあり、これによって呼び出し元はこの機能をキャストせずに使用することができます。In keeping with recent changes to the RSA class in .NET Framework 4.6 and the ECDsa class in .NET Framework 4.6.1, the DSA abstract base class in .NET Framework 4.6.2 has additional methods to allow callers to use this functionality without casting. データに署名する場合は、以下の例のように、DSACertificateExtensions.GetDSAPrivateKey 拡張メソッドを呼び出すことができます。You can call the DSACertificateExtensions.GetDSAPrivateKey extension method to sign data, as the following example shows.

public static byte[] SignDataDsaSha384(byte[] data, X509Certificate2 cert)
    using (DSA dsa = cert.GetDSAPrivateKey())
        return dsa.SignData(data, HashAlgorithmName.SHA384);
Public Shared Function SignDataDsaSha384(data As Byte(), cert As X509Certificate2) As Byte()
    Using DSA As DSA = cert.GetDSAPrivateKey()
        Return DSA.SignData(data, HashAlgorithmName.SHA384)
    End Using
End Function

署名データを検証する場合は、以下の例のように、DSACertificateExtensions.GetDSAPublicKey 拡張メソッドを呼び出すことができます。And you can call the DSACertificateExtensions.GetDSAPublicKey extension method to verify signed data, as the following example shows.

public static bool VerifyDataDsaSha384(byte[] data, byte[] signature, X509Certificate2 cert)
    using (DSA dsa = cert.GetDSAPublicKey())
        return dsa.VerifyData(data, signature, HashAlgorithmName.SHA384);
 Public Shared Function VerifyDataDsaSha384(data As Byte(), signature As Byte(), cert As X509Certificate2) As Boolean
    Using dsa As DSA = cert.GetDSAPublicKey()
        Return dsa.VerifyData(data, signature, HashAlgorithmName.SHA384)
    End Using
End Function

ECDiffieHellman キー派生ルーチンへの入力をよりわかりやすくIncreased clarity for inputs to ECDiffieHellman key derivation routines

.NET Framework 3.5 では、3 種類の KDF (キー派生関数) ルーチンによる Elliptic Curve Diffie-Hellman キー承諾のサポートが追加されました。.NET Framework 3.5 added support for Elliptic Curve Diffie-Hellman Key Agreement with three different Key Derivation Function (KDF) routines. ルーチンへの入力、およびルーチン自体は ECDiffieHellmanCng オブジェクトのプロパティで構成されました。The inputs to the routines, and the routines themselves, were configured via properties on the ECDiffieHellmanCng object. しかし、すべてのルーチンですべての入力プロパティが読み取られるわけではないため、これまで開発者がよく混乱することがありました。But since not every routine read every input property, there was ample room for confusion on the past of the developer.

.NET Framework 4.6.2 ではこれに対処するために、次の 3 つのメソッドが ECDiffieHellman 基底クラスに追加され、これらの KDF ルーチンとその入力がよりわかりやくなりました。To address this in the .NET Framework 4.6.2, the following three methods have been added to the ECDiffieHellman base class to more clearly represent these KDF routines and their inputs:

ECDiffieHellman メソッドECDiffieHellman method 説明Description
DeriveKeyFromHash(ECDiffieHellmanPublicKey, HashAlgorithmName, Byte[], Byte[]) 次の式を使用してキー マテリアルを派生させます。Derives key material using the formula

HASH(secretPrepend || x || secretAppend)HASH(secretPrepend || x || secretAppend)

HASH(secretPrepend OrElse x OrElse secretAppend)HASH(secretPrepend OrElse x OrElse secretAppend)

ここで x は、EC Diffie-Hellman アルゴリズムの計算結果を表します。where x is the computed result of the EC Diffie-Hellman algorithm.
DeriveKeyFromHmac(ECDiffieHellmanPublicKey, HashAlgorithmName, Byte[], Byte[], Byte[]) 次の式を使用してキー マテリアルを派生させます。Derives key material using the formula

HMAC(hmacKey, secretPrepend || x || secretAppend)HMAC(hmacKey, secretPrepend || x || secretAppend)

HMAC(hmacKey, secretPrepend OrElse x OrElse secretAppend)HMAC(hmacKey, secretPrepend OrElse x OrElse secretAppend)

ここで x は、EC Diffie-Hellman アルゴリズムの計算結果を表します。where x is the computed result of the EC Diffie-Hellman algorithm.
DeriveKeyTls(ECDiffieHellmanPublicKey, Byte[], Byte[]) TLS 擬似乱数関数 (PRF) 派生アルゴリズムを使用して、キー マテリアルを派生させます。Derives key material using the TLS pseudo-random function (PRF) derivation algorithm.

永続化されたキーによる対称暗号化のサポートSupport for persisted-key symmetric encryption

Windows の暗号化ライブラリ (CNG) では、永続化された対称キーの格納とハードウェアに格納された対称キーの使用のサポートが追加され、.NET Framework 4.6.2 で開発者はこの機能を利用できるようになりました。The Windows cryptography library (CNG) added support for storing persisted symmetric keys and using hardware-stored symmetric keys, and the .NET Framework 4.6.2 made it possible for developers to make use of this feature. キー名とキー プロバイダーの概念が実装に固有であるため、この機能を使用するには、推奨されるファクトリ手法 (Aes.Create の呼び出しなど) ではなく、具象実装型のコンストラクターを利用する必要があります。Since the notion of key names and key providers is implementation-specific, using this feature requires utilizing the constructor of the concrete implementation types instead of the preferred factory approach (such as calling Aes.Create).

永続化されたキーによる対称暗号化は、AES (AesCng) と 3DES (TripleDESCng) アルゴリズムでサポートされます。Persisted-key symmetric encryption support exists for the AES (AesCng) and 3DES (TripleDESCng) algorithms. 次に例を示します。For example:

public static byte[] EncryptDataWithPersistedKey(byte[] data, byte[] iv)
    using (Aes aes = new AesCng("AesDemoKey", CngProvider.MicrosoftSoftwareKeyStorageProvider))
        aes.IV = iv;

        // Using the zero-argument overload is required to make use of the persisted key
        using (ICryptoTransform encryptor = aes.CreateEncryptor())
            if (!encryptor.CanTransformMultipleBlocks)
                throw new InvalidOperationException("This is a sample, this case wasn’t handled...");

            return encryptor.TransformFinalBlock(data, 0, data.Length);
Public Shared Function EncryptDataWithPersistedKey(data As Byte(), iv As Byte()) As Byte()
    Using Aes As Aes = New AesCng("AesDemoKey", CngProvider.MicrosoftSoftwareKeyStorageProvider)
        Aes.IV = iv

        ' Using the zero-argument overload Is required to make use of the persisted key
        Using encryptor As ICryptoTransform = Aes.CreateEncryptor()
            If Not encryptor.CanTransformMultipleBlocks Then
                Throw New InvalidOperationException("This is a sample, this case wasn’t handled...")
            End If
            Return encryptor.TransformFinalBlock(data, 0, data.Length)
        End Using
    End Using
End Function

SHA-2 ハッシュの SignedXml サポートSignedXml support for SHA-2 hashing

.NET Framework 4.6.2 では SignedXml クラスに対するサポートが追加され、RSA-SHA256、RSA-SHA384、RSA-SHA512 の各 PKCS#1 署名メソッド、および SHA256、SHA384、SHA512 の各参照ダイジェスト アルゴリズムが使うことができるようになりました。The .NET Framework 4.6.2 adds support to the SignedXml class for RSA-SHA256, RSA-SHA384, and RSA-SHA512 PKCS#1 signature methods, and SHA256, SHA384, and SHA512 reference digest algorithms.

以下のように、URI 定数はすべて SignedXml で示されます。The URI constants are all exposed on SignedXml:

SignedXml フィールドSignedXml field 定数Constant
XmlDsigSHA256Url "http://www.w3.org/2001/04/xmlenc#sha256""http://www.w3.org/2001/04/xmlenc#sha256"
XmlDsigRSASHA256Url "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256""http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"
XmlDsigSHA384Url "http://www.w3.org/2001/04/xmldsig-more#sha384""http://www.w3.org/2001/04/xmldsig-more#sha384"
XmlDsigRSASHA384Url "http://www.w3.org/2001/04/xmldsig-more#rsa-sha384""http://www.w3.org/2001/04/xmldsig-more#rsa-sha384"
XmlDsigSHA512Url "http://www.w3.org/2001/04/xmlenc#sha512""http://www.w3.org/2001/04/xmlenc#sha512"
XmlDsigRSASHA512Url "http://www.w3.org/2001/04/xmldsig-more#rsa-sha512""http://www.w3.org/2001/04/xmldsig-more#rsa-sha512"

これらのアルゴリズムのサポートを追加するためにカスタムの SignatureDescription ハンドラーを CryptoConfig に登録していたプログラムはすべて従来どおり引き続き機能しますが、既定でプラットフォームでサポートされるようになったため、CryptoConfig への登録は不要になりました。Any programs that have registered a custom SignatureDescription handler into CryptoConfig to add support for these algorithms will continue to function as they did in the past, but since there are now platform defaults, the CryptoConfig registration is no longer necessary.


.NET Framework 4.6.2 では、.NET Framework Data Provider for SQL Server (System.Data.SqlClient) に次の新機能が含まれています。.NET Framework Data Provider for SQL Server (System.Data.SqlClient) includes the following new features in the .NET Framework 4.6.2:

Azure SQL Database への接続プールとタイムアウトConnection pooling and timeouts with Azure SQL databases

接続プールが有効な状態で、タイムアウトまたは他のログイン エラーが発生した場合は、例外がキャッシュされ、キャッシュされた例外は次の 5 秒から 1 分の間の後続の接続試行時にすべてスローされます。When connection pooling is enabled and a timeout or other login error occurs, an exception is cached, and the cached exception is thrown on any subsequent connection attempt for the next 5 seconds to 1 minute. 詳しくは、「SQL Server の接続プール (ADO.NET)」をご覧ください。For more information, see SQL Server Connection Pooling (ADO.NET).

通常は迅速に復旧される一時的なエラーで接続試行が失敗する可能性があるため、Azure SQL Database への接続時のこの動作は望ましくありません。This behavior is not desirable when connecting to Azure SQL Databases, since connection attempts can fail with transient errors that are typically recovered quickly. 接続試行操作をより最適化するため、Azure SQL Database への接続が失敗した場合は、接続プールのブロック期間の動作は削除されます。To better optimize the connection retry experience, the connection pool blocking period behavior is removed when connections to Azure SQL Databases fail.

新しい PoolBlockingPeriod キーワードを追加することで、ご利用のアプリに最適なブロック期間を選択できます。The addition of the new PoolBlockingPeriod keyword lets you select the blocking period best suited for your app. 次の値が含まれます。Values include:


Azure SQL Database に接続しているアプリケーションの接続プールのブロック期間は無効になり、他のすべての SQL Server インスタンスに接続しているアプリケーションの接続プールのブロック期間が有効になります。The connection pool blocking period for an application that connects to an Azure SQL Database is disabled, and the connection pool blocking period for an application that connects to any other SQL Server instance is enabled. これが既定値です。This is the default value. サーバー エンドポイント名の末尾が以下のいずれかである場合は、Azure SQL Database と見なされます。If the Server endpoint name ends with any of the following, they are considered Azure SQL Databases:

  • .database.windows.net.database.windows.net

  • .database.chinacloudapi.cn.database.chinacloudapi.cn

  • .database.usgovcloudapi.net.database.usgovcloudapi.net

  • .database.cloudapi.de.database.cloudapi.de


接続プールのブロック期間は常に有効になります。The connection pool blocking period is always enabled.


接続プールのブロック期間は常に無効になります。The connection pool blocking period is always disabled.

Always Encrypted の強化Enhancements for Always Encrypted

SQLClient では、Always Encrypted の以下の 2 つの機能が強化されました。SQLClient introduces two enhancements for Always Encrypted:

  • 暗号化されたデータベースの列に対するパラメーター クエリのパフォーマンスを向上させるために、クエリ パラメーターの暗号化メタデータがキャッシュされるようになりました。To improve performance of parameterized queries against encrypted database columns, encryption metadata for query parameters is now cached. SqlConnection.ColumnEncryptionQueryMetadataCacheEnabled プロパティが true (既定値) に設定されている状態で、同じクエリが複数回呼び出された場合、クライアントはサーバーからパラメーターのメタデータを 1 回だけ取得します。With the SqlConnection.ColumnEncryptionQueryMetadataCacheEnabled property set to true (which is the default value), if the same query is called multiple times, the client retrieves parameter metadata from the server only once.

  • キー キャッシュ内の列暗号化キー エントリは、SqlConnection.ColumnEncryptionKeyCacheTtl プロパティを使用して設定された構成可能な時間間隔後に削除されるようになりました。Column encryption key entries in the key cache are now evicted after a configurable time interval, set using the SqlConnection.ColumnEncryptionKeyCacheTtl property.

Windows Communication FoundationWindows Communication Foundation

.NET Framework 4.6.2 では、Windows Communication Foundation の次の領域の機能が強化されています。In the .NET Framework 4.6.2, Windows Communication Foundation has been enhanced in the following areas:

CNG を使用して格納される証明書の WCF トランスポート セキュリティ サポートWCF transport security support for certificates stored using CNG

WCF トランスポート セキュリティでは、Windows 暗号化ライブラリ (CNG) を使用して格納される証明書がサポートされます。WCF transport security supports certificates stored using the Windows cryptography library (CNG). .NET Framework 4.6.2 では、このサポートは、指数の長さが 32 ビット以下の公開キーを持つ証明書を使う場合に限定されます。In the .NET Framework 4.6.2, this support is limited to using certificates with a public key that has an exponent no more than 32 bits in length. .NET Framework 4.6.2 を対象とするアプリケーションでは、この機能は既定で有効になります。When an application targets the .NET Framework 4.6.2, this feature is on by default.

.NET Framework 4.6.1 以前を対象とするアプリケーションが .NET Framework 4.6.2 で実行されている場合、app.config または web.config ファイルの <runtime> セクションに次の行を追加することで、この機能を有効にできます。For applications that target the .NET Framework 4.6.1 and earlier but are running on the .NET Framework 4.6.2, this feature can be enabled by adding the following line to the <runtime> section of the app.config or web.config file.


以下のようなコードを使用してプログラムで行うこともできます。This can also be done programmatically with code like the following:

private const string DisableCngCertificates = @"Switch.System.ServiceModel.DisableCngCertificates";
AppContext.SetSwitch(disableCngCertificates, false);
Const DisableCngCertificates As String = "Switch.System.ServiceModel.DisableCngCertificates"
AppContext.SetSwitch(disableCngCertificates, False)

DataContractJsonSerializer クラスによる複数の夏時間調整規則のサポート強化Better support for multiple daylight saving time adjustment rules by the DataContractJsonSerializer class

お客様はアプリケーションの構成設定を使用して、DataContractJsonSerializer クラスで 1 つのタイム ゾーンに対して複数の調整規則がサポートされているかどうかを判別することができます。Customers can use an application configuration setting to determine whether the DataContractJsonSerializer class supports multiple adjustment rules for a single time zone. これはオプトイン機能です。This is an opt-in feature. これを有効にするには、app.config ファイルに次の設定を追加します。To enable it, add the following setting to your app.config file:

     <AppContextSwitchOverrides value="Switch.System.Runtime.Serialization.DoNotUseTimeZoneInfo=false" />

この機能が有効な場合、DataContractJsonSerializer オブジェクトは TimeZone 型ではなく TimeZoneInfo 型を使用して、日時データを逆シリアル化します。When this feature is enabled, a DataContractJsonSerializer object uses the TimeZoneInfo type instead of the TimeZone type to deserialize date and time data. TimeZoneInfo では、TimeZone でサポートされない複数の調整規則がサポートされるため、過去のタイム ゾーン データを操作できます。TimeZoneInfo supports multiple adjustment rules, which makes it possible to work with historic time zone data; TimeZone does not.

TimeZoneInfo 構造体とタイム ゾーン調整の詳細については、「タイム ゾーンの概要」を参照してください。For more information on the TimeZoneInfo structure and time zone adjustments, see Time Zone Overview.

NetNamedPipeBinding の最適な一致NetNamedPipeBinding best match

WCF には、クライアント アプリケーションで設定できる新しいアプリ設定があります。これにより、クライアント アプリケーションは常に、要求したものと最も一致する URI でリッスンしているサービスに接続できます。WCF has a new app setting that can be set on client applications to ensure they always connect to the service listening on the URI that best matches the one that they request. このアプリ設定が false (既定値) に設定されている場合、クライアントは NetNamedPipeBinding を使用して、要求した URI の部分文字列である URI でリッスンしているサービスへの接続を試行できます。With this app setting set to false (the default), it is possible for clients using NetNamedPipeBinding to attempt to connect to a service listening on a URI that is a substring of the requested URI.

たとえば、クライアントが net.pipe://localhost/Service1 でリッスンしているサービスに接続しようとしているときに、管理者特権で実行しているコンピューター上の別のサービスが net.pipe://localhost でリッスンしているとします。For example, a client tries to connect to a service listening at net.pipe://localhost/Service1, but a different service on that machine running with administrator privilege is listening at net.pipe://localhost. このアプリ設定が false に設定されている場合、クライアントは間違ったサービスに接続しようとします。With this app setting set to false, the client would attempt to connect to the wrong service. アプリ設定を true に設定すれば、クライアントは常に最も一致するサービスに接続するようになります。After setting the app setting to true, the client will always connect to the best matching service.


NetNamedPipeBinding を使用するクライアントは、完全なエンドポイント アドレスではなく、サービスのベース アドレス (存在する場合) に基づいてサービスを検索します。Clients using NetNamedPipeBinding find services based on the service's base address (if it exists) rather than the full endpoint address. この設定が常に機能するようにするには、サービスは一意のベース アドレスを使用する必要があります。To ensure this setting always works the service should use a unique base address.

この変更を有効にするには、以下のアプリ設定をクライアント アプリケーションの App.config ファイルまたは Web.config ファイルに追加します。To enable this change, add the following app setting to your client application's App.config or Web.config file:

        <add key="wcf:useBestMatchNamedPipeUri" value="true" />

SSL 3.0 が既定のプロトコルではなくなったSSL 3.0 is not a default protocol

トランスポート セキュリティで NetTcp を使用し、証明書の資格情報の種類を使用する場合、SSL 3.0 は、安全な接続のネゴシエーションに使用される既定のプロトコルではなくなりました。When using NetTcp with transport security and a credential type of certificate, SSL 3.0 is no longer a default protocol used for negotiating a secure connection. TLS 1.0 が NetTcp のプロトコル一覧に含まれているため、ほとんどの場合、既存のアプリには影響はないと考えられます。In most cases, there should be no impact to existing apps, because TLS 1.0 is included in the protocol list for NetTcp. 既存のすべてのクライアントは TLS 1.0 以降を使用して接続をネゴシエートできるようになりました。All existing clients should be able to negotiate a connection using at least TLS 1.0. Ssl3 が必要な場合は、以下の構成メカニズムのいずれかを使用して、ネゴシエートされたプロトコルの一覧に追加します。If Ssl3 is required, use one of the following configuration mechanisms to add it to the list of negotiated protocols.

Windows Presentation Foundation (WPF)Windows Presentation Foundation (WPF)

.NET Framework 4.6.2 では、Windows Presentation Foundation の次の領域の機能が強化されています。In the .NET Framework 4.6.2, Windows Presentation Foundation has been enhanced in the following areas:

グループの並べ替えGroup sorting

CollectionView オブジェクトを使用してデータをグループ化するアプリケーションは、グループを並べ替える方法を明示的に宣言できるようになりました。An application that uses a CollectionView object to group data can now explicitly declare how to sort the groups. 明示的な並べ替えにより、アプリがグループを動的に追加または削除する場合や、グループ化に関連する項目のプロパティの値を変更する場合に発生する非直感的な順序付けの問題が解決されます。Explicit sorting addresses the problem of non-intuitive ordering that occurs when an app dynamically adds or removes groups, or when it changes the value of item properties involved in grouping. また、グループ化プロパティの比較がコレクション全体の並べ替えからグループの並べ替えに変更されるため、グループ作成プロセスのパフォーマンスを向上させることができます。It can also improve the performance of the group creation process by moving comparisons of the grouping properties from the sort of the full collection to the sort of the groups.

グループの並べ替えをサポートするために、新しい GroupDescription.SortDescriptions および GroupDescription.CustomSort プロパティで、GroupDescription オブジェクトによって生成されるグループのコレクションを並べ替える方法が示されます。To support group sorting, the new GroupDescription.SortDescriptions and GroupDescription.CustomSort properties describe how to sort the collection of groups produced by the GroupDescription object. これは、同じ名前の ListCollectionView プロパティでデータ項目を並べ替える方法を示すのと同様です。This is analogous to the way the identically named ListCollectionView properties describe how to sort the data items.

PropertyGroupDescription クラスの新しい 2 つの静的プロパティである CompareNameAscendingCompareNameDescending は、最も一般的なケースで使用できます。Two new static properties of the PropertyGroupDescription class, CompareNameAscending and CompareNameDescending, can be used for the most common cases.

たとえば、次の XAML ではデータを年齢でグループ化し、年齢グループを昇順に並べ替え、各年齢グループ内の項目を姓でグループ化します。For example, the following XAML groups data by age, sort the age groups in ascending order, and group the items within each age group by last name.

              "{x:Static PropertyGroupDescription.CompareNamesAscending}"/>

     <SortDescription PropertyName="LastName"/>

タッチ キーボードのサポートTouch keyboard support

タッチ キーボードのサポートにより、WPF アプリケーションでのフォーカス追跡が可能になります。テキスト入力が可能なコントロールによってタッチ入力が受信されると、Windows 10 の新しいタッチ キーボードが自動的に起動および終了します。Touch keyboard support enables focus tracking in WPF applications by automatically invoking and dismissing the touch Keyboard in Windows 10 when the touch input is received by a control that can take textual input.

.NET Framework の以前のバージョンでは、WPF アプリケーションで、WPF のペンまたはタッチ ジェスチャ サポートを無効にしないとフォーカス追跡を選択できません。In previous versions of .NET Framework, WPF applications can't opt into the focus tracking without disabling WPF pen/touch gesture support. そのため、WPF アプリケーションは完全な WPF タッチのフル サポートを選ぶか、Windows のマウス プロモーションに依存する必要があります。As a result, WPF applications must choose between full WPF touch support or rely on Windows mouse promotion.

モニターごとの DPIPer-monitor DPI

WPF アプリ用の高 DPI とハイブリッド DPI 環境の最近の急激な増加に対応するために、.NET Framework 4.6.2 の WPF でモニターごとに対応できるようになりました。To support the recent proliferation of high-DPI and hybrid-DPI environments for WPF apps, WPF in the .NET Framework 4.6.2 enables per-monitor awareness. ご使用の WPF アプリでモニターごとの DPI 対応を有効にする方法の詳細については、GitHub のサンプルと開発者向けガイドに関するページを参照してください。See the samples and developer guide on GitHub for more information about how to enable your WPF app to become per-monitor DPI aware.

.NET Framework の以前のバージョンでは、WPF アプリはシステム DPI 対応です。In previous versions of the .NET Framework, WPF apps are system-DPI aware. つまり、アプリケーションの UI は、アプリがレンダリングされるモニターの DPI に基づき、必要に応じて OS でスケーリングされます。In other words, the application's UI is scaled by the OS as appropriate, depending on the DPI of the monitor on which the app is rendered.

.NET Framework 4.6.2 で実行されるアプリの場合、次のように、アプリケーションの構成ファイルの <runtime> セクションに構成ステートメントを追加して、WPF アプリでモニターごとの DPI 変更を無効にすることができます。For apps running under the .NET Framework 4.6.2, you can disable per-monitor DPI changes in WPF apps by adding a configuration statement to the <runtime> section of your application configuration file, as follows:

   <AppContextSwitchOverrides value="Switch.System.Windows.DoNotScaleForDpiChanges=false"/>

Windows Workflow Foundation (WF)Windows Workflow Foundation (WF)

.NET Framework 4.6.2 では、Windows Workflow Foundation の次領域の機能が強化されています。In the .NET Framework 4.6.2, Windows Workflow Foundation has been enhanced in the following area:

再ホストされた WF デザイナーにおける C# 式と IntelliSense のサポートSupport for C# expressions and IntelliSense in the Rehosted WF Designer

.NET Framework 4.5 以降では、WF によって、Visual Studio デザイナーとコード ワークフローの両方で C# 式がサポートされます。Starting with .NET Framework 4.5, WF supports C# expressions in both the Visual Studio Designer and in code workflows. 再ホストされたワークフロー デザイナーは WF の主な機能です。これにより、ワークフロー デザイナーを Visual Studio の外部のアプリケーション (WPF など) で使用できるようになります。The Rehosted Workflow Designer is a key feature of WF that allows for the Workflow Designer to be in an application outside Visual Studio (for example, in WPF). Windows Workflow Foundation は、再ホストされたワークフロー デザイナーで C# 式と IntelliSense をサポートできるようにします。Windows Workflow Foundation provides the ability to support C# expressions and IntelliSense in the Rehosted Workflow Designer. 詳細については、Windows Workflow Foundation のブログを参照してください。For more information, see the Windows Workflow Foundation blog.

Availability of IntelliSense when a customer rebuilds a workflow project from Visual Studio 4.6.2 より前のバージョンの .NET Framework で、お客様が Visual Studio からワークフロー プロジェクトを再ビルドした場合、WF Designer IntelliSense は破損してしまいます。Availability of IntelliSense when a customer rebuilds a workflow project from Visual Studio In versions of the .NET Framework prior to 4.6.2, WF Designer IntelliSense is broken when a customer rebuilds a workflow project from Visual Studio. プロジェクトのビルドに成功しても、デザイナーでワークフローの種類が見つからず、 [エラー一覧] ウィンドウにワークフローの種類が欠落していることを示す IntelliSense からの警告が表示されます。While the project build is successful, the workflow types are not found on the designer, and warnings from IntelliSense for the missing workflow types appear in the Error List window. .NET Framework 4.6.2 ではこのイシューに対処し、IntelliSense を使用できるようにします。.NET Framework 4.6.2 addresses this issue and makes IntelliSense available.

ワークフロー追跡を有効にしたワークフロー V1 アプリケーションを FIPS モードで実行Workflow V1 applications with Workflow Tracking on now run under FIPS-mode

FIPS コンプライアンス モードが有効なコンピューターで、ワークフロー追跡が有効なワークフロー バージョン 1 スタイルのアプリケーションを正常に実行できるようになりました。Machines with FIPS Compliance Mode enabled can now successfully run a workflow Version 1-style application with Workflow tracking on. このシナリオを有効にするには、app.config ファイルを以下のように変更する必要があります。To enable this scenario, you must make the following change to your app.config file:

<add key="microsoft:WorkflowRuntime:FIPSRequired" value="true" />

このシナリオが有効でない場合、アプリケーションを実行すると、引き続き例外が生成され、"この実装は Windows プラットフォーム FIPS 検証暗号化アルゴリズムの一部ではありません" というメッセージが表示されます。If this scenario is not enabled, running the application continues to generate an exception with the message, "This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms."

Visual Studio ワークフロー デザイナーで動的更新を使用する場合のワークフローの改善Workflow Improvements when using Dynamic Update with Visual Studio Workflow Designer

ワークフロー デザイナー、フローチャート アクティビティ デザイナー、およびその他のワークフロー アクティビティ デザイナーで、DynamicUpdateServices.PrepareForUpdate メソッドを呼び出した後に保存されたワークフローが正常に読み込まれ、表示されるようになりました。The Workflow Designer, FlowChart Activity Designer, and other Workflow Activity Designers now successfully load and display workflows that have been saved after calling the DynamicUpdateServices.PrepareForUpdate method. .NET Framework 4.6.2 より前のバージョンの .NET Framework では、DynamicUpdateServices.PrepareForUpdate を呼び出した後に保存されたワークフローの XAML ファイルを Visual Studio で読み込むと、以下の問題が発生する場合がありました。In versions of the .NET Framework before .NET Framework 4.6.2, loading a XAML file in Visual Studio for a workflow that has been saved after calling DynamicUpdateServices.PrepareForUpdate can result in the following issues:

  • ワークフロー デザイナーで XAML ファイルが正しく読み込めない (行の末尾に ViewStateData.Id がある場合)。The Workflow Designer can't load the XAML file correctly (when the ViewStateData.Id is at the end of the line).

  • フローチャート アクティビティ デザイナーまたは他のワークフロー アクティビティ デザイナーで、アタッチされるプロパティの値ではなく既定の場所にすべてのオブジェクトが表示される場合がある。Flowchart Activity Designer or other Workflow Activity Designers may display all objects in their default locations as opposed to attached property values.


ClickOnce が更新され、既にサポートされている 1.0 プロトコルに加え、TLS 1.1 と TLS 1.2 がサポートがサポートされるようになりました。ClickOnce has been updated to support TLS 1.1 and TLS 1.2 in addition to the 1.0 protocol, which it already supports. ClickOnce が必要なプロトコルを自動的に検出するため、TLS 1.1 と 1.2 のサポートを有効にするために、ClickOnce アプリケーション内での追加の手順は不要です。ClickOnce automatically detects which protocol is required; no extra steps within the ClickOnce application are required to enable TLS 1.1 and 1.2 support.

Windows フォームおよび WPF アプリの UWP アプリへの変換Converting Windows Forms and WPF apps to UWP apps

Windows では、WPF および Windows フォーム アプリを含む、既存の Windows デスクトップ アプリを UWP (ユニバーサル Windows プラットフォーム) で使用できるようになりました。Windows now offers capabilities to bring existing Windows desktop apps, including WPF and Windows Forms apps, to the Universal Windows Platform (UWP). このテクノロジはブリッジとして機能し、既存のコード ベースを段階的に UWP に移行し、アプリをすべての Windows 10 デバイスで使用できるようにします。This technology acts as a bridge by enabling you to gradually migrate your existing code base to UWP, thereby bringing your app to all Windows 10 devices.

変換後のデスクトップ アプリは UWP アプリのアプリ ID のようなアプリ ID を取得し、UWP API をアクセス可能にして、ライブ タイルや通知などの機能を有効にすることができます。Converted desktop apps gain an app identity similar to the app identity of UWP apps, which makes UWP APIs accessible to enable features such as Live Tiles and notifications. アプリは引き続き従来どおり動作し、完全信頼アプリとして実行されます。The app continues to behave as before and runs as a full trust app. アプリが変換されたら、アプリ コンテナー プロセスを既存の完全信頼プロセスに追加し、適応ユーザー インターフェイスを追加できます。Once the app is converted, an app container process can be added to the existing full trust process to add an adaptive user interface. すべての機能がアプリ コンテナー プロセスに移行されたら、完全信頼プロセスを削除し、新しい UWP アプリをすべての Windows 10 デバイスで有効にすることができます。When all functionality is moved to the app container process, the full trust process can be removed and the new UWP app can be made available to all Windows 10 devices.

デバッグの機能強化Debugging improvements

.NET Framework 4.6.2 で アンマネージ デバッグ API が強化され、NullReferenceException がスローされたときに、ソース コードの単一行でどの変数が null になっているかを判別できるように、さらに分析されるようになりました。The unmanaged debugging API has been enhanced in the .NET Framework 4.6.2 to perform additional analysis when a NullReferenceException is thrown so that it is possible to determine which variable in a single line of source code is null. このシナリオをサポートするために、次の API がアンマネージ デバッグ API に追加されました。To support this scenario, the following APIs have been added to the unmanaged debugging API.

.NET Framework 4.6.1 の新機能What's new in .NET Framework 4.6.1

.NET Framework 4.6.1 には、次の領域における新機能が含まれています。The .NET Framework 4.6.1 includes new features in the following areas:

.NET Framework 4.6.1 の詳細については、次のトピックを参照してください。For more information on the .NET Framework 4.6.1, see the following topics:

暗号: ECDSA を含む X509 証明書のサポートCryptography: Support for X509 certificates containing ECDSA

.NET Framework 4.6 では、X509 証明書の RSACng サポートが追加されました。.NET Framework 4.6 added RSACng support for X509 certificates. .NET Framework 4.6.1 では、ECDSA (Elliptic Curve Digital Signature Algorithm: 楕円曲線デジタル署名アルゴリズム) X509 証明書のサポートが追加されました。The .NET Framework 4.6.1 adds support for ECDSA (Elliptic Curve Digital Signature Algorithm) X509 certificates.

ECDSA は、RSA よりも安全な暗号化アルゴリズムで、パフォーマンスも向上するため、トランスポート層セキュリティ (TLS) のパフォーマンスとスケーラビリティが問題になる場合に最適な選択肢です。ECDSA offers better performance and is a more secure cryptography algorithm than RSA, providing an excellent choice where Transport Layer Security (TLS) performance and scalability is a concern. .NET Framework の実装では、既存の Windows 機能の呼び出しがラップされます。The .NET Framework implementation wraps calls into existing Windows functionality.

次のサンプル コードでは、.NET Framework 4.6.1 での新しい ECDSA X509 証明書のサポートを使ってバイト ストリームの署名が簡単に生成できることを示しています。The following example code shows how easy it is to generate a signature for a byte stream by using the new support for ECDSA X509 certificates included in the .NET Framework 4.6.1.

using System;
using System.Security.Cryptography;
using System.Security.Cryptography.X509Certificates;

public class Net461Code
    public static byte[] SignECDsaSha512(byte[] data, X509Certificate2 cert)
        using (ECDsa privateKey = cert.GetECDsaPrivateKey())
            return privateKey.SignData(data, HashAlgorithmName.SHA512);

    public static byte[] SignECDsaSha512(byte[] data, ECDsa privateKey)
        return privateKey.SignData(data, HashAlgorithmName.SHA512);
Imports System.Security.Cryptography
Imports System.Security.Cryptography.X509Certificates

Public Class Net461Code
    Public Shared Function SignECDsaSha512(data As Byte(), cert As X509Certificate2) As Byte()
        Using privateKey As ECDsa = cert.GetECDsaPrivateKey()
            Return privateKey.SignData(data, HashAlgorithmName.SHA512)
        End Using
    End Function

    Public Shared Function SignECDsaSha512(data As Byte, privateKey As ECDsa) As Byte()
        Return privateKey.SignData(data, HashAlgorithmName.SHA512)
    End Function
End Class

このコードは、.NET Framework 4.6 での署名の生成に必要な次のコードとは大きく異なっています。This offers a marked contrast to the code needed to generate a signature in .NET Framework 4.6.

using System;
using System.Security.Cryptography;
using System.Security.Cryptography.X509Certificates;

public class Net46Code
    public static byte[] SignECDsaSha512(byte[] data, X509Certificate2 cert)
        // This would require using cert.Handle and a series of p/invokes to get at the
        // underlying key, then passing that to a CngKey object, and passing that to
        // new ECDsa(CngKey).  It's a lot of work.
        throw new Exception("That's a lot of work...");

    public static byte[] SignECDsaSha512(byte[] data, ECDsa privateKey)
        // This way works, but SignData probably better matches what you want.
        using (SHA512 hasher = SHA512.Create())
            byte[] signature1 = privateKey.SignHash(hasher.ComputeHash(data));

        // This might not be the ECDsa you got!
        ECDsaCng ecDsaCng = (ECDsaCng)privateKey;
        ecDsaCng.HashAlgorithm = CngAlgorithm.Sha512;
        return ecDsaCng.SignData(data);
Imports System.Security.Cryptography
Imports System.Security.Cryptography.X509Certificates

Public Class Net46Code
    Public Shared Function SignECDsaSha512(data As Byte(), cert As X509Certificate2) As Byte()
        ' This would require using cert.Handle and a series of p/invokes to get at the
        ' underlying key, then passing that to a CngKey object, and passing that to
        ' new ECDsa(CngKey).  It's a lot of work.
        Throw New Exception("That's a lot of work...")
    End Function

    Public Shared Function SignECDsaSha512(data As Byte(), privateKey As ECDsa) As Byte()
        ' This way works, but SignData probably better matches what you want.
        Using hasher As SHA512 = SHA512.Create()
            Dim signature1 As Byte() = privateKey.SignHash(hasher.ComputeHash(data))
        End Using

        ' This might not be the ECDsa you got!
        Dim ecDsaCng As ECDsaCng = CType(privateKey, ECDsaCng)
        ecDsaCng.HashAlgorithm = CngAlgorithm.Sha512
        Return ecDsaCng.SignData(data)
    End Function
End Class   


次のものが ADO.NET に追加されました。The following have been added to ADO.NET:

ハードウェア保護キーに対する Always Encrypted のサポートAlways Encrypted support for hardware protected keys

ADO.NET では、Always Encrypted 列 (常に暗号化される列) のマスター キーをハードウェア セキュリティ モジュール (HSM) に格納することが、ネイティブでサポートされるようになりました。ADO.NET now supports storing Always Encrypted column master keys natively in Hardware Security Modules (HSMs). このサポートによって、ユーザーは、HSM に格納された非対称キーを利用できます。カスタムの列マスター キー ストア プロバイダーを作成してからアプリケーションに登録する必要はありません。With this support, customers can leverage asymmetric keys stored in HSMs without having to write custom column master key store providers and registering them in applications.

HSM に格納された列マスター キーで保護された Always Encrypted データにアクセスするには、HSM ベンダー提供の CSP プロバイダーまたは CNG キー ストア プロバイダーをアプリ サーバーまたはクライアント コンピューターにインストールする必要があります。Customers need to install the HSM vendor-provided CSP provider or CNG key store providers on the app servers or client computers in order to access Always Encrypted data protected with column master keys stored in a HSM.

AlwaysOn に対する MultiSubnetFailover の接続動作の向上Improved MultiSubnetFailover connection behavior for AlwaysOn

SqlClient で、AlwaysOn 可用性グループ (AG) へのより高速な接続が自動的に提供されるようになりました。SqlClient now automatically provides faster connections to an AlwaysOn Availability Group (AG). SqlClient では、アプリケーションが別のサブネット上の AlwaysOn 可用性グループ (AG) に接続しているかどうかを自動的に検出し、現在のアクティブなサーバーを迅速に探索し、そのサーバーへの接続を提供します。It transparently detects whether your application is connecting to an AlwaysOn availability group (AG) on a different subnet and quickly discovers the current active server and provides a connection to the server. このリリースよりも前は、アプリケーションで接続文字列を設定し、"MultisubnetFailover=true" を含め、AlwaysOn 可用性グループに接続されていることを示す必要がありました。Prior to this release, an application had to set the connection string to include "MultisubnetFailover=true" to indicate that it was connecting to an AlwaysOn Availability Group. true への接続キーワードを設定しないと、アプリケーションで AlwaysOn 可用性グループに接続中にタイムアウトが発生する可能性がありました。Without setting the connection keyword to true, an application might experience a timeout while connecting to an AlwaysOn Availability Group. このリリースを使用すれば、アプリケーションで MultiSubnetFailovertrue に設定する必要がなくなります。With this release, an application does not need to set MultiSubnetFailover to true anymore. Always On 可用性グループの SqlClient サポートの詳細については、「高可用性障害復旧のための SqlClient サポート」をご覧ください。For more information about SqlClient support for Always On Availability Groups, see SqlClient Support for High Availability, Disaster Recovery.

Windows Presentation Foundation (WPF)Windows Presentation Foundation (WPF)

Windows Presentation Foundation には、さまざまな改善と変更が含まれています。Windows Presentation Foundation includes a number of improvements and changes.

パフォーマンスの向上Improved performance

.NET Framework 4.6.1 で、タッチ イベントの開始の遅延が修正されました。The delay in firing touch events has been fixed in the .NET Framework 4.6.1. また、RichTextBox コントロールの入力が高速入力時のレンダーのスレッドを停止させなくなりました。In addition, typing in a RichTextBox control no longer ties up the render thread during fast input.

スペル チェック機能の改善Spell checking improvements

WPF のスペル チェック機能が、追加の言語のスペル チェックのためにオペレーティング システムのサポートを利用するように、Windows 8.1 以降のバージョンで更新されました。The spell checker in WPF has been updated on Windows 8.1 and later versions to leverage operating system support for spell-checking additional languages. Windows 8.1 よりも前の Windows バージョンの機能の変更はありません。There is no change in functionality on Windows versions prior to Windows 8.1.

以前のバージョンの .NET Framework と同様に、TextBox コントロールまたは RichTextBox ブロック用の言語が、次の順序で情報を探すことによって検出されます。As in previous versions of the .NET Framework, the language for a TextBox control ora RichTextBox block is detected by looking for information in the following order:

  • xml:lang (存在する場合)。xml:lang, if it is present.

  • 現在の入力言語。Current input language.

  • 現在のスレッド カルチャ。Current thread culture.

WPF での言語サポートの詳細については、.NET Framework 4.6.1 機能に関する WPF ブログの記事を参照してください。For more information on language support in WPF, see the WPF blog post on .NET Framework 4.6.1 features.

ユーザーごとのユーザー辞書の追加サポートAdditional support for per-user custom dictionaries

.NET Framework 4.6.1 では、WPF で、グローバルに登録されているユーザー辞書が認識されます。In .NET Framework 4.6.1, WPF recognizes custom dictionaries that are registered globally. この機能は、ユーザー辞書をコントロールごとに登録する機能に加えて使用できます。This capability is available in addition to the ability to register them per-control.

以前のバージョンの WPF では、ユーザー辞書で除外された単語とオートコレクト リストが認識されませんでした。In previous versions of WPF, custom dictionaries did not recognize Excluded Words and AutoCorrect lists. %AppData%\Microsoft\Spelling\<language tag> ディレクトリに配置できるファイルの使用によって、これらが Windows 8.1 と Windows 10 でサポートされます。They are supported on Windows 8.1 and Windows 10 through the use of files that can be placed under the %AppData%\Microsoft\Spelling\<language tag> directory. これらのファイルには、次の規則が適用されます。The following rules apply to these files:

  • これらのファイルには、拡張子の .dic (追加された単語の場合)、.exc (除外された単語の場合)、または .acl (オートコレクトの場合) が付いている必要があります。The files should have extensions of .dic (for added words), .exc (for excluded words), or .acl (for AutoCorrect).

  • これらのファイルは、バイト オーダー マーク (BOM) で始まる UTF-16 LE プレーン テキストである必要があります。The files should be UTF-16 LE plaintext that starts with the Byte Order Mark (BOM).

  • それぞれの行は、1 つの単語 (追加および除外された単語の一覧内)、または単語が縦棒 ("|") で区切られたオートコレクトのペア (オートコレクトの単語の一覧内) で構成される必要があります。Each line should consist of a word (in the added and excluded word lists), or an autocorrect pair with the words separated by a vertical bar ("|") (in the AutoCorrect word list).

  • これらのファイルは読み取り専用と見なされ、システムによって変更されることはありません。These files are considered read-only and are not modified by the system.


これらの新しいファイル形式は、WPF スペル チェック API で直接サポートされるわけではありません。また、アプリケーションで WPF に提供されるユーザー辞書では以前と同様に .lex ファイルを使用する必要があります。These new file-formats are not directly supported by the WPF spell checking APIs, and the custom dictionaries supplied to WPF in applications should continue to use .lex files.


WPF のサンプルは、Microsoft/WPF サンプル GitHub リポジトリにいくつかあります。There are a number of WPF samples on the Microsoft/WPF-Samples GitHub repository. プル要求を送信するか、またはGitHub issue (GitHub の問題) を開いて、これらのサンプルの改善にご協力ください。Help us improve our samples by sending us a pull-request or opening a GitHub issue.

DirectX の拡張機能DirectX extensions

WPF には、DX10 および Dx11 のコンテンツとの相互運用を容易にする、D3DImage の新しい実装を提供する NuGet パッケージが含まれています。WPF includes a NuGet package that provides new implementations of D3DImage that make it easy for you to interoperate with DX10 and Dx11 content. このパッケージのコードはオープン ソース化されており、GitHub で入手できます。The code for this package has been open sourced and is available on GitHub.

Windows Workflow Foundation: トランザクションWindows Workflow Foundation: Transactions

Transaction.EnlistPromotableSinglePhase メソッドで、MSDTC 以外の分散トランザクション マネージャーを使用して、トランザクションをプロモート (昇格) できるようになりました。The Transaction.EnlistPromotableSinglePhase method can now use a distributed transaction manager other than MSDTC to promote the transaction. このプロモートは、新しい Transaction.EnlistPromotableSinglePhase(IPromotableSinglePhaseNotification, Guid) オーバーロードに GUID のトランザクション プロモーター識別子を指定することによって行います。You do this by specifying a GUID transaction promoter identifier to the new Transaction.EnlistPromotableSinglePhase(IPromotableSinglePhaseNotification, Guid) overload . この操作が成功すると、そのトランザクションの機能に制限が加えられます。If this operation is successful, there are limitations placed on the capabilities of the transaction. MSDTC 以外のトランザクション プロモーターが登録される (参加する) と、次の各メソッドで MSDTC へのプロモートが必要になるため、これらのメソッドで TransactionPromotionException がスローされます。Once a non-MSDTC transaction promoter is enlisted, the following methods throw a TransactionPromotionException because these methods require promotion to MSDTC:

MSDTC 以外のトランザクション プロモーターが登録されると、そのプロモーターで定義するプロトコルを使用することで、そのプロモーターをその後の永続参加リストに使用する必要があります。Once a non-MSDTC transaction promoter is enlisted, it must be used for future durable enlistments by using protocols that it defines. トランザクション プロモーターの Guid は、PromoterType プロパティを使用して取得できます。The Guid of the transaction promoter can be obtained by using the PromoterType property. トランザクションがプロモートする際、トランザクション プロモーターによって、プロモート済みトークンを表す Byte 配列が提供されます。When the transaction promotes, the transaction promoter provides a Byte array that represents the promoted token. アプリケーションで、MSDTC 以外のプロモート済みトランザクションのプロモート済みトークンを GetPromotedToken メソッドを使用して取得できます。An application can obtain the promoted token for a non-MSDTC promoted transaction with the GetPromotedToken method.

新しい Transaction.EnlistPromotableSinglePhase(IPromotableSinglePhaseNotification, Guid) オーバーロードのユーザーは、プロモーション操作が正常に完了するように、特定の呼び出しシーケンスに従う必要があります。Users of the new Transaction.EnlistPromotableSinglePhase(IPromotableSinglePhaseNotification, Guid) overload must follow a specific call sequence in order for the promotion operation to complete successfully. これらの規則は、メソッドのドキュメントに記載されています。These rules are documented in the method's documentation.


アンマネージド プロファイリング API が、次のように拡張されました。The unmanaged profiling API has been enhanced as follows:

  • ICorProfilerInfo7 インターフェイス内の PDB へのアクセスのサポートが向上。Better support for accessing PDBs in the ICorProfilerInfo7 interface.

    ASP.NET Core では、アセンブリがメモリ内で Roslyn によってコンパイルされることがよりいっそう一般的になっています。In ASP.NET Core, it is becoming much more common for assemblies to be compiled in-memory by Roslyn. プロファイル ツールを作成する開発者にとって、これは従来ディスクにシリアル化されていた PDB が存在しなくなる可能性があることを意味しています。For developers making profiling tools, this means that PDBs that historically were serialized on disk may no longer be present. プロファイル ツールでは、多くの場合 PDB を使用して、コード カバレッジや 1 行単位のパフォーマンス分析などのタスクのソース行に、コードをマップし戻します。Profiler tools often use PDBs to map code back to source lines for tasks such as code coverage or line-by-line performance analysis. ICorProfilerInfo7 インターフェイスは、メモリ内の PDB データにアクセスして、これらのプロファイル ツールを提供する 2 つの新しいメソッド、ICorProfilerInfo7::GetInMemorySymbolsLengthICorProfilerInfo7::ReadInMemorySymbols を含むようになりました。これらの新しい API を使用すれば、プロファイラーでメモリ内の PDB の内容をバイト配列として取得してから、それを処理したり、ディスクにシリアル化したりできます。The ICorProfilerInfo7 interface now includes two new methods, ICorProfilerInfo7::GetInMemorySymbolsLength and ICorProfilerInfo7::ReadInMemorySymbols, to provide these profiler tools with access to the in-memory PDB data, By using the new APIs, a profiler can obtain the contents of an in-memory PDB as a byte array and then process it or serialize it to disk.

  • ICorProfiler インターフェイスを使用したインストルメンテーションの改善。Better instrumentation with the ICorProfiler interface.

    動的インストルメンテーションに ICorProfiler API ReJit 機能を使用しているプロファイラーで、いくつかのメタデータを変更できるようになりました。Profilers that are using the ICorProfiler APIs ReJit functionality for dynamic instrumentation can now modify some metadata. 従来、このようなツールでは、いつでも IL をインストルメント化できましたが、メタデータを変更できるのはモジュールを読み込む時だけでした。Previously such tools could instrument IL at any time, but metadata could only be modified at module load time. IL はメタデータを参照するため、実行できるインストルメンテーションの種類が限られています。Because IL refers to metadata, this limited the kinds of instrumentation that could be done. モジュールの読み込み後のメタデータの編集のサブセットをサポートするために、ICorProfilerInfo7::ApplyMetaData メソッドを追加することで (特に新しい AssemblyRefTypeRefTypeSpecMemberRefMemberSpec、および UserString の各レコードを追加することで)、これらの制限の一部を解消しました。We have lifted some of those limits by adding the ICorProfilerInfo7::ApplyMetaData method to support a subset of metadata edits after the module loads, in particular by adding new AssemblyRef, TypeRef, TypeSpec, MemberRef, MemberSpec, and UserString records. この変更により、はるかに広範な実行時インストルメンテーションが可能になります。This change makes a much broader range of on-the-fly instrumentation possible.

ネイティブ イメージ ジェネレーター (NGEN) PDBNative Image Generator (NGEN) PDBs

マシン間のイベント トレースを使用すれば、ユーザーはマシン A 上でプログラムのプロファイリングを行い、マシン B 上でソース行のマッピングを使用して、プロファイリング データを確認できます。以前のバージョンの.NET Framework を使用する場合、ソースからネイティブへのマッピングを作成するには、ユーザーは、プロファイルされたコンピューターにあるすべてのモジュールとネイティブ イメージを、IL PDB が含まれた分析用コンピューターにコピーする必要がありました。Cross-machine event tracing allows customers to profile a program on Machine A and look at the profiling data with source line mapping on Machine B. Using previous versions of the .NET Framework, the user would copy all the modules and native images from the profiled machine to the analysis machine that contains the IL PDB to create the source-to-native mapping. この処理は、Phone アプリケーションなどファイル サイズが比較的小さい場合には高速に実行されますが、これらのファイルのサイズがデスクトップ システム上で非常に大きくなる可能性があり、その場合コピーにかなりの時間を要する可能性があります。While this process may work well when the files are relatively small, such as for phone applications, the files can be very large on desktop systems and require significant time to copy.

NGen PDB を使用すれば、IL PDB に依存することなく、NGen で IL からネイティブへのマッピングが含まれた PDB を作成できます。With Ngen PDBs, NGen can create a PDB that contains the IL-to-native mapping without a dependency on the IL PDB. このマシン間のイベント トレース シナリオで必要なことは、コンピューター A で生成されたネイティブ イメージの PDB をコンピューター B にコピーすることと、Debug Interface Access API を使用して IL PDB のソースから IL へのマッピングとネイティブ イメージの PDB の IL からネイティブへのマッピングを読み取ることだけです。In our cross-machine event tracing scenario, all that is needed is to copy the native image PDB that is generated by Machine A to Machine B and to use Debug Interface Access APIs to read the IL PDB's source-to-IL mapping and the native image PDB's IL-to-native mapping. 両方のマッピングを組み合わせることで、ソースからネイティブへのマッピングが実現します。Combining both mappings provides a source-to-native mapping. ネイティブ イメージの PDB は、どのモジュールとネイティブ イメージよりもはるかにサイズが小さいため、コンピューター A からコンピューター B へのコピーの処理は非常に高速になります。Since the native image PDB is much smaller than all the modules and native images, the process of copying from Machine A to Machine B is much faster.

.NET 2015 の新機能What's new in .NET 2015

.NET 2015 では、.NET Framework 4.6 と .NET Core が導入されています。.NET 2015 introduces the .NET Framework 4.6 and .NET Core. 一部の新機能はその両方に適用され、その他の機能は .NET Framework 4.6 または .NET Core に固有です。Some new features apply to both, and other features are specific to .NET Framework 4.6 or .NET Core.

  • ASP.NET CoreASP.NET Core

    .NET 2015 には、ASP.NET Core が含まれています。これは、最新のクラウド ベースのアプリを構築するのに効率的な .NET 実装です。.NET 2015 includes ASP.NET Core, which is a lean .NET implementation for building modern cloud-based apps. ASP.NET Core はモジュール形式であるため、ご利用のアプリケーションで必要な機能のみを含めることができます。ASP.NET Core is modular so you can include only those features that are needed in your application. IIS でホストすることも、カスタムのプロセスでセルフホストすることもできます。さらに同じサーバー上のさまざまなバージョンの .NET Framework でアプリを実行することも可能です。It can be hosted on IIS or self-hosted in a custom process, and you can run apps with different versions of the .NET Framework on the same server. クラウド展開用に設計されている新たな環境構成システムが含まれています。It includes a new environment configuration system that is designed for cloud deployment.

    MVC、Web API、および Web ページは、MVC 6 と呼ばれる 1 つのフレームワークに統合されています。MVC, Web API, and Web Pages are unified into a single framework called MVC 6. Visual Studio 2015 以降のツールで ASP.NET Core アプリをビルドします。You build ASP.NET Core apps through tools in Visual Studio 2015 or later. 既存のアプリケーションは、この新しい .NET Framework で動作しますが、MVC 6 または SignalR 3 を使用するアプリをビルドするには Visual Studio 2015 以降のプロジェクト システムを使用する必要があります。Your existing applications will work on the new .NET Framework; however to build an app that uses MVC 6 or SignalR 3, you must use the project system in Visual Studio 2015 or later.

    詳細については、ASP.NET Core に関するページを参照してください。For information, see ASP.NET Core.

  • ASP.NET の更新プログラムASP.NET Updates

    • 非同期応答フラッシュ用のタスク ベース APITask-based API for Asynchronous Response Flushing

      ASP.NET で、非同期応答フラッシュ用の単純なタスク ベース API である HttpResponse.FlushAsync が提供されるようになりました。これにより、言語の async/await サポートを使用して非同期的に応答をフラッシュできます。ASP.NET now provides a simple task-based API for asynchronous response flushing, HttpResponse.FlushAsync, that allows responses to be flushed asynchronously by using your language's async/await support.

    • モデル バインドによるタスクを返すメソッドのサポートModel binding supports task-returning methods

      .NET Framework 4.5 では、Web フォーム ページやユーザー コントロールでの CRUD ベースのデータ操作に対して拡張可能なコード中心のアプローチを可能にするモデル バインド機能が ASP.NET に追加されました。In the .NET Framework 4.5, ASP.NET added the Model Binding feature that enabled an extensible, code-focused approach to CRUD-based data operations in Web Forms pages and user controls. このモデル バインド システムで、Task を返すモデル バインド メソッドがサポートされるようになりました。The Model Binding system now supports Task-returning model binding methods. この機能により、Web フォーム開発者は Entity Framework などの ORM の新しいバージョンを使用するときに、データ バインド システムのように簡単に非同期のスケーラビリティ上のメリットを得ることができます。This feature allows Web Forms developers to get the scalability benefits of async with the ease of the data-binding system when using newer versions of ORMs, including the Entity Framework.

      非同期モデル バインドは、aspnet:EnableAsyncModelBinding 構成設定によって制御されます。Async model binding is controlled by the aspnet:EnableAsyncModelBinding configuration setting.

          <add key=" aspnet:EnableAsyncModelBinding" value="true|false" />

      .NET Framework 4.6 を対象とするアプリでは、既定で true になります。On apps the target the .NET Framework 4.6, it defaults to true. .NET Framework 4.6 で実行され、.NET Framework の以前のバージョンを対象とするアプリでは、既定で false になります。On apps running on the .NET Framework 4.6 that target an earlier version of the .NET Framework, it is false by default. 有効にするには、この構成設定を true に設定します。It can be enabled by setting the configuration setting to true.

    • HTTP/2 のサポート (Windows 10)HTTP/2 Support (Windows 10)

      HTTP/2 は HTTP プロトコルの新しいバージョンで、接続の使用状況が (クライアントとサーバー間のラウンド トリップ数の減少により) 大幅に改善されて、ユーザーが Web ページを読み込むときの遅延が軽減されています。HTTP/2 is a new version of the HTTP protocol that provides much better connection utilization (fewer round-trips between client and server), resulting in lower latency web page loading for users. このプロトコルは単一のエクスペリエンスの一部として要求さる複数の成果物のために最適化されているので、HTTP/2 が最も役立つのは (サービスではなく) web ページです。Web pages (as opposed to services) benefit the most from HTTP/2, since the protocol optimizes for multiple artifacts being requested as part of a single experience. .NET Framework 4.6 では、HTTP/2 のサポートが ASP.NET に追加されました。HTTP/2 support has been added to ASP.NET in .NET Framework 4.6. ネットワーク機能は複数のレイヤーで存在するので、HTTP/2 を有効にするために、Windows、IIS、および ASP.NET で新機能が必要とされていました。Because networking functionality exists at multiple layers, new features were required in Windows, in IIS, and in ASP.NET to enable HTTP/2. ASP.NET で HTTP/2 を使用するには、Windows 10 を実行している必要があります。You must be running on Windows 10 to use HTTP/2 with ASP.NET.

      HTTP/2 は、System.Net.Http.HttpClient API を使用する Windows 10 ユニバーサル Windows プラットフォーム (UWP) アプリでもサポートされ、既定で有効になります。HTTP/2 is also supported and on by default for Windows 10 Universal Windows Platform (UWP) apps that use the System.Net.Http.HttpClient API.

      ASP.NET アプリケーションで PUSH_PROMISE 機能を使用する手段を提供するために、PushPromise(String)PushPromise(String, String, NameValueCollection) の 2 つのオーバーロードを持つ新しいメソッドが HttpResponse クラスに追加されました。In order to provide a way to use the PUSH_PROMISE feature in ASP.NET applications, a new method with two overloads, PushPromise(String) and PushPromise(String, String, NameValueCollection), has been added to the HttpResponse class.


      ASP.NET Core では HTTP/2 がサポートされますが、PUSH PROMISE 機能のサポートはまだ追加されていません。While ASP.NET Core supports HTTP/2, support for the PUSH PROMISE feature has not yet been added.

      ブラウザーと web サーバー (Windows 上の IIS) がすべての処理を実行します。The browser and the web server (IIS on Windows) do all the work. ユーザーの側で複雑な操作を実行する必要はありません。You don't have to do any heavy-lifting for your users.

      主要なブラウザーのほとんどは HTTP/2 をサポートしているため、多くの場合、サーバーが HTTP/2 をサポートしていれば、ユーザーもそのメリットを得ることができます。Most of the major browsers support HTTP/2, so it's likely that your users will benefit from HTTP/2 support if your server supports it.

    • トークン バインディング プロトコルのサポートSupport for the Token Binding Protocol

      Microsoft と Google は、トークン バインディング プロトコルと呼ばれる、認証のための新しいアプローチに共同で取り組んできました。Microsoft and Google have been collaborating on a new approach to authentication, called the Token Binding Protocol. この前提となっているのは、犯罪者が (ブラウザー キャッシュ内の) 認証トークンを盗用することで、本来ならパスワードや他の特別な情報でセキュリティ保護されているリソース (銀行口座など) にアクセスできる可能性がある、ということです。The premise is that authentication tokens (in your browser cache) can be stolen and used by criminals to access otherwise secure resources (for example, your bank account) without requiring your password or any other privileged knowledge. 新しいプロトコルは、この問題を軽減することを目指しています。The new protocol aims to mitigate this problem.

      トークン バインディング プロトコルは、Windows 10 でブラウザーの機能として実装されます。The Token Binding Protocol will be implemented in Windows 10 as a browser feature. ASP.NET アプリは、認証トークンの正当性が検証されるように、このプロトコルに参加します。ASP.NET apps will participate in the protocol, so that authentication tokens are validated to be legitimate. クライアントとサーバーの実装は、プロトコルによって指定されるエンド ツー エンドの保護を確立します。The client and the server implementations establish the end-to-end protection specified by the protocol.

    • ランダムな文字列のハッシュ アルゴリズムRandomized string hash algorithms

      .NET Framework 4.5 で、ランダム化された文字列のハッシュ アルゴリズムが導入されました。.NET Framework 4.5 introduced a randomized string hash algorithm. しかし、ASP.NET の一部の機能は安定したハッシュ コードに依存していたため、この機能は ASP.NET ではサポートされませんでした。However, it was not supported by ASP.NET because of some ASP.NET features depended on a stable hash code. .NET Framework 4.6 では、ランダムな文字列のハッシュ アルゴリズムがサポートされるようになりました。In .NET Framework 4.6, randomized string hash algorithms are now supported. この機能を有効にするには、aspnet:UseRandomizedStringHashAlgorithm 構成設定を使用します。To enable this feature, use the aspnet:UseRandomizedStringHashAlgorithm config setting.

          <add key="aspnet:UseRandomizedStringHashAlgorithm" value="true|false" />

    ADO .NET では、SQL Server 2016 Community Technology Preview 2 (CTP2) で使用できる Always Encrypted 機能がサポートされました。ADO .NET now supports the Always Encrypted feature available in SQL Server 2016 Community Technology Preview 2 (CTP2). SQL Server は、Always Encrypted 機能を使用して、暗号化されたデータに対して操作を実行できます。特に、サーバー上ではなく、ユーザーが信頼している環境内にアプリケーションと共に暗号化キーを保存できるようになりました。With Always Encrypted, SQL Server can perform operations on encrypted data, and best of all the encryption key resides with the application inside the customer’s trusted environment and not on the server. Always Encrypted でユーザー データが保護されるので、DBA はプレーン テキスト データにアクセスできません。Always Encrypted secures customer data so DBAs do not have access to plain text data. データの暗号化と復号化は、ドライバー レベルで透過的に行われるので、既存のアプリケーションに対する変更が最小限に抑えられます。Encryption and decryption of data happens transparently at the driver level, minimizing changes that have to be made to existing applications. 詳細については、「Always Encrypted (データベース エンジン)」および「Always Encrypted (クライアント開発)」を参照してください。For details, see Always Encrypted (Database Engine) and Always Encrypted (client development).

  • マネージド コードの JIT コンパイラ (64 ビット)64-bit JIT Compiler for managed code

    .NET Framework 4.6 の特徴の 1 つとして、新しいバージョンの 64 ビット JIT コンパイラ (RyuJIT というコードネームで呼ばれていたもの) があります。.NET Framework 4.6 features a new version of the 64-bit JIT compiler (originally code-named RyuJIT). この新しい 64 ビット コンパイラは、これまでの 64 ビット JIT コンパイラよりもパフォーマンスが大幅に向上しています。The new 64-bit compiler provides significant performance improvements over the older 64-bit JIT compiler. 新しい 64 ビット コンパイラは、.NET Framework 4.6 上で実行される 64 ビット プロセスで有効になります。The new 64-bit compiler is enabled for 64-bit processes running on top of .NET Framework 4.6. 64 ビットまたは AnyCPU としてコンパイルされ、64 ビット オペレーティング システム上で実行されるアプリは、64 ビットで動作します。Your app will run in a 64-bit process if it is compiled as 64-bit or AnyCPU and is running on a 64-bit operating system. 新しいコンパイラへの移行をできる限り透過的に行うように注意を払いましたが、動作の変更が発生する可能性があります。While care has been taken to make the transition to the new compiler as transparent as possible, changes in behavior are possible.

    新しい 64 ビット JIT コンパイラには、ハードウェア SIMD アクセラレータ機能も含まれています。これを System.Numerics 名前空間の SIMD 対応の型と組み合わせると、パフォーマンスが大幅に向上する可能性があります。The new 64-bit JIT compiler also includes hardware SIMD acceleration features when coupled with SIMD-enabled types in the System.Numerics namespace, which can yield good performance improvements.

  • アセンブリ ローダーの改善Assembly loader improvements

    アセンブリ ローダーで、対応する NGEN イメージの読み込み後に IL アセンブリをアンロードすることにより、メモリがより効率的に使用されるようになりました。The assembly loader now uses memory more efficiently by unloading IL assemblies after a corresponding NGEN image is loaded. この変更は、仮想メモリが減少するため、特に大規模な 32 ビット アプリ (Visual Studio など) で有益であり、物理メモリの節約にもなります。This change decreases virtual memory, which is particularly beneficial for large 32-bit apps (such as Visual Studio), and also saves physical memory.

  • 基本クラス ライブラリの変更点Base class library changes

    主なシナリオを利用できるようにするため、多くの新しい API が .NET Framework 4.6 に関連して追加されました。Many new APIs have been added around to .NET Framework 4.6 to enable key scenarios. 変更点と追加点を以下に示します。These include the following changes and additions:

    • IReadOnlyCollection<T> implementationsIReadOnlyCollection<T> implementations

      追加のコレクション IReadOnlyCollection<T> (Queue<T>Stack<T> など) が実装されています。Additional collections implement IReadOnlyCollection<T> such as Queue<T> and Stack<T>.

    • CultureInfo.CurrentCulture と CultureInfo.CurrentUICultureCultureInfo.CurrentCulture and CultureInfo.CurrentUICulture

      CultureInfo.CurrentCulture プロパティと CultureInfo.CurrentUICulture プロパティが読み取り専用ではなく、読み取り/書き込み可能になりました。The CultureInfo.CurrentCulture and CultureInfo.CurrentUICulture properties are now read-write rather than read-only. 新しい CultureInfo オブジェクトをこれらのプロパティに割り当てると、Thread.CurrentThread.CurrentCulture プロパティで現在定義されているスレッド カルチャと、Thread.CurrentThread.CurrentUICulture プロパティで現在定義されている UI スレッド カルチャも変更されます。If you assign a new CultureInfo object to these properties, the current thread culture defined by the Thread.CurrentThread.CurrentCulture property and the current UI thread culture defined by the Thread.CurrentThread.CurrentUICulture properties also change.

    • ガベージ コレクション (GC) の機能強化Enhancements to garbage collection (GC)

      GC クラスに TryStartNoGCRegion メソッドと EndNoGCRegion メソッドが含まれるようになりました。これらのメソッドを使用するとクリティカル パスの実行中にガベージ コレクションを不許可にできます。The GC class now includes TryStartNoGCRegion and EndNoGCRegion methods that allow you to disallow garbage collection during the execution of a critical path.

      GC.Collect(Int32, GCCollectionMode, Boolean, Boolean) メソッドの新しいオーバーロードを使用して、小さなオブジェクト ヒープと大きなオブジェクト ヒープの両方に関して、スイープして圧縮するのか、スイープのみを行うのかを制御できます。A new overload of the GC.Collect(Int32, GCCollectionMode, Boolean, Boolean) method allows you to control whether both the small object heap and the large object heap are swept and compacted or swept only.

    • SIMD が有効な型SIMD-enabled types

      System.Numerics 名前空間には、Matrix3x2Matrix4x4PlaneQuaternionVector2Vector3Vector4 など、いくつかの SIMD 対応の型が含まれるようになりました。The System.Numerics namespace now includes a number of SIMD-enabled types, such as Matrix3x2, Matrix4x4, Plane, Quaternion, Vector2, Vector3, and Vector4.

      新しい 64 ビット JIT コンパイラにはハードウェア SIMD アクセラレータ機能も含まれているため、新しい 64 ビット JIT コンパイラで SIMD 対応の型を使用すると、パフォーマンスが大幅に向上します。Because the new 64-bit JIT compiler also includes hardware SIMD acceleration features, there are especially significant performance improvements when using the SIMD-enabled types with the new 64-bit JIT compiler.

    • 暗号の更新Cryptography updates

      System.Security.Cryptography API は、Windows CNG 暗号化 API をサポートするために更新中です。The System.Security.Cryptography API is being updated to support the Windows CNG cryptography APIs. 以前のバージョンの .NET Framework は、System.Security.Cryptography の実装の基礎として、それより前のバージョンの Windows 暗号化 API に完全に依存していました。Previous versions of the .NET Framework have relied entirely on an earlier version of the Windows Cryptography APIs as the basis for the System.Security.Cryptography implementation. CNG API は特定のカテゴリのアプリにとって重要な最新の暗号アルゴリズムをサポートするものであるため、CNG API をサポートしてほしいというリクエストが寄せられていました。We have had requests to support the CNG API, since it supports modern cryptography algorithms, which are important for certain categories of apps.

      .NET Framework 4.6 には、Windows CNG 暗号化 API をサポートするために、次の新しい機能強化が含まれています。.NET Framework 4.6 includes the following new enhancements to support the Windows CNG cryptography APIs:

      • 可能な場合に CAPI ベースの実装ではなく CNG ベースの実装を返す X509 証明書用の一連の拡張メソッド System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPublicKey(System.Security.Cryptography.X509Certificates.X509Certificate2) および System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPrivateKey(System.Security.Cryptography.X509Certificates.X509Certificate2)A set of extension methods for X509 Certificates, System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPublicKey(System.Security.Cryptography.X509Certificates.X509Certificate2) and System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPrivateKey(System.Security.Cryptography.X509Certificates.X509Certificate2), that return a CNG-based implementation rather than a CAPI-based implementation when possible. (一部のスマート カードなどでは現在も CAPI が必要であり、API がフォールバックを処理します)。(Some smartcards, etc., still require CAPI, and the APIs handle the fallback).

      • RSA アルゴリズムの CNG 実装を提供する System.Security.Cryptography.RSACng クラス。The System.Security.Cryptography.RSACng class, which provides a CNG implementation of the RSA algorithm.

      • 一般的な操作でキャストを不要にする RSA API の機能強化。Enhancements to the RSA API so that common actions no longer require casting. たとえば、以前のバージョンの .NET Framework で X509Certificate2 オブジェクトを使用してデータを暗号化するには、次のようなコードが必要です。For example, encrypting data using an X509Certificate2 object requires code like the following in previous versions of the .NET Framework.

        RSACryptoServiceProvider rsa = (RSACryptoServiceProvider)cert.PrivateKey;
        byte[] oaepEncrypted = rsa.Encrypt(data, true);
        byte[] pkcs1Encrypted = rsa.Encrypt(data, false);
        Dim rsa As RSACryptoServiceProvider = CType(cert.PrivateKey, RSACryptoServiceProvider)
        Dim oaepEncrypted() As Byte = rsa.Encrypt(data, True)
        Dim pkcs1Encrypted() As Byte = rsa.Encrypt(data, False)

        .NET Framework 4.6 で新しい暗号化を使用するコードは、次のように書き換えてキャストを回避することができます。Code that uses the new cryptography APIs in .NET Framework 4.6 can be rewritten as follows to avoid the cast.

        RSA rsa = cert.GetRSAPrivateKey();
        if (rsa == null)
           throw new InvalidOperationException("An RSA certificate was expected");
        byte[] oaepEncrypted = rsa.Encrypt(data, RSAEncryptionPadding.OaepSHA1);
        byte[] pkcs1Encrypted = rsa.Encrypt(data, RSAEncryptionPadding.Pkcs1);
        Dim rsa As RSA = cert.GetRSAPrivateKey()
        If rsa Is Nothing Then
           Throw New InvalidOperationException("An RSA certificate was expected")
         End If
        Dim oaepEncrypted() As Byte = rsa.Encrypt(data, RSAEncryptionPadding.OaepSHA1)
        Dim pkcs1Encrypted() As Byte = rsa.Encrypt(data, RSAEncryptionPadding.Pkcs1)
    • 日付および時間と UNIX 時間の変換のサポートSupport for converting dates and times to or from Unix time

      日付値および時間値と UNIX 時間の変換をサポートするため、次の新しいメソッドが DateTimeOffset 構造体に追加されました。The following new methods have been added to the DateTimeOffset structure to support converting date and time values to or from Unix time:

    • 互換性スイッチCompatibility switches

      AppContext クラスでは、ライブラリの作成者が統一された新機能のオプトアウト メカニズムをユーザーに提供できるようにする、新しい互換性機能を追加します。The AppContext class adds a new compatibility feature that enables library writers to provide a uniform opt-out mechanism for new functionality for their users. これにより、オプトアウト要求を伝達するために、コンポーネント間に疎結合のコントラクトが確立されます。It establishes a loosely coupled contract between components in order to communicate an opt-out request. 通常、この機能は既存の機能が変更されるときに重要となります。This capability is typically important when a change is made to existing functionality. それに対して、新しい機能には暗黙のオプトインが既に存在しています。Conversely, there is already an implicit opt-in for new functionality.

      AppContext によって、ライブラリは互換性スイッチを定義して公開します。また、それらに依存するコードは、それらのスイッチを設定してライブラリの動作に影響を与えることができます。With AppContext, libraries define and expose compatibility switches, while code that depends on them can set those switches to affect the library behavior. ライブラリは、既定では新しい機能を提供し、スイッチが設定されている場合のみそれを変更する (つまり以前の機能を提供する) ことができます。By default, libraries provide the new functionality, and they only alter it (that is, they provide the previous functionality) if the switch is set.

      アプリケーション (またはライブラリ) は、依存するライブラリが定義したスイッチの値 (常に Boolean 値) を宣言できます。An application (or a library) can declare the value of a switch (which is always a Boolean value) that a dependent library defines. スイッチは常に暗黙的に false です。The switch is always implicitly false. スイッチを true に設定すると、それが有効になります。Setting the switch to true enables it. スイッチを明示的に false に設定すると、新しい動作が提供されます。Explicitly setting the switch to false provides the new behavior.

      AppContext.SetSwitch("Switch.AmazingLib.ThrowOnException", true);
      AppContext.SetSwitch("Switch.AmazingLib.ThrowOnException", True)

      ライブラリは、コンシューマーがスイッチの値を宣言したことを確認してから、それを適切に実行する必要があります。The library must check if a consumer has declared the value of the switch and then appropriately act on it.

      if (!AppContext.TryGetSwitch("Switch.AmazingLib.ThrowOnException", out shouldThrow))
          // This is the case where the switch value was not set by the application.
          // The library can choose to get the value of shouldThrow by other means.
          // If no overrides nor default values are specified, the value should be 'false'.
          // A false value implies the latest behavior.
      // The library can use the value of shouldThrow to throw exceptions or not.
      if (shouldThrow)
          // old code
          // new code
      If Not AppContext.TryGetSwitch("Switch.AmazingLib.ThrowOnException", shouldThrow) Then
          ' This is the case where the switch value was not set by the application.
          ' The library can choose to get the value of shouldThrow by other means.
          ' If no overrides nor default values are specified, the value should be 'false'.
          ' A false value implies the latest behavior.
      End If
      ' The library can use the value of shouldThrow to throw exceptions or not.
      If shouldThrow Then
          ' old code
          ' new code
      End If

      スイッチは、ライブラリによって公開される正式なコントラクトであるため、一貫性のある形式を使用することをお勧めします。It's beneficial to use a consistent format for switches, since they are a formal contract exposed by a library. 2 つの明確な形式を次に示します。The following are two obvious formats.

      • Switch.namespace.switchnameSwitch.namespace.switchname

      • Switch.library.switchnameSwitch.library.switchname

    • タスク ベースの非同期パターン (TAP) の変更点Changes to the task-based asynchronous pattern (TAP)

      .NET Framework 4.6 をターゲットとするアプリの場合、Task および Task<TResult> オブジェクトは、呼び出し元のスレッドのカルチャと UI カルチャを継承します。For apps that target the .NET Framework 4.6, Task and Task<TResult> objects inherit the culture and UI culture of the calling thread. 以前のバージョンの .NET Framework をターゲットするとアプリまたは特定のバージョンの .NET Framework をターゲットとしないアプリの動作には影響を及ぼしません。The behavior of apps that target previous versions of the .NET Framework, or that do not target a specific version of the .NET Framework, is unaffected. 詳細については、CultureInfo クラスのトピックの「カルチャとタスク ベースの非同期の操作」セクションをご覧ください。For more information, see the "Culture and task-based asynchronous operations" section of the CultureInfo class topic.

      System.Threading.AsyncLocal<T> クラスを使用すると、async メソッドなど、特定の非同期制御フローに対してローカルなアンビエント データを表すことができます。The System.Threading.AsyncLocal<T> class allows you to represent ambient data that is local to a given asynchronous control flow, such as an async method. これは、スレッド間でデータを保持するために使用できます。It can be used to persist data across threads. AsyncLocal<T>.Value プロパティの明示的な変更やスレッドでのコンテキスト変換の発生などによってアンビエント データが変更されるたびに通知されるコールバック メソッドを定義することもできます。You can also define a callback method that is notified whenever the ambient data changes either because the AsyncLocal<T>.Value property was explicitly changed, or because the thread encountered a context transition.

      タスク ベースの非同期パターン (TAP) に、特定の状態で完了したタスクを返す 3 つの便利なメソッド Task.CompletedTaskTask.FromCanceled、および Task.FromException が追加されました。Three convenience methods, Task.CompletedTask, Task.FromCanceled, and Task.FromException, have been added to the task-based asynchronous pattern (TAP) to return completed tasks in a particular state.

      NamedPipeClientStream クラスで、新しい ConnectAsync メソッドによる非同期通信がサポートされるようになりました。The NamedPipeClientStream class now supports asynchronous communication with its new ConnectAsync. メソッドをオーバーライドします。method.

    • EventSource がイベント ログへの書き込みをサポートEventSource now supports writing to the Event log

      コンピューター上で作成された既存の ETW セッションに加えて、EventSource クラスを使用して管理または操作メッセージをイベント ログに記録できるようになりました。You now can use the EventSource class to log administrative or operational messages to the event log, in addition to any existing ETW sessions created on the machine. 以前は、この機能のために Microsoft.Diagnostics.Tracing.EventSource NuGet パッケージを使用する必要がありました。In the past, you had to use the Microsoft.Diagnostics.Tracing.EventSource NuGet package for this functionality. この機能は .NET Framework 4.6 に組み込まれました。This functionality is now built-into .NET Framework 4.6.

      NuGet パッケージと .NET Framework 4.6 は、どちらも次の機能によって更新されています。Both the NuGet package and .NET Framework 4.6 have been updated with the following features:

      • ダイナミック イベントDynamic events

        イベント メソッドを作成せずに、実行時にイベントを定義できます。Allows events defined "on the fly" without creating event methods.

      • リッチ ペイロードRich payloads

        特別な属性が指定されたクラスや配列に加えて、プリミティブ型もペイロードとして渡すことができます。Allows specially attributed classes and arrays as well as primitive types to be passed as a payload

      • アクティビティの追跡Activity tracking

        Start イベントと Stop イベントの間のイベントに、現在アクティブなすべてのアクティビティを表す ID が付けられます。Causes Start and Stop events to tag events between them with an ID that represents all currently active activities.

      これらの機能をサポートするため、EventSource クラスにオーバーロードされた Write メソッドが追加されました。To support these features, the overloaded Write method has been added to the EventSource class.

  • Windows Presentation Foundation (WPF)Windows Presentation Foundation (WPF)

    • HDPI の強化HDPI improvements

      .NET Framework 4.6 では、WPF での HDPI サポートが強化されました。HDPI support in WPF is now better in the .NET Framework 4.6. 境界があるコントロールでのクリッピングの発生を減らすため、レイアウトの丸め処理が変更されました。Changes have been made to layout rounding to reduce instances of clipping in controls with borders. 既定では、TargetFrameworkAttribute が .NET 4.6 に設定されている場合にのみ、この機能が有効になります。By default, this feature is enabled only if your TargetFrameworkAttribute is set to .NET 4.6. 以前のバージョンの Framework を対象とするアプリケーションが .NET Framework 4.6 で実行される場合は、app.config ファイルの <runtime> セクションに次の行を追加することで、新しい動作を選択できます。Applications that target earlier versions of the framework but are running on the .NET Framework 4.6 can opt in to the new behavior by adding the following line to the <runtime> section of the app.config file:


      異なる DPI 設定を持つ (マルチ DPI セットアップの) 複数のモニターにまたがる WPF ウィンドウは、ブラック アウト領域なしで完全にレンダリングされるようになりました。WPF windows straddling multiple monitors with different DPI settings (Multi-DPI setup) are now completely rendered without blacked-out regions. この動作の選択を解除するには、app.config ファイルの <appSettings> セクションに次の行を追加して、この新しい動作を無効にします。You can opt out of this behavior by adding the following line to the <appSettings> section of the app.config file to disable this new behavior:

      <add key="EnableMultiMonitorDisplayClipping" value="true"/>

      DPI 設定に基づいて自動的に正しいカーソルを読み込む機能のサポートが System.Windows.Input.Cursor に追加されました。Support for automatically loading the right cursor based on DPI setting has been added to System.Windows.Input.Cursor.

    • タッチの改善Touch is better

      タッチで予期しない動作が発生するという、お客様から報告された Connect の問題が .NET Framework 4.6 で対処されました。Customer reports on Connect that touch produces unpredictable behavior have been addressed in the .NET Framework 4.6. Windows 8.1 以降では、Windows ストア アプリケーションと WPF アプリケーションのダブルタップのしきい値が同じになりました。The double tap threshold for Windows Store applications and WPF applications is now the same in Windows 8.1 and above.

    • 透過的な子ウィンドウのサポートTransparent child window support

      .NET Framework 4.6 の WPF では、Windows 8.1 以降の透過的な子ウィンドウがサポートされます。WPF in the .NET Framework 4.6 supports transparent child windows in Windows 8.1 and above. これにより、最上位レベルのウィンドウ内に四角形でない透過的な子ウィンドウを作成できます。This allows you to create non-rectangular and transparent child windows in your top-level windows. この機能を有効にするには、HwndSourceParameters.UsesPerPixelTransparency プロパティを true に設定します。You can enable this feature by setting the HwndSourceParameters.UsesPerPixelTransparency property to true.

  • Windows Communication Foundation (WCF)Windows Communication Foundation (WCF)

    • SSL のサポートSSL support

      WCF で、NetTcp をトランスポート セキュリティおよびクライアント認証と共に使用する場合に、SSL のバージョンとして SSL 3.0 および TLS 1.0 に加えて TLS 1.1 および TLS 1.2 がサポートされるようになりました。WCF now supports SSL version TLS 1.1 and TLS 1.2, in addition to SSL 3.0 and TLS 1.0, when using NetTcp with transport security and client authentication. 使用するプロトコルを選択することも、安全性の低い古いプロトコルを無効化することもできるようになりました。It is now possible to select which protocol to use, or to disable old lesser secure protocols. これを行うには、SslProtocols プロパティを設定するか、または構成ファイルに以下を追加します。This can be done either by setting the SslProtocols property or by adding the following to a configuration file.

            <security mode= "None|Transport|Message|TransportWithMessageCredential" >
                <transport clientCredentialType="None|Windows|Certificate"
    • 異なる HTTP 接続によるメッセージの送信Sending messages using different HTTP connections

      WCF で、ユーザーが別の基になる HTTP 接続を使用して特定のメッセージを送信できるようになりました。WCF now allows users to ensure certain messages are sent using different underlying HTTP connections. これには、2 つの方法があります。There are two ways to do this:

      • 接続グループ名プレフィックスの使用Using a connection group name prefix

        ユーザーは、WCF で接続グループ名のプレフィックスとして使用される文字列を指定できます。Users can specify a string that WCF will use as a prefix for the connection group name. 異なるプレフィックスを持つ 2 つのメッセージは、別の基になる HTTP 接続を使用して送信されます。Two messages with different prefixes are sent using different underlying HTTP connections. プレフィックスを設定するには、メッセージの Message.Properties プロパティにキー/値のペアを追加します。You set the prefix by adding a key/value pair to the message's Message.Properties property. キーは "HttpTransportConnectionGroupNamePrefix" で、値は使用するプレフィックスです。The key is "HttpTransportConnectionGroupNamePrefix"; the value is the desired prefix.

      • 異なるチャネル ファクトリの使用Using different channel factories

        ユーザーは、異なるチャネル ファクトリによって作成されたチャネルを使用して送信されるメッセージで別の基になる HTTP 接続を使用する機能を有効にすることもできます。Users can also enable a feature that ensures that messages sent using channels created by different channel factories will use different underlying HTTP connections. この機能を有効にするには、ユーザーが次の appSettingtrue に設定する必要があります。To enable this feature, users must set the following appSetting to true:

            <add key="wcf:httpTransportBinding:useUniqueConnectionPoolPerFactory" value="true" />
  • Windows Workflow Foundation (WWF)Windows Workflow Foundation (WWF)

    順序不定の操作要求がタイムアウトする前に未処理の "非プロトコル" ブックマークが存在する場合に、ワークフロー サービスが要求を保持する秒数を指定できるようになりました。You can now specify the number of seconds a workflow service will hold on to an out-of-order operation request when there is an outstanding "non-protocol" bookmark before timing out the request. "非プロトコル" ブックマークとは、未処理の Receive アクティビティに関連付けられていないブックマークです。A "non-protocol" bookmark is a bookmark that is not related to outstanding Receive activities. 一部のアクティビティはその実装内で非プロトコル ブックマークを作成するため、必ずしも非プロトコル ブックマークの存在が明らかにわかるとは限りません。Some activities create non-protocol bookmarks within their implementation, so it may not be obvious that a non-protocol bookmark exists. 例として State や Pick などがあります。These include State and Pick. ステート マシンを使用して実装されたワークフロー サービスや、Pick アクティビティを含むワークフロー サービスがある場合は、非プロトコル ブックマークが存在する可能性が高くなります。So if you have a workflow service implemented with a state machine or containing a Pick activity, you will most likely have non-protocol bookmarks. この間隔を指定するには、app.config ファイルの appSettings セクションに次のような行を追加します。You specify the interval by adding a line like the following to the appSettings section of your app.config file:

    <add key="microsoft:WorkflowServices:FilterResumeTimeoutInSeconds" value="60"/>

    既定値は 60 秒です。The default value is 60 seconds. value を 0 に設定すると、順序不定の要求はただちに拒否され、次のようなテキストを含むエラーが返されます。If value is set to 0, out-of-order requests are immediately rejected with a fault with text that looks like this:

    Operation 'Request3|{http://tempuri.org/}IService' on service instance with identifier '2b0667b6-09c8-4093-9d02-f6c67d534292' cannot be performed at this time. Please ensure that the operations are performed in the correct order and that the binding in use provides ordered delivery guarantees.

    これは、順序不定の操作メッセージを受信し、非プロトコル ブックマークが存在しない場合に受信するメッセージと同じです。This is the same message that you receive if an out-of-order operation message is received and there are no non-protocol bookmarks.

    FilterResumeTimeoutInSeconds 要素の値がゼロ以外で、非プロトコル ブックマークが存在し、タイムアウト間隔が終了した場合、その操作は失敗し、タイムアウト メッセージが発生します。If the value of the FilterResumeTimeoutInSeconds element is non-zero, there are non-protocol bookmarks, and the timeout interval expires, the operation fails with a timeout message.

  • トランザクションTransactions

    TransactionException から派生した例外がスローされる原因となったトランザクションに、分散トランザクション識別子を含めることができるようになりました。You can now include the distributed transaction identifier for the transaction that has caused an exception derived from TransactionException to be thrown. これを行うには、次のキーを app.config ファイルの appSettings セクションに追加します。You do this by adding the following key to the appSettings section of your app.config file:

    <add key="Transactions:IncludeDistributedTransactionIdInExceptionMessage" value="true"/>

    既定値は false です。The default value is false.

  • ネットワークNetworking

    • ソケットの再利用Socket reuse

      Windows 10 には、送信 TCP 接続のローカル ポートを再利用してコンピューターのリソースを効率的に使用する新しいスケーラビリティの高いネットワーク アルゴリズムが含まれています。Windows 10 includes a new high-scalability networking algorithm that makes better use of machine resources by reusing local ports for outbound TCP connections. .NET Framework 4.6 では、この新しいアルゴリズムがサポートされ、.NET アプリで新しい動作を利用できます。.NET Framework 4.6 supports the new algorithm, enabling .NET apps to take advantage of the new behavior. 以前のバージョンの Windows では、人工的なコンカレント接続の制限 (通常は動的なポート範囲の既定のサイズである 16,384) があったため、負荷がかかったときにポートが使い尽くされ、サービスのスケーラビリティが制限されることがありました。In previous versions of Windows, there was an artificial concurrent connection limit (typically 16,384, the default size of the dynamic port range), which could limit the scalability of a service by causing port exhaustion when under load.

      .NET Framework 4.6 では、ポートの再利用を有効にする次の 2 つの API が追加され、コンカレント接続に対する 64 KB の制限が実質的になくなりました。In .NET Framework 4.6, two APIs have been added to enable port reuse, which effectively removes the 64 KB limit on concurrent connections:

      既定では、HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 レジストリ キーの HWRPortReuseOnSocketBind の値が 0x1 に設定されないかぎり、ServicePointManager.ReusePort プロパティは false になります。By default, the ServicePointManager.ReusePort property is false unless the HWRPortReuseOnSocketBind value of the HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 registry key is set to 0x1. HTTP 接続でのローカル ポートの再利用を有効にするには、ServicePointManager.ReusePort プロパティを true に設定します。To enable local port reuse on HTTP connections, set the ServicePointManager.ReusePort property to true. これにより、HttpClient および HttpWebRequest からの外向きのすべての TCP ソケット接続で Windows 10 の新しいソケット オプション SO_REUSE_UNICASTPORT が使用されるようになるため、ローカル ポートの再利用が可能になります。This causes all outgoing TCP socket connections from HttpClient and HttpWebRequest to use a new Windows 10 socket option, SO_REUSE_UNICASTPORT, that enables local port reuse.

      ソケット専用のアプリケーションを作成する開発者は、Socket.SetSocketOption などのメソッドを呼び出すときに System.Net.Sockets.SocketOptionName オプションを指定することにより、送信ソケットでバインド中にローカル ポートを再利用できるようになります。Developers writing a sockets-only application can specify the System.Net.Sockets.SocketOptionName option when calling a method such as Socket.SetSocketOption so that outbound sockets reuse local ports during binding.

    • 国際ドメイン名と PunyCode のサポートSupport for international domain names and PunyCode

      Uri クラスに新しいプロパティ IdnHost が追加され、国際ドメイン名と PunyCode のサポートが強化されました。A new property, IdnHost, has been added to the Uri class to better support international domain names and PunyCode.

  • Windows フォーム コントロールでのサイズ変更Resizing in Windows Forms controls.

    この機能が .NET Framework 4.6 にも拡張されました。DomainUpDownNumericUpDownDataGridViewComboBoxColumnDataGridViewColumnToolStripSplitButton 型、および UITypeEditor を描画するときに使用する Bounds プロパティで指定される四角形も含まれるようになりました。This feature has been expanded in .NET Framework 4.6 to include the DomainUpDown, NumericUpDown, DataGridViewComboBoxColumn, DataGridViewColumn and ToolStripSplitButton types and the rectangle specified by the Bounds property used when drawing a UITypeEditor.

    これはオプトイン機能です。This is an opt-in feature. この機能を有効にするには、アプリケーション構成 (app.config) ファイルで EnableWindowsFormsHighDpiAutoResizing 要素を true に設定します。To enable it, set the EnableWindowsFormsHighDpiAutoResizing element to true in the application configuration (app.config) file:

        <add key="EnableWindowsFormsHighDpiAutoResizing" value="true" />
  • コード ページのエンコーディングのサポートSupport for code page encodings

    .NET Core は、本来 Unicode エンコードをサポートし、既定ではコード ページ エンコーディングに関するサポートは限定的です。.NET Core primarily supports the Unicode encodings and by default provides limited support for code page encodings. Encoding.RegisterProvider メソッドを使用してコード ページ エンコードを登録することで、.NET Framework では利用できるものの .NET Core ではサポートされていないコード ページ エンコードのサポートを追加できます。You can add support for code page encodings available in .NET Framework but unsupported in .NET Core by registering code page encodings with the Encoding.RegisterProvider method. 詳細については、「System.Text.CodePagesEncodingProvider」を参照してください。For more information, see System.Text.CodePagesEncodingProvider.

  • .NET ネイティブ.NET Native

    .NET Core をターゲットとし、C# または Visual Basic で作成されている Windows 10 用の Windows アプリは、IL ではなくネイティブ コードにアプリをコンパイルする新しい技術を活用できます。Windows apps for Windows 10 that target .NET Core and are written in C# or Visual Basic can take advantage of a new technology that compiles apps to native code rather than IL. これで、起動時間と実行時間がより速いアプリを生成できます。They produce apps characterized by faster startup and execution times. 詳しくは、「.NET ネイティブによるアプリのコンパイル」をご覧ください。For more information, see Compiling Apps with .NET Native. JIT コンパイルと NGEN による結果の違い、およびコードにおけるその影響の概要については、「.NET ネイティブとコンパイル」をご覧ください。For an overview of .NET Native that examines how it differs from both JIT compilation and NGEN and what that means for your code, see .NET Native and Compilation.

    ご利用のアプリは、Visual Studio 2015 以降でコンパイルするときに、既定でネイティブ コードにコンパイルされます。Your apps are compiled to native code by default when you compile them with Visual Studio 2015 or later. 詳しくは、「.NET ネイティブの概要」をご覧ください。For more information, see Getting Started with .NET Native.

    .NET ネイティブ アプリのデバッグをサポートするため、アンマネージ デバッグ APIに対して数多くの新しいインターフェイスと列挙型が追加されました。To support debugging .NET Native apps, a number of new interfaces and enumerations have been added to the unmanaged debugging API. 詳しくは、「デバッグ (アンマネージ API リファレンス)」をご覧ください。For more information, see the Debugging (Unmanaged API Reference) topic.

  • オープン ソースの .NET Framework パッケージOpen-source .NET Framework packages

    .NET Core のパッケージ (変更できないコレクションなど)、SIMD API、およびネットワーク API (System.Net.Http 名前空間に含まれるものなど) は、GitHub でオープンソース パッケージとして入手できるようになりました。.NET Core packages such as the immutable collections, SIMD APIs, and networking APIs such as those found in the System.Net.Http namespace are now available as open-source packages on GitHub. このコードにアクセスするには、GitHub 上の .NET をご覧ください。To access the code, see .NET on GitHub. これらのパッケージの詳細、および投稿方法については、「.NET Core とオープン ソース」および GitHub の .NET ホーム ページを参照してください。For more information and how to contribute to these packages, see .NET Core and Open-Source, .NET Home Page on GitHub.

.NET Framework 4.5.2 の新機能What's new in .NET Framework 4.5.2

  • ASP.NET アプリ用の新しい API。New APIs for ASP.NET apps. 新しい HttpResponse.AddOnSendingHeaders メソッドと HttpResponseBase.AddOnSendingHeaders メソッドにより、応答がクライアント アプリにフラッシュされる際の、応答ヘッダーと状態コードを確認および変更できます。The new HttpResponse.AddOnSendingHeaders and HttpResponseBase.AddOnSendingHeaders methods let you inspect and modify response headers and status code as the response is being flushed to the client app. PreSendRequestHeaders イベントや PreSendRequestContent イベントの代わりに、より効率的で信頼性の高いこれらのメソッドの使用を検討してください。Consider using these methods instead of the PreSendRequestHeaders and PreSendRequestContent events; they are more efficient and reliable.

    HostingEnvironment.QueueBackgroundWorkItem メソッドにより、小さなバックグラウンド作業項目をスケジュールできます。The HostingEnvironment.QueueBackgroundWorkItem method lets you schedule small background work items. ASP.NET はこれらの項目を追跡し、すべてのバックグラウンド作業項目が完了するまで IIS が突然ワーカー プロセスを終了しないようにします。ASP.NET tracks these items and prevents IIS from abruptly terminating the worker process until all background work items have completed. このメソッドは、ASP.NET マネージド アプリ ドメインの外部で呼び出すことはできません。This method can't be called outside an ASP.NET managed app domain.

    新しい HttpResponse.HeadersWritten プロパティと HttpResponseBase.HeadersWritten プロパティは、応答ヘッダーが書き込まれたかどうかを示すブール値を返します。The new HttpResponse.HeadersWritten and HttpResponseBase.HeadersWritten properties return Boolean values that indicate whether the response headers have been written. これらのプロパティを使用して、HttpResponse.StatusCode (ヘッダーが書き込まれた場合に例外をスローする) などの API への呼び出しが成功することを確認できます。You can use these properties to make sure that calls to APIs such as HttpResponse.StatusCode (which throw exceptions if the headers have been written) will succeed.

  • Windows フォーム コントロールでのサイズ変更Resizing in Windows Forms controls. この機能が拡張されました。This feature has been expanded. これにより、システム DPI 設定を使用して、次の追加コントロールのコンポーネント (例: コンボ ボックスのドロップダウン矢印) をサイズ変更できます。You can now use the system DPI setting to resize components of the following additional controls (for example, the drop-down arrow in combo boxes):

    これはオプトイン機能です。This is an opt-in feature. この機能を有効にするには、アプリケーション構成 (app.config) ファイルで EnableWindowsFormsHighDpiAutoResizing 要素を true に設定します。To enable it, set the EnableWindowsFormsHighDpiAutoResizing element to true in the application configuration (app.config) file:

        <add key="EnableWindowsFormsHighDpiAutoResizing" value="true" />
  • 新しいワークフロー機能。New workflow feature. EnlistPromotableSinglePhase メソッドを使用している (および、結果として IPromotableSinglePhaseNotification インターフェイスを実装している) リソース マネージャーは、新しい Transaction.PromoteAndEnlistDurable メソッドを使用して、次の事柄を要求できます。A resource manager that's using the EnlistPromotableSinglePhase method (and therefore implementing the IPromotableSinglePhaseNotification interface) can use the new Transaction.PromoteAndEnlistDurable method to request the following:

    これは同じアプリ ドメイン内で実行でき、MSDTC とやり取りして昇格を実行するためにアンマネージ コードを追加する必要はありません。This can be done within the same app domain, and doesn't require any extra unmanaged code to interact with MSDTC to perform the promotion. System.Transactions から昇格可能な登録リストにより実装された IPromotableSinglePhaseNotificationPromote メソッドへの未処理の呼び出しがある場合のみ、この新しいメソッドを呼び出すことができます。The new method can be called only when there's an outstanding call from System.Transactions to the IPromotableSinglePhaseNotificationPromote method that's implemented by the promotable enlistment.

  • プロファイリングの機能強化。Profiling improvements. 次の新しいアンマネージ プロファイリング API により、さらに信頼性の高いプロファイリングを提供します。The following new unmanaged profiling APIs provide more robust profiling:

    以前の ICorProfiler の実装は、依存アセンブリの遅延読み込みをサポートしていました。Previous ICorProfiler implementations supported lazy loading of dependent assemblies. 新しいプロファイリング API では、プロファイラーにより挿入される依存アセンブリを、アプリの完全な初期化後に読み込むのではなく、すぐに読み込む必要があります。The new profiling APIs require dependent assemblies that are injected by the profiler to be loadable immediately, instead of being loaded after the app is fully initialized. この変更は、既存の ICorProfiler API のユーザーには影響しません。This change doesn't affect users of the existing ICorProfiler APIs.

  • デバッグの機能強化。Debugging improvements. 次の新しいアンマネージド デバッグ API により、プロファイラーとの統合性が向上しました。The following new unmanaged debugging APIs provide better integration with a profiler. これにより、ダンプのデバッグ時にコンパイラ ReJIT 要求により作成されたローカル変数やコードだけでなく、プロファイラーにより挿入されたメタデータにアクセスできます。You can now access metadata inserted by the profiler as well as local variables and code produced by compiler ReJIT requests when dump debugging.

  • イベント トレーシングの変更。Event tracing changes. .NET Framework 4.5.2 では、より大きなサーフェイス領域において、アウトプロセスの Windows イベント トレーシング (ETW) に基づくアクティビティ トレーシングができるようになりました。.NET Framework 4.5.2 enables out-of-process, Event Tracing for Windows (ETW)-based activity tracing for a larger surface area. これにより、アドバンスト パワー マネージメント (APM) ベンダーは、スレッドを越えた個々の要求とアクティビティのコストを正確に追跡する軽量ツールを提供できます。This enables Advanced Power Management (APM) vendors to provide lightweight tools that accurately track the costs of individual requests and activities that cross threads. これらのイベントは、ETW コントローラーで有効にされた場合にのみ発生します。したがって、変更は以前に記述された ETW コードや ETW が無効な状態で実行されるコードには影響しません。These events are raised only when ETW controllers enable them; therefore, the changes don't affect previously written ETW code or code that runs with ETW disabled.

  • トランザクションの昇格と永続参加リストへの変換Promoting a transaction and converting it to a durable enlistment

    Transaction.PromoteAndEnlistDurable は、.NET Framework 4.5.2 および 4.6 に追加された新しい API です。Transaction.PromoteAndEnlistDurable is a new API added to .NET Framework 4.5.2 and 4.6:

    [System.Security.Permissions.PermissionSetAttribute(System.Security.Permissions.SecurityAction.LinkDemand, Name = "FullTrust")]
    public Enlistment PromoteAndEnlistDurable(Guid resourceManagerIdentifier,
                                              IPromotableSinglePhaseNotification promotableNotification,
                                              ISinglePhaseNotification enlistmentNotification,
                                              EnlistmentOptions enlistmentOptions)
    <System.Security.Permissions.PermissionSetAttribute(System.Security.Permissions.SecurityAction.LinkDemand, Name:="FullTrust")>
    public Function PromoteAndEnlistDurable(resourceManagerIdentifier As Guid,
                                            promotableNotification As IPromotableSinglePhaseNotification,
                                            enlistmentNotification As ISinglePhaseNotification,
                                            enlistmentOptions As EnlistmentOptions) As Enlistment

    このメソッドは、以前に ITransactionPromoter.Promote メソッドへの応答として Transaction.EnlistPromotableSinglePhase によって作成された参加リストで使用できます。The method may be used by an enlistment that was previously created by Transaction.EnlistPromotableSinglePhase in response to the ITransactionPromoter.Promote method. これは、System.Transactions に対して、トランザクションを MSDTC トランザクションに昇格させ、昇格可能参加リストを永続参加リストに "変換" するように要求します。It asks System.Transactions to promote the transaction to an MSDTC transaction and to "convert" the promotable enlistment to a durable enlistment. このメソッドが正常に完了すると、IPromotableSinglePhaseNotification インターフェイスが System.Transactions から参照されなくなり、その後の通知は指定された ISinglePhaseNotification インターフェイスに到着します。After this method completes successfully, the IPromotableSinglePhaseNotification interface will no longer be referenced by System.Transactions, and any future notifications will arrive on the provided ISinglePhaseNotification interface. 問題の参加リストは、永続参加リストとして機能し、トランザクションのログ記録と復旧をサポートする必要があります。The enlistment in question must act as a durable enlistment, supporting transaction logging and recovery. 詳細については、Transaction.EnlistDurable を参照してください。Refer to Transaction.EnlistDurable for details. さらに、この参加リストは ISinglePhaseNotification もサポートする必要があります。In addition, the enlistment must support ISinglePhaseNotification. このメソッドは、ITransactionPromoter.Promote の呼び出しの処理中にのみ呼び出すことができます。This method can only be called while processing an ITransactionPromoter.Promote call. そうでない場合は、TransactionException 例外がスローされます。If that is not the case, a TransactionException exception is thrown.

.NET Framework 4.5.1 の新機能What's new in .NET Framework 4.5.1

2014 年 4 月の更新:April 2014 updates:

  • Visual Studio 2013 更新プログラム 2 には、次のシナリオをサポートするポータブル クラス ライブラリ テンプレートの更新が含まれています。Visual Studio 2013 Update 2 includes updates to the Portable Class Library templates to support these scenarios:

    • Windows 8.1、Windows Phone 8.1、および Windows Phone Silverlight 8.1 を対象とするポータブル ライブラリで Windows ランタイム API を使用できます。You can use Windows Runtime APIs in portable libraries that target Windows 8.1, Windows Phone 8.1, and Windows Phone Silverlight 8.1.

    • Windows 8.1 または Windows Phone 8.1 を対象とする場合、ポータブル ライブラリに XAML (Windows.UI.XAML 型) を含めることができます。You can include XAML (Windows.UI.XAML types) in portable libraries when you target Windows 8.1 or Windows Phone 8.1. 次の XAML テンプレートがサポートされています: 空白のページ、リソース ディクショナリ、テンプレート コントロール、およびユーザー コントロール。The following XAML templates are supported: Blank Page, Resource Dictionary, Templated Control, and User Control.

    • Windows 8.1 および Windows Phone 8.1 を対象とするストア アプリで使用するためにポータブル Windows ラインタイム コンポーネント (.winmd ファイル) を作成できます。You can create a portable Windows Runtime component (.winmd file) for use in Store apps that target Windows 8.1 and Windows Phone 8.1.

    • ポータブル クラス ライブラリのような Windows ストアまたは Windows Phone ストア クラス ライブラリを再ターゲットできます。You can retarget a Windows Store or Windows Phone Store class library like a Portable Class Library.

    これらの変更の詳細については、ポータブル クラス ライブラリに関するページを参照してください。For more information about these changes, see Portable Class Library.

  • .NET Framework のコンテンツ セットには、Windows アプリをビルドして配置するためのプリコンパイル テクノロジである .NET Native のドキュメントが含まれます。The .NET Framework content set now includes documentation for .NET Native, which is a precompilation technology for building and deploying Windows apps. .NET Native は、中間言語 (IL) ではなくネイティブ コードへアプリを直接コンパイルすることにより、パフォーマンスを向上させます。.NET Native compiles your apps directly to native code, rather than to intermediate language (IL), for better performance. 詳しくは、「.NET ネイティブによるアプリのコンパイル」をご覧ください。For details, see Compiling Apps with .NET Native.

  • .NET Framework Reference Source で、新しい参照エクスペリエンスと強化された機能が提供されます。The .NET Framework Reference Source provides a new browsing experience and enhanced functionality. これにより、.NET Frameworkのソース コードをオンラインで参照したり、リファレンスをダウンロードしてオフラインで表示したりできます。さらに、デバッグ中にソース (パッチや更新を含む) をステップ実行できます。You can now browse through the .NET Framework source code online, download the reference for offline viewing, and step through the sources (including patches and updates) during debugging. 詳細については、ブログ記事「A new look for .NET Reference Source (.NET Reference Source の新しい外観)」を参照してください。For more information, see the blog entry A new look for .NET Reference Source.

.NET Framework 4.5.1 の基底クラスの新機能と機能強化には次が含まれます。New features and enhancements in the base classes in .NET Framework 4.5.1 include:

  • アセンブリの自動バインディング リダイレクト。Automatic binding redirection for assemblies. Visual Studio 2013 以降では、アプリまたはそのコンポーネントが同じアセンブリの複数バージョンを参照している場合、.NET Framework 4.5.1 を対象とするアプリのコンパイル時に、バインディング リダイレクトをアプリ構成ファイルに追加できます。Starting with Visual Studio 2013, when you compile an app that targets the .NET Framework 4.5.1, binding redirects may be added to the app configuration file if your app or its components reference multiple versions of the same assembly. また、.NET Framework の以前のバージョンを対象とするプロジェクトで、この機能を有効にすることもできます。You can also enable this feature for projects that target older versions of the .NET Framework. 詳細については、自動バインディング リダイレクトを有効/無効にする」をご覧ください。For more information, see How to: Enable and Disable Automatic Binding Redirection.

  • 開発者がサーバーおよびクラウド アプリケーションのパフォーマンスを向上するために役立つ診断情報を収集する機能。Ability to collect diagnostics information to help developers improve the performance of server and cloud applications. 詳細については、WriteEventWithRelatedActivityId クラスの WriteEventWithRelatedActivityIdCore メソッドと EventSource メソッドを参照してください。For more information, see the WriteEventWithRelatedActivityId and WriteEventWithRelatedActivityIdCore methods in the EventSource class.

  • ガベージ コレクション中に大きなオブジェクト ヒープ (LOH) を圧縮する機能。Ability to explicitly compact the large object heap (LOH) during garbage collection. 詳細については、GCSettings.LargeObjectHeapCompactionMode プロパティを参照してください。For more information, see the GCSettings.LargeObjectHeapCompactionMode property.

  • その他のパフォーマンス向上 (ASP.NET アプリの中断、マルチコア JIT の改良、.NET Framework 更新後のアプリ起動時間の短縮など)。Additional performance improvements such as ASP.NET app suspension, multi-core JIT improvements, and faster app startup after a .NET Framework update. 詳細については、ブログ記事「.NET Framework 4.5.1 announcement」(.NET Framework 4.5.1 についてのお知らせ) および「ASP.NET app suspend」 (ASP.NET アプリケーションの中断) を参照してください。For details, see the .NET Framework 4.5.1 announcement and the ASP.NET app suspend blog post.

Windows フォームの機能強化には次が含まれます。Improvements to Windows Forms include:

  • Windows フォーム コントロールでのサイズ変更。Resizing in Windows Forms controls. アプリのアプリケーション構成ファイル (app.config) 内のエントリで有効にすることにより、システム DIP 設定を使用してコントロールのコンポーネント (例: プロパティ グリッドに表示されるアイコン) をサイズ変更できます。You can use the system DPI setting to resize components of controls (for example, the icons that appear in a property grid) by opting in with an entry in the application configuration file (app.config) for your app. 現在、この機能は次の Windows フォーム コントロールでサポートされています。This feature is currently supported in the following Windows Forms controls:

    この機能を有効にするには、構成ファイル (app.config) に新しい <appSettings> 要素を追加し、EnableWindowsFormsHighDpiAutoResizing 要素を true に設定します。To enable this feature, add a new <appSettings> element to the configuration file (app.config) and set the EnableWindowsFormsHighDpiAutoResizing element to true:

        <add key="EnableWindowsFormsHighDpiAutoResizing" value="true" />

Visual Studio 2013 で .NET Framework アプリをデバッグするときの改善点は次のとおりです。Improvements when debugging your .NET Framework apps in Visual Studio 2013 include:

  • Visual Studio デバッガーの戻り値。Return values in the Visual Studio debugger. Visual Studio 2013 でマネージド アプリをデバッグする場合、メソッドの戻り値の型と値が [自動変数] ウィンドウに表示されます。When you debug a managed app in Visual Studio 2013, the Autos window displays return types and values for methods. デスクトップ アプリ、Windows ストア アプリ、Windows Phone アプリについて、この情報を使用できます。This information is available for desktop, Windows Store, and Windows Phone apps. 詳細については、「メソッド呼び出しの戻り値の調査」をご覧ください。For more information, see Examine return values of method calls.

  • 64 ビット アプリのエディット コンティニュ。Edit and Continue for 64-bit apps. Visual Studio 2013 では、デスクトップ、Windows ストア、Windows Phone 用の 64 ビット マネージド アプリについて、エディット コンティニュ機能がサポートされています。Visual Studio 2013 supports the Edit and Continue feature for 64-bit managed apps for desktop, Windows Store, and Windows Phone. 既存の制限は、32 ビット アプリと 64 ビット アプリの両方でまだ有効です (「Supported Code Changes (C#)」(サポートされているコードの変更 (C#)) の記事の最後のセクションを参照してください)。The existing limitations remain in effect for both 32-bit and 64-bit apps (see the last section of the Supported Code Changes (C#) article).

  • 非同期対応のデバッグ。Async-aware debugging. Visual Studio 2013 で非同期アプリを簡単にデバッグするために、呼び出し履歴には、非同期プログラミングをサポートするためにコンパイラに用意されているインフラストラクチャ コード、および論理上の親フレーム内のチェーンが表示されません。これにより、論理的なプログラムの実行をよりわかりやすく行うことができます。To make it easier to debug asynchronous apps in Visual Studio 2013, the call stack hides the infrastructure code provided by compilers to support asynchronous programming, and also chains in logical parent frames so you can follow logical program execution more clearly. [タスク] ウィンドウが [並列タスク] ウィンドウに代わって使用され、特定のブレークポイントに関連するタスクが表示されます。また、現在アクティブなタスクやアプリでスケジュールされているタスクなども表示されます。A Tasks window replaces the Parallel Tasks window and displays tasks that relate to a particular breakpoint, and also displays any other tasks that are currently active or scheduled in the app. この機能については、「.NET Framework 4.5.1 announcement」(.NET Framework 4.5.1 についてのお知らせ) の「Async-aware debugging」(非同期対応のデバッグ) セクションを参照してください。You can read about this feature in the "Async-aware debugging" section of the .NET Framework 4.5.1 announcement.

  • Windows ランタイム コンポーネント向けのより適切な例外処理のサポート。Better exception support for Windows Runtime components. Windows 8.1 では、言語の種類に関係なく、Windows ストア アプリから発生する例外には、例外を発生させたエラーに関する情報が保持されます。In Windows 8.1, exceptions that arise from Windows Store apps preserve information about the error that caused the exception, even across language boundaries. この機能については、「.NET Framework 4.5.1 announcement」(.NET Framework 4.5.1 についてのお知らせ) の「Windows Store app development」(Windows ストア アプリ開発) のセクションを参照してください。You can read about this feature in the "Windows Store app development" section of the .NET Framework 4.5.1 announcement.

Visual Studio 2013 以降では、Mpgo.exe (マネージド プロファイル ガイド付き最適化ツール) を使って、Windows 8.x ストア アプリとデスクトップ アプリを最適化することができます。Starting with Visual Studio 2013, you can use the Managed Profile Guided Optimization Tool (Mpgo.exe) to optimize Windows 8.x Store apps as well as desktop apps.

ASP.NET 4.5.1 の新機能については、「ASP.NET and Web Tools for Visual Studio 2013 のリリース ノート」を参照してください。For new features in ASP.NET 4.5.1, see ASP.NET and Web Tools for Visual Studio 2013 Release Notes.

.NET Framework 4.5 の新機能What's new in .NET Framework 4.5

基底クラスBase classes

  • 配置時に .NET Framework 4 アプリケーションを検出して終了することにより、システムの再起動を減らす機能。Ability to reduce system restarts by detecting and closing .NET Framework 4 applications during deployment. .NET Framework 4.5 のインストール中のシステム再起動の削減」をご覧ください。See Reducing System Restarts During .NET Framework 4.5 Installations.

  • 64 ビット プラットフォームでの 2 ギガバイト (GB) を超える配列のサポート。Support for arrays that are larger than 2 gigabytes (GB) on 64-bit platforms. この機能は、アプリケーション構成ファイルで有効にすることができます。This feature can be enabled in the application configuration file. <gcAllowVeryLargeObjects> 要素」も参照してください。オブジェクト サイズと配列サイズに関する他の制限も記載されています。See the <gcAllowVeryLargeObjects> element, which also lists other restrictions on object size and array size.

  • サーバーのガベージ コレクションをバックグラウンドで行うことにより、パフォーマンスを改善します。Better performance through background garbage collection for servers. .NET Framework 4.5 でサーバーのガベージ コレクションを使うと、バックグラウンド ガベージ コレクションが自動的に有効になります。When you use server garbage collection in the .NET Framework 4.5, background garbage collection is automatically enabled. ガベージ コレクションの基礎」(ガベージ コレクションの基礎) トピックの「バックグラウンド サーバー ガベージ コレクション」というセクションをご覧ください。See the Background Server Garbage Collection section of the Fundamentals of Garbage Collection topic.

  • マルチコア プロセッサでオプションで使用できるバックグラウンドの Just-in-time (JIT) コンパイルを使用すると、アプリケーションのパフォーマンスが向上します。Background just-in-time (JIT) compilation, which is optionally available on multi-core processors to improve application performance. ProfileOptimization」を参照してください。See ProfileOptimization.

  • 正規表現エンジンがタイムアウトする前に、正規表現の解決を試みる時間に制限を設ける機能。Regex.MatchTimeout プロパティを参照してください。Ability to limit how long the regular expression engine will attempt to resolve a regular expression before it times out. See the Regex.MatchTimeout property.

  • アプリケーション ドメインの既定のカルチャを定義する機能。Ability to define the default culture for an application domain. 詳細については、CultureInfo クラスのトピックを参照してください。See the CultureInfo class.

  • Unicode UTF-16 エンコードのコンソール サポート。Console support for Unicode (UTF-16) encoding. 詳細については、Console クラスのトピックを参照してください。See the Console class.

  • カルチャに従った文字列の順序のバージョン指定と比較データのサポート。Support for versioning of cultural string ordering and comparison data. 詳細については、SortVersion クラスのトピックを参照してください。See the SortVersion class.

  • リソースを取得するときのパフォーマンスを改善します。Better performance when retrieving resources. リソースのパッケージ化と配置」を参照してください。See Packaging and Deploying Resources.

  • Zip 圧縮の機能強化により、圧縮ファイルのサイズが小さくなりました。Zip compression improvements to reduce the size of a compressed file. System.IO.Compression 名前空間を参照してください。See the System.IO.Compression namespace.

  • CustomReflectionContext クラスを使用して、既定のリフレクションの動作をオーバーライドするリフレクション コンテキストをカスタマイズできる機能。Ability to customize a reflection context to override default reflection behavior through the CustomReflectionContext class.

  • System.Globalization.IdnMapping クラスを Windows 8 で使用した場合の IDNA (Internationalized Domain Names in Applications) 規格の 2008 バージョンのサポート。Support for the 2008 version of the Internationalized Domain Names in Applications (IDNA) standard when the System.Globalization.IdnMapping class is used on Windows 8.

  • オペレーティング システムへの文字列比較の処理代行。 .NET Framework を Windows 8 で使ったときに、Unicode 6.0 が実装されます。Delegation of string comparison to the operating system, which implements Unicode 6.0, when the .NET Framework is used on Windows 8. 他のプラットフォームで実行されている場合、.NET Framework には、Unicode 5.x. を実装する独自の文字列比較データが含まれています。When running on other platforms, the .NET Framework includes its own string comparison data, which implements Unicode 5.x. String クラスおよび SortVersion クラスの「コメント」セクションを参照してください。See the String class and the Remarks section of the SortVersion class.

  • アプリケーション ドメインごとに文字列のハッシュ コードを計算する機能。Ability to compute the hash codes for strings on a per application domain basis. <UseRandomizedStringHashAlgorithm> 要素」をご覧ください。See <UseRandomizedStringHashAlgorithm> Element.

  • Type クラスと TypeInfo クラスで、タイプ リフレクションのサポートが分割されました。Type reflection support split between Type and TypeInfo classes. Windows ストア アプリのための .NET Framework のリフレクション」をご覧ください。See Reflection in the .NET Framework for Windows Store Apps.

MEF (Managed Extensibility Framework)Managed Extensibility Framework (MEF)

.NET Framework 4.5 では、MEF (Managed Extensibility Framework) に次の新機能が用意されています。In the .NET Framework 4.5, the Managed Extensibility Framework (MEF) provides the following new features:

  • ジェネリック型のサポート。Support for generic types.

  • 属性ではなく命名規則に基づいてパーツを作成できるようにする、規則ベースのプログラミング モデル。Convention-based programming model that enables you to create parts based on naming conventions rather than attributes.

  • 複数のスコープ。Multiple scopes.

  • Windows 8.x ストア アプリを作成するときに使うことができる MEF のサブセット。A subset of MEF that you can use when you create Windows 8.x Store apps. このサブセットは、ダウンロード可能パッケージとして NuGet ギャラリーから入手できます。This subset is available as a downloadable package from the NuGet Gallery. パッケージをインストールするには、Visual Studio でプロジェクトを開き、 [プロジェクト] メニューの [NuGet パッケージの管理] をクリックし、Microsoft.Composition パッケージをオンラインで検索します。To install the package, open your project in Visual Studio, choose Manage NuGet Packages from the Project menu, and search online for the Microsoft.Composition package.

詳しくは、「Managed Extensibility Framework (MEF)」を参照してください。For more information, see Managed Extensibility Framework (MEF).

非同期のファイル操作Asynchronous file operations

.NET Framework 4.5 では、新しい非同期機能が C# および Visual Basic 言語に追加されました。In the .NET Framework 4.5, new asynchronous features were added to the C# and Visual Basic languages. これらの機能は、非同期操作を実行するためのタスク ベースのモデルを追加します。These features add a task-based model for performing asynchronous operations. この新しいモデルを使用するには、I/O クラスで非同期メソッドを使用します。To use this new model, use the asynchronous methods in the I/O classes. 非同期ファイル I/O」を参照してください。See Asynchronous File I/O.


.NET Framework 4.5 では、リソース ファイル ジェネレーター (Resgen.exe) を使うと、.NET Framework アセンブリに埋め込まれた .resources ファイルから Windows 8.x ストア アプリ用の .resw ファイルを作成することができます。In the .NET Framework 4.5, Resource File Generator (Resgen.exe) enables you to create a .resw file for use in Windows 8.x Store apps from a .resources file embedded in a .NET Framework assembly. 詳しくは、「Resgen.exe (リソース ファイル ジェネレーター)」をご覧ください。For more information, see Resgen.exe (Resource File Generator).

マネージド プロファイル ガイド付き最適化ツール (Mpgo.exe) を使用すると、ネイティブ イメージ アセンブリを最適化することによって、アプリケーションの起動時間、メモリの使用率 (ワーキング セットのサイズ)、およびスループットを向上させることができます。Managed Profile Guided Optimization (Mpgo.exe) enables you to improve application startup time, memory utilization (working set size), and throughput by optimizing native image assemblies. このコマンド ライン ツールは、ネイティブ イメージ アプリケーション アセンブリ用のプロファイル データを生成します。The command-line tool generates profile data for native image application assemblies. Mpgo.exe (マネージド プロファイル ガイド付き最適化ツール)」をご覧ください。See Mpgo.exe (Managed Profile Guided Optimization Tool). Visual Studio 2013 以降では、Windows 8.x ストア アプリおよびデスクトップ アプリを最適化するために、Mpgo.exe を使うことができます。Starting with Visual Studio 2013, you can use Mpgo.exe to optimize Windows 8.x Store apps as well as desktop apps.

並列コンピューティングParallel computing

.NET Framework 4.5 では、並列計算用にいくつかの新機能と機能強化が提供されています。The .NET Framework 4.5 provides several new features and improvements for parallel computing. パフォーマンスの向上、コントロールの強化、非同期プログラミングのサポートの改善、新しいデータフロー ライブラリ、並列デバッグとパフォーマンス分析のためのサポートの強化などが挙げられます。These include improved performance, increased control, improved support for asynchronous programming, a new dataflow library, and improved support for parallel debugging and performance analysis. ブログ「Parallel Programming with .NET」(.NET での並列プログラミング) の記事「What’s New for Parallelism in .NET 4.5」(.NET 4.5 での並列処理の新機能) を参照してください。See the entry What’s New for Parallelism in .NET 4.5 in the Parallel Programming with .NET blog.


ASP.NET 4.5 および 4.5.1 では、Web フォーム モデルのバインディング、WebSocket のサポート、非同期ハンドラー、パフォーマンスの向上などの多くの機能が追加されています。ASP.NET 4.5 and 4.5.1 add model binding for Web Forms, WebSocket support, asynchronous handlers, performance enhancements, and many other features. 詳細については、次のリソースを参照してください。For more information, see the following resources:

ネットワーク Networking

.NET Framework 4.5 は、HTTP アプリケーションに新しいプログラミング インターフェイスを提供します。The .NET Framework 4.5 provides a new programming interface for HTTP applications. 詳細については、新しい System.Net.Http 名前空間と System.Net.Http.Headers 名前空間を参照してください。For more information, see the new System.Net.Http and System.Net.Http.Headers namespaces.

既存の HttpListener と関連クラスを使用して WebSocket 接続を受け入れ、やり取りするための新しいプログラミング インターフェイスのサポートも含まれています。Support is also included for a new programming interface for accepting and interacting with a WebSocket connection by using the existing HttpListener and related classes. 詳細については、新しい System.Net.WebSockets 名前空間と HttpListener クラスを参照してください。For more information, see the new System.Net.WebSockets namespace and the HttpListener class.

また .NET Framework 4.5 には、次のネットワークの機能強化が含まれています。In addition, the .NET Framework 4.5 includes the following networking improvements:

  • RFC 準拠の URI サポート。RFC-compliant URI support. 詳細については、Uri および関連クラスを参照してください。For more information, see Uri and related classes.

  • 国際化ドメイン名 (IDN: Internationalized Domain Name) による解析のサポート。Support for Internationalized Domain Name (IDN) parsing. 詳細については、Uri および関連クラスを参照してください。For more information, see Uri and related classes.

  • 電子メール アドレスの国際化 (EAI) のサポート。Support for Email Address Internationalization (EAI). 詳細については、「System.Net.Mail」を参照してください。For more information, see the System.Net.Mail namespace.

  • 強化された IPv6 サポート。Improved IPv6 support. 詳細については、「System.Net.NetworkInformation」を参照してください。For more information, see the System.Net.NetworkInformation namespace.

  • デュアル モードのソケットのサポート。Dual-mode socket support. 詳細については、Socket クラスおよび TcpListener クラスを参照してください。For more information, see the Socket and TcpListener classes.

Windows Presentation Foundation (WPF)Windows Presentation Foundation (WPF)

.NET Framework 4.5 では、WPF (Windows Presentation Foundation) の次の領域の機能が変更および強化されています。In the .NET Framework 4.5, Windows Presentation Foundation (WPF) contains changes and improvements in the following areas:

  • クイック アクセス ツール バー、アプリケーション メニューおよびタブをホストするリボン ユーザー インターフェイスを実装できる新しい Ribbon コントロール。The new Ribbon control, which enables you to implement a ribbon user interface that hosts a Quick Access Toolbar, Application Menu, and tabs.

  • 同期および非同期のデータ検証をサポートする新しい INotifyDataErrorInfo インターフェイス。The new INotifyDataErrorInfo interface, which supports synchronous and asynchronous data validation.

  • VirtualizingPanel および Dispatcher クラスの新しい機能。New features for the VirtualizingPanel and Dispatcher classes.

  • グループ化された大量のデータを表示するときに、非 UI スレッドのコレクションにアクセスすることによってパフォーマンスを向上。Improved performance when displaying large sets of grouped data, and by accessing collections on non-UI threads.

  • 静的プロパティへのデータ バインディング、ICustomTypeProvider インターフェイスを実装するカスタム型へのデータ バインディング、およびバインディング式からのデータ バインディング情報の取得。Data binding to static properties, data binding to custom types that implement the ICustomTypeProvider interface, and retrieval of data binding information from a binding expression.

  • 値の変更に伴うデータの再配置 (ライブ形成)。Repositioning of data as the values change (live shaping).

  • 項目コンテナーのデータ コンテキストを切断するかどうかをチェックする機能。Ability to check whether the data context for an item container is disconnected.

  • プロパティの変更とデータ ソースの更新までの経過時間を設定する機能。Ability to set the amount of time that should elapse between property changes and data source updates.

  • 弱いイベント パターン実装時のサポートの強化。Improved support for implementing weak event patterns. また、イベントでマークアップ拡張機能を使用することもできるようになりました。Also, events can now accept markup extensions.

Windows Communication Foundation (WCF)Windows Communication Foundation (WCF)

.NET Framework 4.5 では、Windows Communication Foundation (WCF) アプリケーションの記述と保守を簡単にするため、次の機能が追加されました。In the .NET Framework 4.5, the following features have been added to make it simpler to write and maintain Windows Communication Foundation (WCF) applications:

  • 生成された構成ファイルの簡略化。Simplification of generated configuration files.

  • コントラクト優先開発のサポート。Support for contract-first development.

  • ASP.NET 互換モードをより簡単に構成できる機能。Ability to configure ASP.NET compatibility mode more easily.

  • 既定のトランスポート プロパティ値に変更を加え、設定しなければならない可能性を低減しました。Changes in default transport property values to reduce the likelihood that you will have to set them.

  • XmlDictionaryReaderQuotas クラスを更新して、XML ディクショナリ リーダーのクォータを手動で構成する手間を省けるようにしました。Updates to the XmlDictionaryReaderQuotas class to reduce the likelihood that you will have to manually configure quotas for XML dictionary readers.

  • ビルド処理の一部として Visual Studio による WCF 構成ファイルを検証することで、アプリケーションを実行する前に構成エラーを検出できます。Validation of WCF configuration files by Visual Studio as part of the build process, so you can detect configuration errors before you run your application.

  • 新しい非同期ストリーミングのサポート。New asynchronous streaming support.

  • Internet Information Services (IIS) での HTTPS 上のエンドポイントを公開しやすくする新しい HTTPS プロトコル マッピング。New HTTPS protocol mapping to make it easier to expose an endpoint over HTTPS with Internet Information Services (IIS).

  • ?singleWSDL をサービス URL に追加して 1 つの WSDL ドキュメントのメタデータを生成する機能。Ability to generate metadata in a single WSDL document by appending ?singleWSDL to the service URL.

  • TCP トランスポートと同様のパフォーマンス特性を持つポート 80 と 443 で真の双方向通信を可能にする Websockets のサポート。Websockets support to enable true bidirectional communication over ports 80 and 443 with performance characteristics similar to the TCP transport.

  • コード内の構成サービスのサポート。Support for configuring services in code.

  • XML エディターのツール ヒント。XML Editor tooltips.

  • ChannelFactory キャッシュのサポート。ChannelFactory caching support.

  • バイナリ エンコーダーの圧縮サポート。Binary encoder compression support.

  • 開発者が「ファイア アンド フォーゲット (撃ち放し)」メッセージングを使用するサービスを作成できるようにする UDP トランスポートのサポート。Support for a UDP transport that enables developers to write services that use "fire and forget" messaging. クライアントは、サービスにメッセージを送信しますが、サービスからの応答を期待しません。A client sends a message to a service and expects no response from the service.

  • HTTP トランスポートとトランスポート セキュリティを使用したときに、単一の WCF エンドポイントで複数の認証モードをサポートする機能。Ability to support multiple authentication modes on a single WCF endpoint when using the HTTP transport and transport security.

  • 国際化ドメイン名 (IDN: Internationalized Domain Name) を使用する WCF サービスのサポート。Support for WCF services that use internationalized domain names (IDNs).

詳細については、「Windows Communication Foundation 4.5 の新機能」を参照してください。For more information, see What's New in Windows Communication Foundation.

Windows Workflow Foundation (WF)Windows Workflow Foundation (WF)

.NET Framework 4.5 では、次に示すようないくつかの新しい機能が Windows Workflow Foundation (WF) に追加されました。In the .NET Framework 4.5, several new features were added to Windows Workflow Foundation (WF), including:

  • 最初に .NET Framework 4.0.1 (.NET Framework 4 Platform Update 1) の一部として導入された、ステート マシンのワークフロー。State machine workflows, which were first introduced as part of .NET Framework 4.0.1 (.NET Framework 4 Platform Update 1). この更新プログラムには、開発者がステート マシン ワークフローを作成できるようにする新しいクラスとアクティビティが複数含まれていました。This update included several new classes and activities that enabled developers to create state machine workflows. .NET Framework 4.5 では、これらのクラスとアクティビティが、次を含むように更新されました。These classes and activities were updated for the .NET Framework 4.5 to include:

    • 状態でブレークポイントを設定する機能。The ability to set breakpoints on states.

    • ワークフロー デザイナーで遷移をコピーして貼り付ける機能。The ability to copy and paste transitions in the workflow designer.

    • 共有されるトリガーの遷移作成のデザイナー サポート。Designer support for shared trigger transition creation.

    • StateMachineState、および Transition などのようにステート マシン ワークフローを作成する機能。Activities for creating state machine workflows, including: StateMachine, State, and Transition.

  • 次のようなワークフロー デザイナーの機能が強化されました。Enhanced Workflow Designer features such as the following:

    • [クイック検索][フォルダーを指定して検索] など、Visual Studio で強化されたワークフロー検索機能。Enhanced workflow search capabilities in Visual Studio, including Quick Find and Find in Files.

    • 2 番目の子アクティビティがコンテナー アクティビティに追加されたときに、自動的にシーケンス アクティビティを作成し、両方のアクティビティをシーケンス アクティビティに含める機能。Ability to automatically create a Sequence activity when a second child activity is added to a container activity, and to include both activities in the Sequence activity.

    • スクロール バーを使用せずに変更されるワークフローの表示部分を変更できるようにするパン サポート。Panning support, which enables the visible portion of a workflow to be changed without using the scroll bars.

    • ツリー スタイルのアウトライン ビューでワークフローのコンポーネントを表示し、 [ドキュメント アウトライン] ビューでコンポーネントを選択できるようにする新しい [ドキュメント アウトライン] ビュー。A new Document Outline view that shows the components of a workflow in a tree-style outline view and lets you select a component in the Document Outline view.

    • アクティビティに注釈を追加できる機能。Ability to add annotations to activities.

    • ワークフロー デザイナーでアクティビティ デリゲートを定義および使用する機能。Ability to define and consume activity delegates by using the workflow designer.

    • ステート マシンのアクティビティと遷移、およびフローチャート ワークフローの自動接続と自動挿入。Auto-connect and auto-insert for activities and transitions in state machine and flowchart workflows.

  • ワークフローのビュー状態情報を XAML ファイルの 1 つの要素に保管して、ビュー状態情報を簡単に見つけ、編集できるようにします。Storage of the view state information for a workflow in a single element in the XAML file, so you can easily locate and edit the view state information.

  • 子アクティビティの永続化を防ぐ NoPersistScope コンテナー アクティビティ。A NoPersistScope container activity to prevent child activities from persisting.

  • C# 式のサポート:Support for C# expressions:

    • Visual Basic を使用するワークフロー プロジェクトは、Visual Basic 式を使用し、C# ワークフロー プロジェクトは C# 式を使用します。Workflow projects that use Visual Basic will use Visual Basic expressions, and C# workflow projects will use C# expressions.

    • Visual Studio 2010 で作成され、Visual Basic 式が使用されている C# ワークフロー プロジェクトは、C# 式を使用する C# ワークフロー プロジェクトと互換性があります。C# workflow projects that were created in Visual Studio 2010 and that have Visual Basic expressions are compatible with C# workflow projects that use C# expressions.

  • バージョン管理機能の強化Versioning enhancements:

    • 永続化されたワークフロー インスタンスとワークフロー定義間のマッピングを提供する新しい WorkflowIdentity クラス。The new WorkflowIdentity class, which provides a mapping between a persisted workflow instance and its workflow definition.

    • WorkflowServiceHost を含む同じホスト内の複数のワークフローのバージョンの並列実行。Side-by-side execution of multiple workflow versions in the same host, including WorkflowServiceHost.

    • 動的更新プログラムで、永続化されたワークフロー インスタンスの定義を変更する機能。In Dynamic Update, the ability to modify the definition of a persisted workflow instance.

  • 既存のサービス コントラクトに合わせて自動的にアクティビティを生成するサポートが提供されるコントラクト優先のワークフロー サービス開発。Contract-first workflow service development, which provides support for automatically generating activities to match an existing service contract.

詳細については、「.NET 4.5 での Windows Workflow Foundation の新機能」を参照してください。For more information, see What's New in Windows Workflow Foundation.

Windows 8.x ストア アプリ用 .NET.NET for Windows 8.x Store apps

Windows 8.x ストア アプリは、特定のフォーム ファクターに合わせて設計されており、Windows オペレーティング システムの機能を利用します。Windows 8.x Store apps are designed for specific form factors and leverage the power of the Windows operating system. C# または Visual Basic を使って Windows 用の Windows 8.x ストア アプリをビルドするために、.NET Framework 4.5 または 4.5.1 のサブセットを使うことができます。A subset of the .NET Framework 4.5 or 4.5.1 is available for building Windows 8.x Store apps for Windows by using C# or Visual Basic. このサブセットは Windows 8.x ストア アプリ用 .NET と呼ばれ、概要のページで説明されています。This subset is called .NET for Windows 8.x Store apps and is discussed in an overview.

ポータブル クラス ライブラリ Portable Class Libraries

Visual Studio 2012 (および以降のバージョン) のポータブル クラス ライブラリ プロジェクトを使うと、複数の .NET Framework プラットフォームで動作するマネージド アセンブリを作成してビルドできます。The Portable Class Library project in Visual Studio 2012 (and later versions) enables you to write and build managed assemblies that work on multiple .NET Framework platforms. ポータブル クラス ライブラリ プロジェクトを使って、対象とするプラットフォーム (Windows Phone や Windows 8.x ストア アプリ用 .NET など) を選択できます。Using a Portable Class Library project, you choose the platforms (such as Windows Phone and .NET for Windows 8.x Store apps) to target. プロジェクトで使用できる型およびメンバーは、自動的にこれらのプラットフォーム間で共通の型とメンバーに制限されます。The available types and members in your project are automatically restricted to the common types and members across these platforms. 詳細については、ポータブル クラス ライブラリに関するページを参照してください。For more information, see Portable Class Library.

関連項目See also