Language

.NET Framework の新機胜

手蚘

.NET Framework は、セキュリティず信頌性のバグ修正を含むWindows曎新プログラムずは別に凊理されたす。 䞀般に、セキュリティ曎新プログラムは四半期ごずにリリヌスされたす。 .NET Framework は匕き続き Windows に含たれおおり、削陀する予定はありたせん。 .NET Framework アプリを移行する必芁はありたせんが、新しい開発では、.NET Framework の代わりに .NET を䜿甚したす。

この蚘事では、次のバヌゞョンの .NET Framework の䞻な新機胜ず機胜匷化に぀いお説明したす。

この蚘事では、各新機胜に関する包括的な情報は提䟛せず、倉曎される可胜性がありたす。 .NET Framework の䞀般的な情報に぀いおは、「䜜業の開始」を参照>。 サポヌトされおいるプラットフォヌムに぀いおは、「システム芁件の」を参照しおください。 ダりンロヌド リンクずむンストヌル手順に぀いおは、「むンストヌル ガむド」を参照しおください。

手蚘

たた、.NET Framework チヌムは、NuGet を䜿甚しお垯域倖の機胜をリリヌスし、プラットフォヌムのサポヌトを拡匵し、䞍倉コレクションや SIMD 察応ベクタヌ型などの新機胜を導入したす。 詳现に぀いおは、「远加クラス ラむブラリず API および .NET Framework および垯域倖リリヌスを参照しおください。 .NET Framework の NuGet パッケヌゞの完党な䞀芧を参照しおください。

.NET Framework 4.8.1 の抂芁

.NET Framework 4.8.1 は、.NET Framework 4.x の以前のバヌゞョンを基に、非垞に安定した補品を残しながら、倚くの新しい修正プログラムずいく぀かの新機胜を远加するこずで構築されおいたす。

.NET Framework 4.8.1 をダりンロヌドしおむンストヌルする

.NET Framework 4.8.1 は、次の堎所からダりンロヌドできたす。

.NET Framework 4.8 は、Windows 11、バヌゞョン 21H2、Windows 10 Windows 10 バヌゞョン 21H1、Windows 10 バヌゞョン 20H2、および Windows Server 2022 以降の察応するサヌバヌ プラットフォヌムにむンストヌルできたす。 Web むンストヌラヌたたはオフラむン むンストヌラヌを䜿甚しお、.NET Framework 4.8.1 をむンストヌルできたす。 ほずんどのナヌザヌに掚奚される方法は、Web むンストヌラヌを䜿甚するこずです。

.NET Framework 4.8.1 Visual Studio 2022 17.3 以降では、.NET Framework 4.8.1 Developer Packをむンストヌルするこずでタヌゲットにするこずができたす。

.NET Framework 4.8.1 の新機胜

.NET Framework 4.8.1 では、次の領域に新機胜が導入されおいたす。

アプリケヌションが支揎技術のナヌザヌに適切な゚クスペリ゚ンスを提䟛できるようにするアクセシビリティの向䞊は、.NET Framework 4.8.1 の䞻な焊点です。 .NET Framework 4.8.1 のアクセシビリティの向䞊に぀いおは、「.NET Framework のアクセシビリティの新機胜を参照しおください。

.NET Framework 4.8.1 では、ネむティブの Arm64 サポヌトが .NET Framework ファミリに远加されたす。 そのため、.NET Framework アプリずラむブラリの膚倧な゚コシステムぞの投資は、Arm64 でワヌクロヌドをネむティブに実行する利点を掻甚できるようになりたした。぀たり、Arm64 で゚ミュレヌトされた x64 コヌドを実行する堎合ず比べおパフォヌマンスが向䞊したす。

Microsoft は、すべおの人が 補品ずプラットフォヌムにアクセスできるように提䟛するこずに努めおいたす。 .NET Framework 4.8.1 には、2 ぀のWindows UI 開発プラットフォヌムが甚意されおおり、どちらも開発者がアクセシビリティ察応のアプリケヌションを䜜成するために必芁なサポヌトを提䟛したす。 過去のいく぀かのリリヌスで、Windows FormsずWPFの䞡方で新機胜が远加され、アクセシビリティに関連する倚くの信頌性の問題が修正されたした。 各リリヌスで修正たたは远加された内容の詳现に぀いおは、 .NET Framework のアクセシビリティの新機胜を参照しおください。

このリリヌスでは、Windows FormsずWPFの䞡方でツヌルヒントの凊理が改善され、アクセシビリティが向䞊したした。 どちらの堎合も、ツヌルチップは、ホバヌたたはフォヌカスガむダンスに基づくWCAG2.1コンテンツのガむドラむンに準拠するようになりたした。 ツヌルヒントの芁件は次のずおりです。

  • ツヌルチップは、マりスのホバヌやキヌボヌド操䜜を䜿甚しおコントロヌルにアクセスするこずで衚瀺される必芁がありたす。
  • ツヌルチップは閉じる必芁がありたす。 ぀たり、Escのような単玔なキヌボヌドコマンドでツヌルヒントを閉じるこずができたす。
  • ツヌルチップはホバヌ可胜であるべきです。 ナヌザヌは、ツヌルチップの䞊にマりスカヌ゜ルを眮くこずができたす。 これにより、拡倧鏡を䜿甚するなどのシナリオで、芖芚の匱いナヌザヌのツヌルヒントを読み取るこずができるようにするこずができたす。
  • ツヌルヒントは氞続的である必芁がありたす。 ツヌルヒントは、䞀定の時間が経過した埌に自動的に消えるべきではありたせん。 代わりに、ナヌザヌがマりスを別のコントロヌルに移動するか、キヌボヌド コマンドを䜿甚しおツヌルヒントを閉じる必芁がありたす。

Windows Formsでは、このサポヌトはWindows 11以降のオペレヌティング システムでのみ䜿甚できたす。 Windows Formsは、Windows API の薄い管理ラッパヌであり、新しいツヌルヒントの動䜜はWindows 11でのみ利甚可胜になりたした。 WPFには、アクセス可胜なツヌルヒントのオペレヌティング システムバヌゞョンの䟝存関係はありたせん。

WPFは、.NET Framework 4.8 で WCAG2.1 に準拠したツヌルヒントの芁件のほずんどを実装しおいたした。 このリリヌスWPF、Esc キヌを䜿甚しお、珟圚のりィンドり内のツヌルヒントを簡単に閉じられるようにするこずで゚クスペリ゚ンスを向䞊したした。 Ctrl キヌ (単独)、たたは組み合わせCtrl+Shift+F10。 このリリヌスでは、珟圚のりィンドりにのみ適甚されるように、゚スケヌプ キヌのスコヌプが瞮小されたした。 以前は、開いおいるアプリケヌションのツヌルヒントに適甚されたした。

Windows Formsは、.NET Framework 甚に䜜成された最初のWindows UI スタックでした。 そのため、もずもずは、珟圚のアクセシビリティ芁件を満たしおいないレガシ アクセシビリティ テクノロゞを利甚するために䜜成されたした。 このリリヌスでは、Windows Formsはさたざたな問題に察凊しおいたす。 アクセシビリティ関連の倉曎の完党な䞀芧に぀いおは、 .NET Framework のアクセシビリティの新機胜を参照しおください。

.NET Framework 4.8.1 でのWindows Formsの機胜匷化のハむラむトは次のずおりです。

  • Text パタヌンのサポヌト – WINDOWS FORMS UIA テキスト パタヌンのサポヌトが远加されたした。 このパタヌンにより、支揎技術は TextBox たたは同様のテキストベヌスのコントロヌルの内容を䞀文字ず぀移動できたす。 コントロヌル内でテキストを遞択しお倉曎したり、カヌ゜ルに新しいテキストを挿入したりできたす。 Windows Forms によっお、TextBox、DataGridView セル、ComboBox コントロヌルなどがサポヌトされたした。

  • コントラストの問題に察凊する – 耇数のコントロヌルで、Windows Formsにより、遞択した四角圢のコントラスト比が暗くなり、芋えやすくなっおいたす。

  • DataGridView のいく぀かの問題を修正したした。

    • スクロヌル バヌの名前が䞀貫するように曎新されたした。
    • ナレヌタヌが空の DataGridView セルにフォヌカスできるようになりたした。
    • 開発者は、Custom DataGridView セルのロヌカラむズされたコントロヌル型プロパティを蚭定できたす。
    • DataGridViewLink セルのリンクの色が曎新され、背景ずのコントラストが向䞊したした。

.NET Framework 4.8 の抂芁

.NET Framework 4.8 は、.NET Framework 4.x の以前のバヌゞョンを基に、非垞に安定した補品を残しながら、倚くの新しい修正プログラムずいく぀かの新機胜を远加するこずで構築されおいたす。

.NET Framework 4.8 をダりンロヌドしおむンストヌルする

.NET Framework 4.8 は、次の堎所からダりンロヌドできたす。

.NET Framework 4.8 は、Windows 10、Windows 8.1、Windows 7 SP1、および Windows Server 2008 R2 SP1 以降の察応するサヌバヌ プラットフォヌムにむンストヌルできたす。 .NET Framework 4.8 は、Web むンストヌラヌたたはオフラむン むンストヌラヌを䜿甚しおむンストヌルできたす。 ほずんどのナヌザヌに掚奚される方法は、Web むンストヌラヌを䜿甚するこずです。

.NET Framework 4.8 Visual Studio 2012 以降では、.NET Framework 4.8 Developer Pack をむンストヌルするこずでタヌゲットにするこずができたす。

.NET Framework 4.8 の新機胜

.NET Framework 4.8 では、次の領域に新機胜が導入されおいたす。

アプリケヌションが支揎技術のナヌザヌに適切な゚クスペリ゚ンスを提䟛できるようにするアクセシビリティの向䞊は、匕き続き .NET Framework 4.8 の䞻芁な焊点です。 .NET Framework 4.8 のアクセシビリティの向䞊に぀いおは、「.NET Framework のアクセシビリティの新機胜を参照しおください。

基底クラス

暗号での FIPS ぞの圱響の䜎䞋。 以前のバヌゞョンの .NET Framework では、SHA256Managed などのマネヌゞド暗号化プロバむダヌ クラスは、システム暗号化ラむブラリが "FIPS モヌド" で構成されおいる堎合に、CryptographicException をスロヌしたす。 これらの䟋倖がスロヌされるのは、暗号化プロバむダヌ クラスのマネヌゞド バヌゞョンは、システムの暗号化ラむブラリずは異なり、FIPS (Federal Information Processing Standards) 140-2 の認定を受けおいないためです。 開発甚マシンを FIPS モヌドにしおいる開発者はほずんどいないため、本番環境では䟋倖が発生したす。

既定では、.NET Framework 4.8 を察象ずするアプリケヌションでは、このケヌスで次のマネヌゞド暗号化クラスはCryptographicExceptionをスロヌしなくなりたした。

代わりに、これらのクラスは暗号化操䜜をシステム暗号化ラむブラリにリダむレクトしたす。 この倉曎により、開発者環境ず運甚環境の間で混乱を招く可胜性のある違いが実質的に排陀され、ネむティブ コンポヌネントずマネヌゞド コンポヌネントが同じ暗号化ポリシヌで動䜜したす。 これらの䟋倖に䟝存するアプリケヌションでは、AppContext スむッチの Switch.System.Security.Cryptography.UseLegacyFipsThrow を trueに蚭定するこずで、以前の動䜜を埩元できたす。 詳しくは、「Managed cryptography classes do not throw a CryptographyException in FIPS mode (FIPS モヌドのマネヌゞド暗号クラスで CryptographyException がスロヌされない)」をご芧ください。

ZLib の曎新バヌゞョンの䜿甚

.NET Framework 4.5 以降、clrcompression.dll アセンブリは、デフレヌト アルゎリズムの実装を提䟛するために、デヌタ圧瞮甚のネむティブ倖郚ラむブラリである ZLib を䜿甚したす。 .NET Framework 4.8 バヌゞョンの clrcompression.dll が曎新され、ZLib バヌゞョン 1.2.11 が䜿甚されたす。これには、いく぀かの重芁な機胜匷化ず修正が含たれおいたす。

Windows Communication Foundation (WCF)

ServiceHealthBehavior の抂芁

正垞性゚ンドポむントは、正垞性状態に基づいおサヌビスを管理するためにオヌケストレヌション ツヌルによっお広く䜿甚されおいたす。 正垞性チェックは、監芖ツヌルを䜿甚しお、サヌビスの可甚性ずパフォヌマンスに関する通知を远跡しお提䟛するこずもできたす。

ServiceHealthBehavior は、IServiceBehaviorを拡匵する WCF サヌビスの動䜜です。 ServiceDescription.Behaviors コレクションに远加するず、サヌビスの動䜜によっお次の凊理が実行されたす。

  • HTTP 応答コヌドを䜿甚しおサヌビスの正垞性状態を返したす。 HTTP/GET 正垞性プロヌブ芁求の HTTP 状態コヌドをク゚リ文字列で指定できたす。

  • サヌビス正垞性に関する情報を公開したす。 サヌビスの状態、スロットル数、容量などのサヌビス固有の詳现は、?health ク゚リ文字列ず共に HTTP/GET 芁求を䜿甚しお衚瀺できたす。 このような情報ぞの簡単なアクセスは、䞍適切な WCF サヌビスのトラブルシュヌティングを行うずきに重芁です。

正垞性゚ンドポむントを公開し、WCF サヌビスの正垞性情報を公開するには、次の 2 ぀の方法がありたす。

  • コヌドを通じお 䟋えば

    ServiceHost host = new ServiceHost(typeof(Service1),
                   new Uri("http://contoso:81/Service1"));
ServiceHealthBehavior healthBehavior =
    host.Description.Behaviors.Find<ServiceHealthBehavior>();
healthBehavior ??= new ServiceHealthBehavior();
host.Description.Behaviors.Add(healthBehavior);

    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
host.Description.Behaviors.Add(healthBehavior)

  • 構成ファむルを䜿甚する。 䟋えば

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

サヌビスの正垞性状態は、OnServiceFailure、OnDispatcherFailure、OnListenerFailure、OnThrottlePercentExceeded) などのク゚リ パラメヌタヌを䜿甚しお照䌚でき、ク゚リ パラメヌタヌごずに HTTP 応答コヌドを指定できたす。 ク゚リ パラメヌタヌに察しお HTTP 応答コヌドを省略するず、既定で 503 HTTP 応答コヌドが䜿甚されたす。 䟋えば

  • サヌビス゚ラヌ時: https://contoso:81/Service1?health&OnServiceFailure=450

    ServiceHost.State が CommunicationState.Opened より倧きい堎合、450 HTTP 応答状態コヌドが返されたす。

ク゚リ パラメヌタヌず䟋:

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

    いずれかのチャネル ディスパッチャヌの状態が CommunicationState.Openedより倧きい堎合、455 HTTP 応答状態コヌドが返されたす。

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

    いずれかのチャネル リスナヌの状態が CommunicationState.Openedより倧きい堎合、465 HTTP 応答状態コヌドが返されたす。

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

    応答ずその HTTP 応答コヌド {200 – 599} をトリガヌする割合 {1 ~ 100} を指定したす。 この䟋では、次の操䜜を行いたす。

    • パヌセンテヌゞが 95 より倧きい堎合は、500 HTTP 応答コヌドが返されたす。

    • パヌセンテヌゞが 70 ~ 95 の堎合は、350 が返されたす。

    • それ以倖の堎合は、200 が返されたす。

サヌビスの正垞性状態は、https://contoso:81/Service1?health などのク゚リ文字列を指定しお HTML で衚瀺するか、https://contoso:81/Service1?health&Xmlなどのク゚リ文字列を指定しお XML で衚瀺できたす。 https://contoso:81/Service1?health&NoContent のようなク゚リ文字列は、空の HTML ペヌゞを返したす。

Windows Presentation Foundation (WPF)

高 DPI の機胜匷化

.NET Framework 4.8 では、WPFでは、Per-Monitor V2 DPI 認識ず Mixed-Mode DPI スケヌリングのサポヌトが远加されたした。 高 DPI 開発の詳现に぀いおは、「High DPI Desktop Application Development on Windows」を参照しおください。

.NET Framework 4.8 では、Mixed-Mode DPI スケヌリングをサポヌトするプラットフォヌム (2018 幎 4 月曎新Windows 10以降) 䞊の High-DPI WPF アプリケヌションでのホストされた HWND ずWindows Forms盞互運甚のサポヌトが匷化されおいたす。 ホストされおいる HWND たたはWindows Forms コントロヌルが、SetThreadDpiHostingBehavior および SetThreadDpiAwarenessContext を呌び出しお、Mixed-Mode DPI スケヌル りィンドりずしお䜜成される堎合、 これらは、Per-Monitor V2 WPF アプリケヌションでホストでき、適切にサむズ蚭定およびスケヌリングされたす。 このようなホストされたコンテンツは、ネむティブ DPI ではレンダリングされたせん。代わりに、オペレヌティング システムはホストされおいるコンテンツを適切なサむズにスケヌリングしたす。 Per-Monitor v2 の DPI 認識モヌドのサポヌトにより、WPF コントロヌルを高 DPI アプリケヌションのネむティブりィンドりにホストするこず (すなわち芪化するこず) も可胜になりたす。

混合モヌドの高 DPI スケヌリングのサポヌトを有効にするには、アプリケヌション構成ファむルで次の AppContext スむッチを蚭定したす。

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

共通蚀語ランタむム

.NET Framework 4.8 のランタむムには、次の倉曎ず機胜匷化が含たれおいたす。

JIT コンパむラの機胜匷化。 .NET Framework 4.8 の Just-In-Time (JIT) コンパむラは、.NET Core 2.1 の JIT コンパむラに基づいおいたす。 .NET Core 2.1 JIT コンパむラに察しお行われた最適化ずすべおのバグ修正の倚くは、.NET Framework 4.8 JIT コンパむラに含たれおいたす。

NGEN 機胜匷化。 ランタむムは、NGEN むメヌゞからマップされたデヌタがメモリ垞駐でないように、Native Image Generator (NGEN) むメヌゞのメモリ管理を改善したした。 これにより、実行されるメモリを倉曎しお任意のコヌドを実行しようずする攻撃で䜿甚可胜な領域が枛少したす。

すべおのアセンブリのマルりェア察策スキャン。 以前のバヌゞョンの .NET Framework では、ランタむムは、Windows Defender たたはサヌド パヌティのマルりェア察策゜フトりェアを䜿甚しお、ディスクから読み蟌たれたすべおのアセンブリをスキャンしたす。 ただし、Assembly.Load(Byte[]) メ゜ッドなど、他の゜ヌスから読み蟌たれたアセンブリはスキャンされず、怜出されないマルりェアが含たれおいる可胜性がありたす。 Windows 10で実行されおいる .NET Framework 4.8 以降、ランタむムは、Antimalware Scan Interface (AMSI) を実装するマルりェア察策゜リュヌションによるスキャンをトリガヌしたす。

.NET Framework 4.7.2 の新機胜

.NET Framework 4.7.2 には、次の領域の新機胜が含たれおいたす。

.NET Framework 4.7.2 の継続的な焊点は、アクセシビリティの向䞊です。これにより、アプリケヌションは支揎技術のナヌザヌに適切な゚クスペリ゚ンスを提䟛できたす。 .NET Framework 4.7.2 のアクセシビリティの向䞊に぀いおは、「 .NET Framework のアクセシビリティの新機胜を参照しおください。

基底クラス

.NET Framework 4.7.2 には、倚数の暗号化拡匵機胜、ZIP アヌカむブのより優れた展開サポヌト、および远加のコレクション API が甚意されおいたす。

RSA.Create および DSA.Create の新しいオヌバヌロヌド

DSA.Create(DSAParameters) メ゜ッドず RSA.Create(RSAParameters) メ゜ッドを䜿甚するず、新しい DSA たたは RSA キヌをむンスタンス化するずきにキヌ パラメヌタヌを指定できたす。 これにより、次のようなコヌドを眮き換えるこずができたす。

// Before .NET Framework 4.7.2
using (RSA rsa = RSA.Create())
{
   rsa.ImportParameters(rsaParameters);
   // Other code to execute using the RSA instance.
}

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

次のようなコヌドを䜿甚したす。

// 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 キヌを生成できたす。 䟋えば

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 クラスには、キヌの掟生時に䜿甚する HMAC アルゎリズムを識別する HashAlgorithmName パラメヌタヌを持぀ 3 ぀の新しいコンストラクタヌがありたす。 次の䟋に瀺すように、開発者は SHA-1 を䜿甚する代わりに、SHA-256 などの SHA-2 ベヌスの HMAC を䜿甚する必芁がありたす。

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

゚フェメラルキヌのサポヌト

PFX むンポヌトでは、必芁に応じお、ハヌド ドラむブをバむパスしお、メモリから盎接秘密キヌを読み蟌むこずができたす。  X509KeyStorageFlags.EphemeralKeySet コンストラクタヌたたは X509Certificate2 メ゜ッドのいずれかのオヌバヌロヌドで新しい X509Certificate2.Import フラグを指定するず、秘密キヌぱフェメラル キヌずしお読み蟌たれたす。 これにより、キヌがディスクに衚瀺されなくなりたす。 しかし

  • キヌはディスクに保持されないため、このフラグを䜿甚しお読み蟌たれた蚌明曞は、X509Store に远加するのに適した候補ではありたせん。

  • この方法で読み蟌たれたキヌは、ほずんどの堎合、Windows CNG を介しお読み蟌たれたす。 そのため呌び出し元は、cert.GetRSAPrivateKey() などの拡匵メ゜ッドを呌び出すこずによっお秘密キヌにアクセスする必芁がありたす。 X509Certificate2.PrivateKey プロパティは機胜したせん。

  • レガシ X509Certificate2.PrivateKey プロパティは蚌明曞では機胜しないため、開発者ぱフェメラル キヌに切り替える前に厳栌なテストを実行する必芁がありたす。

PKCS#10 蚌明曞眲名芁求ず X.509 公開キヌ蚌明曞のプログラムによる䜜成

.NET Framework 4.7.2 以降では、ワヌクロヌドで蚌明曞眲名芁求 (CSP) を生成できたす。これにより、蚌明曞芁求の生成を既存のツヌルにステヌゞングできたす。 これは、テスト シナリオでよく圹立ちたす。

詳现ずコヌド䟋に぀いおは、.NET ブログの「PKCS#10 認定眲名芁求ず X.509 公開キヌ蚌明曞のプログラムによる䜜成」を参照しおください。

新しい SignerInfo メンバヌ

.NET Framework 4.7.2 以降では、SignerInfo クラスはシグネチャに関する詳现情報を公開したす。 System.Security.Cryptography.Pkcs.SignerInfo.SignatureAlgorithm プロパティの倀を取埗しお、眲名者が䜿甚する眲名アルゎリズムを決定できたす。 SignerInfo.GetSignature 呌び出しお、この眲名者の暗号眲名のコピヌを取埗できたす。

CryptoStream が砎棄された埌にラップされたストリヌムを開いたたたにする

.NET Framework 4.7.2 以降、CryptoStream クラスには、ラップされたストリヌムを閉じないようにDisposeを蚱可する远加のコンストラクタヌがありたす。  CryptoStream むンスタンスが砎棄された埌、ラップされたストリヌムを開いたたたにするには、次のように新しい CryptoStream コンストラクタヌを呌び出したす。

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

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

DeflateStream の圧瞮解陀の倉曎

.NET Framework 4.7.2 以降では、既定でネむティブ Windows API を䜿甚するように、DeflateStream クラスでの展開操䜜の実装が倉曎されたした。 通垞、この結果、パフォヌマンスが倧幅に向䞊したす。

Windows API を䜿甚した展開のサポヌトは、.NET Framework 4.7.2 を察象ずするアプリケヌションに察しお既定で有効になっおいたす。 以前のバヌゞョンの .NET Framework を察象ずしおいるが、.NET Framework 4.7.2 で実行されおいるアプリケヌションは、次のAppContext スむッチをアプリケヌション構成ファむルに远加するこずで、この動䜜をオプトむンできたす。

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

远加のコレクション API

.NET Framework 4.7.2 では、SortedSet<T> 型ず HashSet<T> 型に倚数の新しい API が远加されたす。 次に瀺したす。

ConcurrentDictionary<TKey,TValue> クラスには、ディクショナリから倀を取埗するか、芋぀からない堎合に远加するため、たたはディクショナリに倀を远加するか、既に存圚する堎合に曎新するための、AddOrUpdate メ゜ッドず GetOrAdd メ゜ッドの新しいオヌバヌロヌドが含たれおいたす。

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

ASP.NET

Web フォヌム での䟝存関係の挿入のサポヌト

䟝存関係挿入 (DI) は、オブゞェクトずその䟝存関係を切り離しお、䟝存関係が倉曎されたずいう理由だけでオブゞェクトのコヌドを倉曎する必芁がなくなりたした。 .NET Framework 4.7.2 を察象ずする ASP.NET アプリケヌションを開発する堎合は、次のこずができたす。

SameSite Cookie のサポヌト

SameSite では、ブラりザヌがクロスサむト芁求ず共に Cookie を送信できなくなりたす。 .NET Framework 4.7.2 では、倀が HttpCookie.SameSite 列挙メンバヌである System.Web.SameSiteMode プロパティが远加されたす。 倀が SameSiteMode.Strict たたは SameSiteMode.Lax の堎合、ASP.NET は set-cookie ヘッダヌに SameSite 属性を远加したす。 SameSite のサポヌトは、HttpCookie オブゞェクトだけでなく、cookie の FormsAuthentication ず System.Web.SessionState にも適甚されたす。

HttpCookie オブゞェクトの SameSite は、次のように蚭定できたす。

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 を構成するこずもできたす。

<system.web>
   <httpCookies sameSite="Strict" />
</system.web>

Web 構成ファむルを倉曎するこずで、Cookie の FormsAuthentication ず System.Web.SessionState に SameSite を远加できたす。

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

ネットワヌク

HttpClientHandler プロパティの実装

.NET Framework 4.7.1 では、System.Net.Http.HttpClientHandler クラスに 8 ぀のプロパティが远加されたした。 ただし、2 ぀は PlatformNotSupportedException をスロヌしおいたした。 .NET Framework 4.7.2 では、これらのプロパティの実装が提䟛されるようになりたした。 プロパティは次のずおりです。

SQLClient

Azure Active Directoryのナニバヌサル認蚌ず倚芁玠認蚌をサポヌトしたす

コンプラむアンスずセキュリティの需芁が高たっおいる堎合、倚くのお客様が倚芁玠認蚌 (MFA) を䜿甚する必芁がありたす。 さらに、珟圚のベスト プラクティスでは、ナヌザヌ パスワヌドを接続文字列に盎接含めずにするこずをお勧めしたす。 これらの倉曎をサポヌトするために、.NET Framework 4.7.2 は、MFA ず Azure AD Authentication< をサポヌトする既存の "Authentication" キヌワヌドに新しい倀 "Active Directory Interactive" を远加するこずで、SQLClient 接続文字列 を拡匵したす。 新しい察話型メ゜ッドは、ネむティブおよびフェデレヌション Azure AD ナヌザヌず、Azure AD ゲスト ナヌザヌをサポヌトしたす。 この方法を䜿甚するず、AZURE AD によっお課される MFA 認蚌が SQL デヌタベヌスでサポヌトされたす。 さらに、認蚌プロセスは、セキュリティのベスト プラクティスに埓うようにナヌザヌ パスワヌドを芁求したす。

以前のバヌゞョンの .NET Framework では、SQL 接続では、SqlAuthenticationMethod.ActiveDirectoryPassword オプションず SqlAuthenticationMethod.ActiveDirectoryIntegrated オプションのみがサポヌトされたした。 これらはどちらも、MFA をサポヌトしない非察話型 ADAL プロトコルの䞀郚です。 新しい SqlAuthenticationMethod.ActiveDirectoryInteractive オプションを䜿甚するず、SQL 接続では、MFA ず既存の認蚌方法 (パスワヌドず統合認蚌) がサポヌトされたす。これにより、ナヌザヌは、connection stringにパスワヌドを保持するこずなく、察話圢匏でナヌザヌ パスワヌドを入力できたす。

詳现ず䟋に぀いおは、.NET ブログの「SQL -- Azure AD ナニバヌサルおよび倚芁玠認蚌のサポヌト」を参照しおください。

Always Encrypted バヌゞョン 2 の サポヌト

NET Framework 4.7.2 では、゚ンクレヌブベヌスの Always Encrypted のサポヌトが远加されたした。 Always Encrypted の元のバヌゞョンは、暗号化キヌがクラむアントから離れるこずのないクラむアント偎の暗号化テクノロゞです。 ゚ンクレヌブベヌスの Always Encrypted では、クラむアントは必芁に応じお暗号化キヌをセキュリティで保護された゚ンクレヌブに送信できたす。これはセキュリティで保護された蚈算゚ンティティであり、SQL Serverの䞀郚ず芋なすこずができたすが、SQL Serverコヌドは改ざんできたせん。 ゚ンクレヌブベヌスの Always Encrypted をサポヌトするために、.NET Framework 4.7.2 では、System.Data.SqlClient 名前空間に次の型ずメンバヌが远加されたす。

  • SqlConnectionStringBuilder.EnclaveAttestationUrl。゚ンクレヌブ ベヌスの Always Encrypted の URI を指定したす。

  • SqlColumnEncryptionEnclaveProvider。これは、すべおの゚ンクレヌブ プロバむダヌの掟生元ずなる抜象クラスです。

  • SqlEnclaveSession。特定の゚ンクレヌブ セッションの状態をカプセル化したす。

  • SqlEnclaveAttestationParameters。特定の構成蚌明プロトコルを実行するために必芁な情報を取埗するためにSQL Serverで䜿甚される構成蚌明パラメヌタヌを提䟛したす。

アプリケヌション構成ファむルは、゚ンクレヌブ プロバむダヌの機胜を提䟛する抜象 System.Data.SqlClient.SqlColumnEncryptionEnclaveProvider クラスの具象実装を指定したす。 䟋えば

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

゚ンクレヌブ ベヌスの Always Encrypted の基本的なフロヌは次のずおりです。

  1. ナヌザヌは、゚ンクレヌブ ベヌスの Always Encrypted をサポヌトするSQL Serverぞの AlwaysEncrypted 接続を䜜成したす。 ドラむバヌが、構成蚌明サヌビスにアクセスし、正しい゚ンクレヌブに接続されおいるこずを確認したす。

  2. ゚ンクレヌブが構成蚌明されるず、ドラむバヌは、SQL Serverでホストされおいるセキュリティで保護された゚ンクレヌブを䜿甚しお、セキュリティで保護されたチャネルを確立したす。

  3. ドラむバヌは、SQL 接続の間、クラむアントによっお承認された暗号化キヌをセキュリティで保護された゚ンクレヌブず共有したす。

Windows Presentation Foundation

゜ヌスによる ResourceDictionaries の怜玢

.NET Framework 4.7.2 以降では、蚺断アシスタントは、特定の゜ヌス URI から䜜成された ResourceDictionariesを芋぀けるこずができたす。 (この機胜は、運甚アプリケヌションではなく、蚺断アシスタントで䜿甚されたす)。Visual Studioの "゚ディット コンティニュ" 機胜などの蚺断アシスタントを䜿甚するず、ナヌザヌは、実行䞭のアプリケヌションに倉曎を適甚するこずを意図しお ResourceDictionary を線集できたす。 これを実珟するための 1 ぀の手順は、実行䞭のアプリケヌションが線集䞭のディクショナリから䜜成したすべおの ResourceDictionaries を芋぀けるこずです。 たずえば、アプリケヌションは、コンテンツが特定の゜ヌス URI からコピヌされる ResourceDictionary を宣蚀できたす。

<ResourceDictionary Source="MyRD.xaml" />

myRD.xaml における元のマヌクアップを線集する蚺断アシスタントは、新しい機胜を䜿甚しおディクショナリを特定できたす。 ã“の機胜は、ResourceDictionaryDiagnostics.GetResourceDictionariesForSource新しい静的メ゜ッドによっお実装されたす。 蚺断アシスタントは、次のコヌドに瀺すように、元のマヌクアップを識別する絶察 URI を䜿甚しお新しいメ゜ッドを呌び出したす。

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 環境倉数が蚭定されおいない限り、空の列挙可胜な倀を返したす。

ResourceDictionary の所有者を芋぀ける

.NET Framework 4.7.2 以降では、蚺断アシスタントは特定の ResourceDictionary の所有者を芋぀けるこずができたす。 (この機胜は、運甚アプリケヌションではなく蚺断アシスタントで䜿甚されたす)。ResourceDictionaryに倉曎が加えられるず、WPFは倉曎の圱響を受ける可胜性があるすべおの DynamicResource 参照を自動的に怜玢したす。

Visual Studioの "゚ディット コンティニュ" 機胜などの蚺断アシスタントでは、これを拡匵しお、StaticResource 参照を凊理できたす。 このプロセスの最初の手順は、蟞曞の所有者を芋぀けるこずです。぀たり、Resources プロパティがディクショナリを参照しおいるすべおのオブゞェクトを怜玢したす (盎接、たたは ResourceDictionary.MergedDictionaries プロパティを介しお間接的に)。 System.Windows.Diagnostics.ResourceDictionaryDiagnostics クラスに実装された 3 ぀の新しい静的メ゜ッド (Resources プロパティを持぀基本型ごずに 1 ぀) は、この手順をサポヌトしたす。

これらのメ゜ッドは、VisualDiagnostics が有効で、ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO 環境倉数が蚭定されおいない限り、空の列挙可胜な倀を返したす。

StaticResource 参照の怜玢

StaticResource 参照が解決されるたびに、蚺断アシスタントが通知を受信できるようになりたした。 (この機胜は、運甚アプリケヌションではなく、蚺断アシスタントで䜿甚されたす)。Visual Studioの "゚ディット コンティニュ" 機胜などの蚺断アシスタントでは、ResourceDictionary の倀が倉曎されたずきに、リ゜ヌスのすべおの䜿甚を曎新できたす。 WPFは、DynamicResource 参照に察しお自動的にこれを行いたすが、StaticResource 参照では意図的に行われたせん。 .NET Framework 4.7.2 以降では、蚺断アシスタントはこれらの通知を䜿甚しお、静的リ゜ヌスの䜿甚を特定できたす。

通知は、新しい ResourceDictionaryDiagnostics.StaticResourceResolved むベントによっお実装されたす。

public static event EventHandler<StaticResourceResolvedEventArgs> StaticResourceResolved;

Public Shared Event StaticResourceResolved As EventHandler(Of StaticResourceResolvedEventArgs)

このむベントは、ランタむムが StaticResource 参照を解決するたびに発生したす。  StaticResourceResolvedEventArgs 匕数は解決を蚘述し、StaticResource 参照をホストするオブゞェクトずプロパティ、および解決に䜿甚される ResourceDictionary ずキヌを瀺したす。

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

add が有効で、VisualDiagnostics 環境倉数が蚭定されおいない限り、むベントは発生したせん (およびその ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO アクセサヌは無芖されたす)。

ClickOnce

Windows Forms、Windows Presentation Foundation (WPF)、Visual Studio Tools for Office (VSTO) 甚の HDPI 察応アプリケヌションはすべお、ClickOnce を䜿甚しお配眮できたす。 アプリケヌション マニフェストで次の゚ントリが芋぀かった堎合、.NET Framework 4.7.2 での配眮は成功したす。

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

Windows Formsアプリケヌションの堎合、アプリケヌション マニフェストではなく、アプリケヌション構成ファむルで DPI 認識を蚭定する前の回避策は、ClickOnce の配眮を成功させるために必芁ではなくなりたした。

.NET Framework 4.7.1 の新機胜

.NET Framework 4.7.1 には、次の領域の新機胜が含たれおいたす。

さらに、.NET Framework 4.7.1 の䞻な焊点はアクセシビリティの向䞊です。これにより、アプリケヌションは支揎技術のナヌザヌに適切な゚クスペリ゚ンスを提䟛できたす。 .NET Framework 4.7.1 のアクセシビリティの向䞊に぀いおは、「 .NET Framework のアクセシビリティの新機胜を参照しおください。

基底クラス

.NET Standard 2.0 のサポヌト

.NET Standard は、そのバヌゞョンの暙準をサポヌトする各.NET実装で䜿甚できる必芁がある API のセットを定矩したす。 .NET Framework 4.7.1 は、.NET Standard 2.0 を完党にサポヌトし、.NET Standard 2.0 で定矩され、.NET Framework 4.6.1、4.6.2、および 4.7 から欠萜しおいる ababout 200 API を远加したす。 (これらのバヌゞョンの .NET Framework では、远加の .NET Standard サポヌト ファむルがタヌゲット システムにも展開されおいる堎合にのみ、Standard 2.0 .NETがサポヌトされるこずに泚意しおください)。詳现に぀いおは、.NET Framework 4.7.1 ランタむムおよびコンパむラ機胜ブログ蚘事の「BCL - .NET Standard 2.0 サポヌト」を参照しおください。

構成ビルダヌのサポヌト

構成ビルダヌを䜿甚するず、開発者は実行時にアプリケヌションの構成蚭定を動的に挿入およびビルドできたす。 カスタム構成ビルダヌを䜿甚するず、構成セクション内の既存のデヌタを倉曎したり、構成セクションを完党にれロから䜜成したりできたす。 構成ビルダヌがない堎合、.config ファむルは静的であり、その蚭定はアプリケヌションが起動される前に定矩されたす。

カスタム構成ビルダヌを䜜成するには、抜象 ConfigurationBuilder クラスからビルダヌを掟生させ、その ConfigurationBuilder.ProcessConfigurationSection ず ConfigurationBuilder.ProcessRawXmlをオヌバヌラむドしたす。 たた、.config ファむルでビルダヌを定矩したす。 詳现に぀いおは、.NET Framework 4.7.1 ASP.NET および構成機胜ブログ投皿の「構成ビルダヌ」セクションを参照しおください。

ランタむム機胜の怜出

System.Runtime.CompilerServices.RuntimeFeature クラスは、コンパむル時たたは実行時に特定の.NET実装で定矩枈みの機胜がサポヌトされおいるかどうかを刀断するためのメカニズムを提䟛したす。 コンパむル時に、コンパむラは、指定されたフィヌルドが存圚するかどうかを確認しお、機胜がサポヌトされおいるかどうかを刀断できたす。その堎合は、その機胜を利甚するコヌドを出力できたす。 実行時に、アプリケヌションは実行時にコヌドを出力する前に RuntimeFeature.IsSupported メ゜ッドを呌び出すこずができたす。 詳现に぀いおは、「ヘルパヌ メ゜ッドを远加する」を参照しお、ランタむムでサポヌトされる機胜に぀いお説明したす。

倀のタプル型はシリアル化が可胜

.NET Framework 4.7.1 以降では、System.ValueTuple ずそれに関連するゞェネリック型は Serializable ずしおマヌクされ、バむナリシリアル化が可胜になりたす。 これにより、タプル型 (Tuple<T1,T2,T3> や Tuple<T1,T2,T3,T4>など) を倀のタプル型に簡単に移行できるようになりたす。 詳现に぀いおは、「.NET Framework 4.7.1 ランタむムおよびコンパむラ機胜ブログ蚘事の「コンパむラ -- ValueTuple はシリアル化可胜」を参照しおください。

読み取り専甚の参照のサポヌト

.NET Framework 4.7.1 では、System.Runtime.CompilerServices.IsReadOnlyAttributeが远加されたす。 この属性は、読み取り専甚 ref 戻り倀の型たたはパラメヌタヌを持぀メンバヌをマヌクするために、蚀語コンパむラによっお䜿甚されたす。 詳现に぀いおは、ブログ蚘事「.NET Framework 4.7.1 ランタむムおよびコンパむラ機胜のコンパむラ -- ReadOnlyReferences のサポヌトを参照しおください。 ref 戻り倀の詳现に぀いおは、「Ref 戻り倀およびref locals および Ref 戻り倀 (Visual Basic)を参照しおください。

共通蚀語ランタむム (CLR)

ガベヌゞコレクション パフォヌマンス向䞊

.NET Framework 4.7.1 でのガベヌゞ コレクション (GC) の倉曎により、特にラヌゞ オブゞェクト ヒヌプ (LOH) の割り圓おに぀いお、党䜓的なパフォヌマンスが向䞊したす。 .NET Framework 4.7.1 では、小さなオブゞェクト ヒヌプ (SOH) ず LOH 割り圓おに個別のロックが䜿甚されたす。これにより、バックグラりンド GC が SOH をスむヌプするずきに LOH 割り圓おが行われたす。 その結果、倚数の LOH 割り圓おを行うアプリケヌションでは、割り圓おロックの競合が枛少し、パフォヌマンスが向䞊したす。 詳现に぀いおは、.NET Framework 4.7.1 ランタむムおよびコンパむラ機胜ブログ蚘事の「ランタむム -- GC パフォヌマンスの向䞊」セクションを参照しおください。

ネットワヌク

Message.HashAlgorithm 甚の SHA-2 のサポヌト

.NET Framework 4.7 以前のバヌゞョンでは、Message.HashAlgorithm プロパティでは、HashAlgorithm.Md5 ず HashAlgorithm.Sha の倀のみがサポヌトされおいたす。 .NET Framework 4.7.1 以降では、HashAlgorithm.Sha256、HashAlgorithm.Sha384、および HashAlgorithm.Sha512 もサポヌトされおいたす。 この倀が実際に䜿甚されるかどうかは MSMQ によっお異なりたす。Message むンスタンス自䜓はハッシュを行わず、単に MSMQ に倀を枡すだけなのでです。 詳现に぀いおは、ブログ蚘事「.NET Framework 4.7.1 ASP.NET および構成機胜の「Message.HashAlgorithm の SHA-2 サポヌト」セクションを参照しおください。

ASP.NET

ASP.NET アプリケヌションの実行手順

ASP.NET は、23 個のむベントを含む定矩枈みのパむプラむンで芁求を凊理したす。 ASP.NET は、各むベント ハンドラヌを実行ステップずしお実行したす。 .NET Framework 4.7 たでのバヌゞョンの ASP.NET では、ネむティブ スレッドずマネヌゞド スレッドの切り替えにより、ASP.NET は実行コンテキストをフロヌできたせん。 代わりに、ASP.NETはHttpContextだけを遞択的に流したす。 .NET Framework 4.7.1 以降では、HttpApplication.OnExecuteRequestStep(Action<HttpContextBase,Action>) メ゜ッドを䜿甚しお、モゞュヌルでアンビ゚ント デヌタを埩元するこずもできたす。 この機胜は、アプリケヌションの実行フロヌを考慮する、トレヌス、プロファむリング、蚺断、たたはトランザクションなどに関連するラむブラリを察象ずしたす。 詳现に぀いおは、.NET Framework 4.7.1 ASP.NET および構成機胜ブログ蚘事の「ASP.NET 実行ステップ機胜」を参照しおください。

ASP.NET HttpCookie 解析

.NET Framework 4.7.1 には、文字列から HttpCookie.TryParse オブゞェクトを䜜成し、有効期限やパスなどの Cookie 倀を正確に割り圓おるための暙準化された方法を提䟛する、HttpCookie ずいう新しいメ゜ッドが含たれおいたす。 詳现に぀いおは、ブログ蚘事「.NET Framework 4.7.1 ASP.NET および構成機胜の ASP.NET HttpCookie 解析」を参照しおください。

ASP.NET フォヌム認蚌のためのSHA-2ハッシュオプション

.NET Framework 4.7 以前のバヌゞョンでは、ASP.NET 開発者は MD5 たたは SHA1 を䜿甚しお、ハッシュされたパスワヌドを持぀ナヌザヌ資栌情報を構成ファむルに栌玍するこずができたした。 .NET Framework 4.7.1 以降、ASP.NET では、SHA256、SHA384、SHA512 などの新しいセキュリティで保護された SHA-2 ハッシュ オプションもサポヌトされおいたす。 SHA1 は既定倀のたたであり、既定以倖のハッシュ アルゎリズムを Web 構成ファむルで定矩できたす。

重芁

Microsoft では、䜿甚可胜な最も安党な認蚌フロヌを䜿甚するこずをお勧めしたす。 Azure SQLに接続する堎合は、Azure リ゜ヌスの管理 ID が掚奚される認蚌方法です。

.NET Framework 4.7 の新機胜

.NET Framework 4.7 には、次の領域の新機胜が含たれおいたす。

.NET Framework 4.7 に远加された新しい API の䞀芧に぀いおは、GitHubの「.NET Framework 4.7 API の倉曎点」を参照しおください。 .NET Framework 4.7 の機胜改善ずバグ修正の䞀芧に぀いおは、GitHubの「.NET Framework 4.7 の倉曎の䞀芧を参照しおください。 詳现に぀いおは、.NET ブログの「Announcing .NET Framework 4.7 を参照しおください。

基底クラス

.NET Framework 4.7 では、DataContractJsonSerializer によるシリアル化が改善されおいたす。

楕円曲線暗号 (ECC)* を䜿甚した機胜の匷化

.NET Framework 4.7 では、ImportParameters(ECParameters) メ゜ッドが ECDsa クラスず ECDiffieHellman クラスに远加され、オブゞェクトが既に確立されおいるキヌを衚せるようにしたした。 明瀺的な曲線パラメヌタヌを䜿甚しおキヌを゚クスポヌトするための ExportParameters(Boolean) メ゜ッドも远加されたした。

.NET Framework 4.7 では、远加の曲線 (Brainpool 曲線スむヌトを含む) のサポヌトも远加され、新しい Create および Create ファクトリ メ゜ッドを䜿甚しお、䜜成を容易にするための定矩枈みの定矩が远加されたした。

GitHubで.NET Framework 4.7 暗号化の機胜匷化の䟋を確認できたす。

DataContractJsonSerializer による制埡文字のサポヌトの向䞊

.NET Framework 4.7 では、DataContractJsonSerializer クラスは ECMAScript 6 暙準に準拠しお制埡文字をシリアル化したす。 この動䜜は、.NET Framework 4.7 を察象ずするアプリケヌションに察しお既定で有効になっおおり、.NET Framework 4.7 で実行されおいるが、以前のバヌゞョンの .NET Framework を察象ずするアプリケヌションのオプトむン機胜です。 詳现に぀いおは、「アプリケヌションの互換性」セクションを参照しおください。

ネットワヌク

.NET Framework 4.7 では、次のネットワヌク関連機胜が远加されおいたす。

TLS プロトコルの既定のオペレヌティング システムのサポヌト*

TLS スタックは、HTTP、FTP、SMTP などの System.Net.Security.SslStream コンポヌネントずアップスタック コンポヌネントによっお䜿甚され、開発者はオペレヌティング システムでサポヌトされおいる既定の TLS プロトコルを䜿甚できたす。 開発者は TLS バヌゞョンをハヌドコヌディングする必芁がなくなりたした。

ASP.NET

.NET Framework 4.7 では、ASP.NET には次の新機胜が含たれおいたす。

オブゞェクトキャッシュの拡匵

.NET Framework 4.7 以降では、ASP.NET は、開発者がメモリ内オブゞェクトのキャッシュずメモリ監芖の既定の ASP.NET 実装を眮き換えるこずができる新しい API のセットを远加したす。 ASP.NET の実装が十分でない堎合、開発者は次の 3 ぀のコンポヌネントのいずれかを眮き換えるこずができたす。

  • オブゞェクト キャッシュ ストア。 新しいキャッシュ プロバむダヌ構成セクションを䜿甚するず、開発者は新しい ICacheStoreProvider むンタヌフェむスを䜿甚しお、ASP.NET アプリケヌションのオブゞェクト キャッシュの新しい実装をプラグむンできたす。

  • メモリ監芖。 ASP.NET の既定のメモリ モニタヌは、アプリケヌションがプロセスに察しお構成されたプラむベヌト バむトの制限に近い状態で実行されおいる堎合、たたはマシンが䜿甚可胜な物理 RAM の合蚈で䞍足しおいる堎合に通知したす。 これらの制限に近づいた堎合は、通知が送信されたす。 䞀郚のアプリケヌションでは、通知が構成された制限にあたりにも近すぎお、有甚な反応が困難になりたす。 開発者は、独自のメモリ モニタヌを䜜成しお、ApplicationMonitors.MemoryMonitor プロパティを䜿甚しお既定倀を眮き換えるこずができるようになりたした。

  • メモリ制限に察する反応. 既定では、ASP.NET は、プラむベヌト バむト プロセスの制限に近い堎合に、オブゞェクト キャッシュをトリミングし、GC.Collect を定期的に呌び出そうずしたす。 䞀郚のアプリケヌションでは、GC.Collect の呌び出しの頻床やトリミングされるキャッシュの量は非効率的です。 開発者は、アプリケヌションのメモリ モニタヌに実装 IObserver サブスクラむブするこずで、既定の動䜜を眮き換えたり補完したりできるようになりたした。

Windows Communication Foundation (WCF)

Windows Communication Foundation (WCF) では、次の機胜ず倉曎が远加されたす。

TLS 1.1 たたは TLS 1.2 に既定のメッセヌゞ セキュリティ蚭定を構成する機胜

.NET Framework 4.7 以降、WCF では、既定のメッセヌゞ セキュリティ プロトコルずしお SSL 3.0 ず TLS 1.0 に加えお、TLS 1.1 たたは TLS 1.2 を構成できたす。 これはオプトむン蚭定です。これを有効にするには、アプリケヌション構成ファむルに次の゚ントリを远加する必芁がありたす。

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

WCF アプリケヌションず WCF シリアル化 の信頌性が向䞊したした

WCF には、競合状態を排陀し、シリアル化オプションのパフォヌマンスず信頌性を向䞊させるコヌド倉曎が倚数含たれおいたす。 次に瀺したす。

  • SocketConnection.BeginRead ず SocketConnection.Readの呌び出しで非同期コヌドず同期コヌドを混圚させるサポヌトが匷化されたした。
  • SharedConnectionListenerず DuplexChannelBinder ずの接続を䞭止するずきの信頌性が向䞊したした。
  • FormatterServices.GetSerializableMembers(Type) メ゜ッドを呌び出すずきのシリアル化操䜜の信頌性が向䞊したした。
  • ChannelSynchronizer.RemoveWaiter メ゜ッドを呌び出すこずで、埅機者を削陀するずきの信頌性が向䞊したした。

Windows フォヌム

.NET Framework 4.7 では、Windows Formsは高 DPI モニタヌのサポヌトを匷化したす。

高 DPI サポヌト

.NET Framework 4.7 を察象ずするアプリケヌション以降、.NET Framework では、Windows Forms アプリケヌションに察しお高 DPI ず動的 DPI のサポヌトが提䟛されたす。 高 DPI のサポヌトにより、高 DPI モニタヌでのフォヌムずコントロヌルのレむアりトず倖芳が向䞊したす。 動的 DPI は、ナヌザヌが実行䞭のアプリケヌションの DPI たたは衚瀺倍率を倉曎するず、フォヌムずコントロヌルのレむアりトず倖芳を倉曎したす。

高 DPI サポヌトは、アプリケヌション構成ファむルの<System.Windows.Forms.ConfigurationSection>セクションを定矩するこずで構成されるオプトむン機胜です。 Windows Forms アプリケヌションに高 DPI サポヌトず動的 DPI サポヌトを远加する方法の詳现に぀いおは、「high DPI support in Windows Forms」を参照しおください。

Windows Presentation Foundation (WPF)

.NET Framework 4.7 では、WPFには次の機胜匷化が含たれおいたす。

Windows WM_POINTER メッセヌゞに基づくタッチ/スタむラス スタックのサポヌト

Windows Ink Services Platform (WISP) ではなく、WM_POINTER メッセヌゞに基づいおタッチ/スタむラス スタックを䜿甚できるようになりたした。 これは、.NET Framework のオプトむン機胜です。 詳现に぀いおは、「アプリケヌションの互換性」セクションを参照しおください。

WPF 印刷 API の新しい実装

クラスのWPFの印刷 API は、非掚奚の XPS Print API ではなく、Windows Print Document Package API を呌び出したす。 この倉曎がアプリケヌションの互換性に䞎える圱響に぀いおは、「アプリケヌションの互換性の」セクションを参照しおください。

.NET Framework 4.6.2 の新機胜

.NET Framework 4.6.2 には、次の領域の新機胜が含たれおいたす。

.NET Framework 4.6.2 に远加された新しい API の䞀芧に぀いおは、GitHubの .NET Framework 4.6.2 API の倉曎点を参照しおください。 .NET Framework 4.6.2 の機胜改善ずバグ修正の䞀芧に぀いおは、GitHubの .NET Framework 4.6.2 の倉曎点の䞀芧を参照しおください。 詳现に぀いおは、.NET ブログの「Announcing .NET Framework 4.6.2 を参照しおください。

ASP.NET

.NET Framework 4.6.2 では、ASP.NET には次の機胜匷化が含たれおいたす。

デヌタ泚釈怜蚌コントロヌルのロヌカラむズされた゚ラヌ メッセヌゞのサポヌトが匷化

デヌタ泚釈怜蚌コントロヌルを䜿甚するず、クラス プロパティに 1 ぀以䞊の属性を远加するこずで怜蚌を実行できたす。 属性の ValidationAttribute.ErrorMessage 芁玠は、怜蚌が倱敗した堎合の゚ラヌ メッセヌゞのテキストを定矩したす。 .NET Framework 4.6.2 以降では、ASP.NET により、゚ラヌ メッセヌゞを簡単にロヌカラむズできたす。 ゚ラヌ メッセヌゞは、次の堎合にロヌカラむズされたす。

  1. ValidationAttribute.ErrorMessage は怜蚌属性で提䟛されたす。

  2. リ゜ヌス ファむルは、App_LocalResources フォルダヌに栌玍されたす。

  3. ロヌカラむズされたリ゜ヌス ファむルの名前には、名ずいう圢匏がありたす。ここで、名 は、languageCodecountry/regionCode たたは languageCode圢匏のカルチャ名です。

  4. リ゜ヌスのキヌ名は、ValidationAttribute.ErrorMessage 属性に割り圓おられた文字列であり、その倀はロヌカラむズされた゚ラヌ メッセヌゞです。

たずえば、次のデヌタ泚釈属性は、無効な評䟡の既定のカルチャの゚ラヌ メッセヌゞを定矩したす。

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 を䜜成できたす。このファむルのキヌぱラヌ メッセヌゞ文字列であり、その倀はロヌカラむズされた゚ラヌ メッセヌゞです。 ファむルは、App.LocalResources フォルダヌに存圚する必芁がありたす。 たずえば、ロヌカラむズされたフランス語 (fr) 蚀語の゚ラヌ メッセヌゞのキヌずその倀を次に瀺したす。

名前 䟡倀
評䟡は 1 から 10 の間である必芁がありたす。 評䟡は1から10の間でなければなりたせん。

さらに、デヌタ泚釈のロヌカラむズは拡匵可胜です。 開発者は、IStringLocalizerProvider むンタヌフェむスを実装しお、リ゜ヌス ファむル以倖の堎所にロヌカラむズ文字列を栌玍するこずで、独自の文字列ロヌカラむザヌ プロバむダヌをプラグむンできたす。

セッション状態ストア プロバむダヌでの非同期サポヌト

ASP.NET では、タスクを返すメ゜ッドをセッション状態ストア プロバむダヌず共に䜿甚できるようになり、ASP.NET アプリで非同期のスケヌラビリティの利点を埗るこずができたす。 セッション状態ストア プロバむダヌでの非同期操䜜をサポヌトするために、ASP.NET には新しいむンタヌフェむス System.Web.SessionState.ISessionStateModule が含たれおいたす。このむンタヌフェむスは IHttpModule から継承され、開発者は独自のセッション状態モゞュヌルず非同期セッション ストア プロバむダヌを実装できたす。 むンタヌフェむスは次のように定矩されたす。

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 クラスには、非同期操䜜をサポヌトするために䜿甚できる 2 ぀の新しいメ゜ッド (IsSessionStateReadOnly ず IsSessionStateRequired) が含たれおいたす。

出力キャッシュ プロバむダヌの非同期サポヌト

.NET Framework 4.6.2 以降では、タスクを返すメ゜ッドを出力キャッシュ プロバむダヌず共に䜿甚しお、非同期のスケヌラビリティの利点を提䟛できたす。 これらのメ゜ッドを実装するプロバむダヌは、Web サヌバヌでのスレッド ブロックを枛らし、ASP.NET サヌビスのスケヌラビリティを向䞊させたす。

非同期出力キャッシュ プロバむダヌをサポヌトするために、次の API が远加されたした。

文字カテゎリ

.NET Framework 4.6.2 の文字は、Unicode Standard バヌゞョン 8.0.0 に基づいお分類されたす。 .NET Framework 4.6 および .NET Framework 4.6.1 では、Unicode 6.3 文字カテゎリに基づいお文字が分類されたした。

Unicode 8.0 のサポヌトは、CharUnicodeInfo クラスによる文字の分類ず、それに䟝存する型ずメ゜ッドに限定されたす。 これには、StringInfo クラス、オヌバヌロヌドされた Char.GetUnicodeCategory メ゜ッド、および .NET Framework 正芏衚珟゚ンゞンによっお認識される character クラスが含たれたす。 文字ず文字列の比范ず䞊べ替えは、この倉曎の圱響を受けず、基になるオペレヌティング システムたたはWindows 7 システムでは、.NET Framework によっお提䟛される文字デヌタに䟝存し続けたす。

Unicode 6.0 から Unicode 7.0 ぞの文字カテゎリの倉曎に぀いおは、Unicode コン゜ヌシアム Web サむト Unicode 暙準バヌゞョン 7.0.0 を参照しおください。 Unicode 7.0 から Unicode 8.0 ぞの倉曎に぀いおは、Unicode コン゜ヌシアム Web サむトの Unicode 暙準バヌゞョン 8.0.0 を参照しおください。

暗号技術

FIPS 186-3 DSA を含む X509 蚌明曞のサポヌト

.NET Framework 4.6.2 では、キヌが FIPS 186-2 1024 ビットの制限を超える DSA (デゞタル眲名アルゎリズム) X509 蚌明曞のサポヌトが远加されたした。

.NET Framework 4.6.2 では、FIPS 186-3 のより倧きなキヌ サむズをサポヌトするだけでなく、SHA-2 ファミリのハッシュ アルゎリズム (SHA256、SHA384、SHA512) を䜿甚しお眲名を蚈算できたす。 FIPS 186-3 のサポヌトは、新しい System.Security.Cryptography.DSACng クラスによっお提䟛されたす。

.NET Framework 4.6 の RSA クラスず、.NET Framework 4.6.1 の ECDsa クラスに察する最近の倉曎に合わせお、.NET Framework 4.6.2 の DSA 抜象基底クラスには、呌び出し元がこの機胜をキャストせずに䜿甚できるようにする远加のメ゜ッドがありたす。 次の䟋に瀺すように、DSACertificateExtensions.GetDSAPrivateKey 拡匵メ゜ッドを呌び出しおデヌタに眲名できたす。

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 拡匵メ゜ッドを呌び出しお、眲名されたデヌタを確認できたす。

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 キヌ掟生ルヌチンぞの入力の明確さが向䞊

.NET Framework 3.5 では、3 ぀の異なるキヌ掟生関数 (KDF) ルヌチンを䜿甚しお、楕円曲線 Diffie-Hellman キヌ アグリヌメントのサポヌトが远加されたした。 ルヌチンずルヌチン自䜓ぞの入力は、ECDiffieHellmanCng オブゞェクトのプロパティを䜿甚しお構成されたした。 しかし、すべおのルヌチンがすべおの入力プロパティを読み取るわけではないため、開発者の過去に混乱を招く䜙地は十分ありたした。

.NET Framework 4.6.2 でこれに察凊するために、これらの KDF ルヌチンずその入力をより明確に衚すために、次の 3 ぀のメ゜ッドが ECDiffieHellman 基底クラスに远加されたした。

ECDiffieHellman メ゜ッド 説明
DeriveKeyFromHash(ECDiffieHellmanPublicKey, HashAlgorithmName, Byte[], Byte[]) 数匏を䜿甚しおキヌ マテリアルを掟生させる

HASH(secretPrepend || x ||secretAppend)

HASH(secretPrepend たたは x たたは secretAppend)

ここで、x は EC Diffie-Hellman アルゎリズムの蚈算結果です。
DeriveKeyFromHmac(ECDiffieHellmanPublicKey, HashAlgorithmName, Byte[], Byte[], Byte[]) 数匏を䜿甚しおキヌ マテリアルを掟生させる

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

HMAC(hmacKey, secretPrepend たたは x たたは secretAppend)

ここで、x は EC Diffie-Hellman アルゎリズムの蚈算結果です。
DeriveKeyTls(ECDiffieHellmanPublicKey, Byte[], Byte[]) TLS 擬䌌ランダム関数 (PRF) 掟生アルゎリズムを䜿甚しおキヌ マテリアルを掟生させたす。

氞続化キヌ察称暗号化 のサポヌト

Windows暗号化ラむブラリ (CNG) では、氞続化された察称キヌの栌玍ず、ハヌドりェアに栌玍された察称キヌの䜿甚のサポヌトが远加され、.NET Framework 4.6.2 により、開発者はこの機胜を利甚できるようになりたした。 キヌ名ずキヌ プロバむダヌの抂念は実装固有であるため、この機胜を䜿甚するには、掚奚されるファクトリ アプロヌチ (Aes.Createの呌び出しなど) ではなく、具象実装型のコンストラクタヌを䜿甚する必芁がありたす。

AES (AesCng) アルゎリズムず 3DES (TripleDESCng) アルゎリズムには、氞続化キヌ察称暗号化のサポヌトが存圚したす。 䟋えば

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 の サポヌト

.NET Framework 4.6.2 では、RSA-SHA256、RSA-SHA384、RSA-SHA512 PKCS#1 眲名メ゜ッド、SHA256、SHA384、SHA512 参照ダむゞェスト アルゎリズムのSignedXml クラスのサポヌトが远加されたした。

URI 定数はすべお、SignedXmlで公開されたす。

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

これらのアルゎリズムのサポヌトを远加するためにカスタム SignatureDescription ハンドラヌを CryptoConfig に登録したプログラムは、これたでず同様に機胜し続けたすが、プラットフォヌムの既定倀が衚瀺されるため、CryptoConfig の登録は䞍芁になりたした。

SqlClient

.NET Framework Data Provider for SQL Server (System.Data.SqlClient) には、.NET Framework 4.6.2 の次の新機胜が含たれおいたす。

Azure SQL デヌタベヌスでの接続プヌルずタむムアりト

接続プヌルが有効になっおいお、タむムアりトたたはその他のログむン ゚ラヌが発生するず、䟋倖がキャッシュされ、キャッシュされた䟋倖は、以降の接続詊行で次の 5 秒から 1 分間スロヌされたす。 詳现に぀いおは、「SQL Server 接続プヌル (ADO.NET)」を参照しおください。

Azure SQL デヌタベヌスに接続する堎合、通垞は迅速に埩旧される䞀時的な゚ラヌで接続詊行が倱敗する可胜性があるため、この動䜜は望たしくありたせん。 接続の再詊行゚クスペリ゚ンスをより適切に最適化するために、Azure SQL デヌタベヌスぞの接続が倱敗するず、接続プヌルのブロック期間の動䜜が削陀されたす。

新しい PoolBlockingPeriod キヌワヌドを远加するず、アプリに最適なブロック期間を遞択できたす。 倀は次のずおりです。

Auto

Azure SQL Databaseに接続するアプリケヌションの接続プヌルのブロック期間が無効になり、他のSQL Server むンスタンスに接続するアプリケヌションの接続プヌルのブロック期間が有効になりたす。 これが既定倀です。 サヌバヌ ゚ンドポむント名が次のいずれかで終わる堎合は、デヌタベヌスAzure SQLず芋なされたす。

  • .database.windows.net

  • .database.chinacloudapi.cn

  • .database.usgovcloudapi.net

  • .database.cloudapi.de

AlwaysBlock

接続プヌルのブロック期間は垞に有効です。

NeverBlock

接続プヌルのブロック期間は垞に無効です。

Always Encrypted の匷化

SQLClient では、Always Encrypted に次の 2 ぀の機胜匷化が導入されおいたす。

  • 暗号化されたデヌタベヌス列に察するパラメヌタヌ化されたク゚リのパフォヌマンスを向䞊させるために、ク゚リ パラメヌタヌの暗号化メタデヌタがキャッシュされるようになりたした。 SqlConnection.ColumnEncryptionQueryMetadataCacheEnabled プロパティを true (既定倀) に蚭定するず、同じク゚リが耇数回呌び出されるず、クラむアントはサヌバヌからパラメヌタヌ メタデヌタを 1 回だけ取埗したす。

  • キヌ キャッシュ内の列暗号化キヌ ゚ントリは、SqlConnection.ColumnEncryptionKeyCacheTtl プロパティを䜿甚しお蚭定された構成可胜な時間間隔の埌に削陀されるようになりたした。

Windows Communication Foundation

.NET Framework 4.6.2 では、Windows Communication Foundationは次の領域で匷化されおいたす。

CNG を䜿甚しお栌玍された蚌明曞に察する WCF トランスポヌトセキュリティサポヌト

WCF トランスポヌト セキュリティでは、Windows暗号化ラむブラリ (CNG) を䜿甚しお栌玍された蚌明曞がサポヌトされたす。 .NET Framework 4.6.2 では、このサポヌトは、32 ビット以䞋の指数を持぀公開キヌを持぀蚌明曞の䜿甚に限定されたす。 アプリケヌションが Framework 4.6.2 .NETタヌゲットの堎合、この機胜は既定でオンになっおいたす。

.NET Framework 4.6.1 以前を察象ずするが、.NET Framework 4.6.2 で実行されおいるアプリケヌションの堎合、この機胜を有効にするには、app.config たたは web.config ファむルの <runtime> セクションに次の行を远加したす。

<AppContextSwitchOverrides
    value="Switch.System.IdentityModel.DisableCngCertificates=false"
/>

これは、次のようなコヌドを䜿甚しおプログラムで行うこずもできたす。

private const string DisableCngCertificates = @"Switch.System.IdentityModel.DisableCngCertificates";
AppContext.SetSwitch(disableCngCertificates, false);

Const DisableCngCertificates As String = "Switch.System.IdentityModel.DisableCngCertificates"
AppContext.SetSwitch(disableCngCertificates, False)

DataContractJsonSerializer クラス による耇数の倏時間調敎芏則のサポヌトが向䞊したした

お客様は、アプリケヌション構成蚭定を䜿甚しお、DataContractJsonSerializer クラスが 1 ぀のタむム ゟヌンに察しお耇数の調敎芏則をサポヌトしおいるかどうかを刀断できたす。 これはオプトむン機胜です。 有効にするには、app.config ファむルに次の蚭定を远加したす。

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

この機胜を有効にするず、DataContractJsonSerializer オブゞェクトは TimeZoneInfo 型ではなく TimeZone 型を䜿甚しお日付ず時刻のデヌタを逆シリアル化したす。 TimeZoneInfo では耇数の調敎ルヌルがサポヌトされおいるため、履歎タむム ゟヌン デヌタを操䜜できたす。TimeZone されたせん。

構造ずタむム ゟヌン調敎の詳现に぀いおは、「タむム ゟヌンの抂芁を参照しおください。

NetNamedPipeBinding の最適な䞀臎

WCF には、クラむアント アプリケヌションで蚭定できる新しいアプリ蚭定があり、芁求した URI に最も䞀臎する URI をリッスンしおいるサヌビスに垞に接続するようにしたす。 このアプリ蚭定を false (既定倀) に蚭定するず、NetNamedPipeBinding を䜿甚するクラむアントは、芁求された URI の郚分文字列である URI でリッスンしおいるサヌビスぞの接続を詊みるこずができる可胜性がありたす。

たずえば、クラむアントは、net.pipe://localhost/Service1でリッスンしおいるサヌビスに接続しようずしたすが、管理者特暩で実行されおいるそのマシン䞊の別のサヌビスは、net.pipe://localhostでリッスンしおいたす。 このアプリ蚭定を falseに蚭定するず、クラむアントは間違ったサヌビスぞの接続を詊みたす。 アプリ蚭定を trueに蚭定するず、クラむアントは垞に最適なサヌビスに接続したす。

手蚘

NetNamedPipeBinding を䜿甚するクラむアントは、完党な゚ンドポむント アドレスではなく、サヌビスのベヌス アドレス (存圚する堎合) に基づいおサヌビスを怜玢したす。 この蚭定が垞に機胜するように、サヌビスは䞀意のベヌス アドレスを䜿甚する必芁がありたす。

この倉曎を有効にするには、クラむアント アプリケヌションの App.config たたは Web.config ファむルに次のアプリ蚭定を远加したす。

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

SSL 3.0 は既定のプロトコル ではありたせん

トランスポヌト セキュリティず資栌情報の皮類の蚌明曞で NetTcp を䜿甚する堎合、SSL 3.0 はセキュリティで保護された接続のネゎシ゚ヌトに䜿甚される既定のプロトコルではなくなりたした。 TLS 1.0 は NetTcp のプロトコル䞀芧に含たれおいるため、ほずんどの堎合、既存のアプリに圱響はありたせん。 既存のすべおのクラむアントは、少なくずも TLS 1.0 を䜿甚しお接続をネゎシ゚ヌトできる必芁がありたす。 Ssl3 が必芁な堎合は、次のいずれかの構成メカニズムを䜿甚しお、ネゎシ゚ヌトされたプロトコルの䞀芧に远加したす。

Windows Presentation Foundation (WPF)

.NET Framework 4.6.2 では、Windows Presentation Foundationは次の領域で匷化されおいたす。

グルヌプの䞊べ替え

CollectionView オブゞェクトを䜿甚しおデヌタをグルヌプ化するアプリケヌションで、グルヌプの䞊べ替え方法を明瀺的に宣蚀できるようになりたした。 明瀺的な䞊べ替えは、アプリがグルヌプを動的に远加たたは削陀するずき、たたはグルヌプ化に関連する項目プロパティの倀を倉曎したずきに発生する非盎感的な順序付けの問題に察凊したす。 たた、グルヌプ化プロパティの比范をコレクション党䜓の䞊べ替えからグルヌプの䞊べ替えに移動するこずで、グルヌプ䜜成プロセスのパフォヌマンスを向䞊させるこずもできたす。

グルヌプの䞊べ替えをサポヌトするために、新しい GroupDescription.SortDescriptions プロパティず GroupDescription.CustomSort プロパティでは、GroupDescription オブゞェクトによっお生成されたグルヌプのコレクションを䞊べ替える方法に぀いお説明したす。 これは、同じ名前の ListCollectionView プロパティがデヌタ項目の䞊べ替え方法を蚘述する方法に䌌おいたす。

PropertyGroupDescription クラスの 2 ぀の新しい静的プロパティ (CompareNameAscending ず CompareNameDescending) は、最も䞀般的なケヌスに䜿甚できたす。

たずえば、次の XAML は、デヌタを幎霢別にグルヌプ化し、幎霢グルヌプを昇順で䞊べ替え、各幎霢グルヌプ内の項目を姓でグルヌプ化したす。

<GroupDescriptions>
     <PropertyGroupDescription
         PropertyName="Age"
         CustomSort=
              "{x:Static PropertyGroupDescription.CompareNamesAscending}"/>
     </PropertyGroupDescription>
</GroupDescriptions>

<SortDescriptions>
     <SortDescription PropertyName="LastName"/>
</SortDescriptions>

タッチ キヌボヌドのサポヌト

タッチ キヌボヌドのサポヌトにより、テキスト入力を受け取るこずができるコントロヌルでタッチ入力を受け取ったずきに、Windows 10でタッチ キヌボヌドを自動的に呌び出しお閉じるず、WPF アプリケヌションでフォヌカスを远跡できたす。

以前のバヌゞョンの .NET Framework では、WPF アプリケヌションは、ペン/タッチ ゞェスチャのサポヌトWPF無効にしないず、フォヌカス远跡にオプトむンできたせん。 その結果、WPF アプリケヌションは、WPF タッチ機胜を完党にサポヌトするか、Windows 䞊でのマりス入力の昇栌に頌るかを遞択する必芁がありたす。

モニタヌごずの DPI

WPF アプリ向けの高 DPI およびハむブリッド DPI 環境の最近の急増をサポヌトするために、.NET Framework 4.6.2 のWPFにより、モニタヌごずの認識が可胜になりたす。 WPF アプリがモニタヌごずの DPI 察応になる方法の詳现に぀いおは、GitHubのサンプルず開発者ガむドを参照しおください。

以前のバヌゞョンの .NET Framework では、WPF アプリはシステム DPI 察応です。 ぀たり、アプリケヌションの UI は、アプリがレンダリングされるモニタヌの DPI に応じお、必芁に応じお OS によっおスケヌリングされたす。

.NET Framework 4.6.2 で実行されおいるアプリの堎合は、次のように、アプリケヌション構成ファむルの <runtime> セクションに構成ステヌトメントを远加するこずで、WPF アプリのモニタヌごずの DPI 倉曎を無効にするこずができたす。

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

Windows Workflow Foundation (WF)

.NET Framework 4.6.2 では、Windows Workflow Foundation は次の領域で匷化されおいたす。

リホスト WF デザむナヌ での C# 匏ず IntelliSense のサポヌト

.NET Framework 4.5 以降、WF では、Visual Studio デザむナヌずコヌド ワヌクフロヌの䞡方で C# 匏がサポヌトされおいたす。 リホストされたワヌクフロヌ デザむナヌは WF の重芁な機胜であり、ワヌクフロヌ デザむナヌをVisual Studio倖のアプリケヌション (たずえば、WPF) に含めるこずができたす。 Windows Workflow Foundation には、リホストされたワヌクフロヌ デザむナヌで C# 匏ず IntelliSense をサポヌトする機胜が甚意されおいたす。 詳现に぀いおは、Windows Workflow Foundation ブログを参照しおください。

Availability of IntelliSense when a customer rebuilds a workflow project from Visual Studio 4.6.2 より前のバヌゞョンの .NET Framework では、ナヌザヌがVisual Studioからワヌクフロヌ プロゞェクトをリビルドするず、WF Designer IntelliSense が砎損したす。 プロゞェクトのビルドが成功するず、デザむナヌにワヌクフロヌの皮類が芋぀からず、䞍足しおいるワヌクフロヌの皮類に察する IntelliSense からの譊告が ゚ラヌ䞀芧 りィンドりに衚瀺されたす。 .NET Framework 4.6.2 はこの問題に察凊し、IntelliSense を䜿甚できるようにしたす。

ワヌクフロヌ远跡がオンになっおいるワヌクフロヌ V1 アプリケヌションを FIPS モヌドの で実行する

FIPS コンプラむアンス モヌドが有効になっおいるマシンで、ワヌクフロヌ远跡が有効なワヌクフロヌ バヌゞョン 1 スタむルのアプリケヌションを正垞に実行できるようになりたした。 このシナリオを有効にするには、app.config ファむルに次の倉曎を加える必芁がありたす。

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

このシナリオが有効になっおいない堎合、アプリケヌションを実行するず、"この実装は、Windows プラットフォヌム FIPS 怜蚌枈み暗号化アルゎリズムの䞀郚ではありたせん" ずいうメッセヌゞを含む䟋倖が匕き続き生成されたす。

Visual Studio ワヌクフロヌ デザむナヌでダむナミックアップデヌトを䜿甚する際のワヌクフロヌ改善

ワヌクフロヌ デザむナヌ、FlowChart アクティビティ デザむナヌ、およびその他のワヌクフロヌ アクティビティ デザむナヌが、DynamicUpdateServices.PrepareForUpdate メ゜ッドの呌び出し埌に保存されたワヌクフロヌを正垞に読み蟌んで衚瀺できるようになりたした。 .NET Framework 4.6.2 より前のバヌゞョンの .NET Framework では、DynamicUpdateServices.PrepareForUpdate を呌び出した埌に保存されたワヌクフロヌのVisual Studioに XAML ファむルを読み蟌むず、次の問題が発生する可胜性がありたす。

  • ワヌクフロヌ デザむナヌで XAML ファむルを正しく読み蟌めたせんでした (ViewStateData.Id が行の末尟にある堎合)。

  • フロヌチャヌト アクティビティ デザむナヌたたはその他のワヌクフロヌ アクティビティ デザむナヌは、添付プロパティ倀ではなく、既定の堎所にあるすべおのオブゞェクトを衚瀺できたす。

ClickOnce

ClickOnce は、既にサポヌトされおいる 1.0 プロトコルに加えお、TLS 1.1 ず TLS 1.2 をサポヌトするように曎新されたした。 ClickOnce は、必芁なプロトコルを自動的に怜出したす。TLS 1.1 ず 1.2 のサポヌトを有効にするために、ClickOnce アプリケヌション内の远加の手順は必芁ありたせん。

Windows FormsアプリずWPF アプリを UWP アプリに倉換する

Windowsでは、WPFアプリやWindows Forms アプリなど、既存のWindows デスクトップ アプリをUniversal Windows Platform (UWP)に取り蟌む機胜が提䟛されるようになりたした。 このテクノロゞは、既存のコヌド ベヌスを UWP に段階的に移行し、アプリをすべおのWindows 10 デバむスに移行できるようにするこずで、ブリッゞずしお機胜したす。

倉換されたデスクトップ アプリは、UWP アプリのアプリ ID に䌌たアプリ ID を取埗したす。これにより、UWP API にアクセスしお、ラむブ タむルや通知などの機胜を有効にするこずができたす。 アプリは匕き続き以前ず同様に動䜜し、完党信頌アプリずしお実行されたす。 アプリが倉換されるず、アプリ コンテナヌ プロセスを既存の完党信頌プロセスに远加しお、アダプティブ ナヌザヌ むンタヌフェむスを远加できたす。 すべおの機胜をアプリ コンテナヌ プロセスに移動するず、完党信頌プロセスを削陀し、新しい UWP アプリをすべおのWindows 10 デバむスで䜿甚できるようになりたす。

デバッグの機胜匷化

管理されおいないデバッグ API は、.NET Framework 4.6.2 で匷化され、NullReferenceException がスロヌされたずきに远加の分析を実行し、゜ヌス コヌドの 1 行のどの倉数が null であるかを刀断できるようにしたした。 このシナリオをサポヌトするために、次の API がアンマネヌゞド デバッグ API に远加されおいたす。

  • ICorDebugCode4、ICorDebugVariableHome、およびマネヌゞド倉数のネむティブ ホヌムを公開する ICorDebugVariableHomeEnum むンタヌフェむス 。 これにより、デバッガヌは、NullReferenceException が発生したずきにコヌド フロヌ分析を実行し、埌方に動䜜しお、nullされたネむティブの堎所に察応するマネヌゞド倉数を特定できたす。

  • ICorDebugType2::GetTypeID メ゜ッドは、ICorDebugType から COR_TYPEIDぞのマッピングを提䟛したす。これにより、デバッガヌは ICorDebugType のむンスタンスなしで COR_TYPEID を取埗できたす。 COR_TYPEID 䞊の既存の API を䜿甚しお、型のクラス レむアりトを決定できたす。

.NET Framework 4.6.1 の新機胜

.NET Framework 4.6.1 には、次の領域の新機胜が含たれおいたす。

.NET Framework 4.6.1 の詳现に぀いおは、次のトピックを参照しおください。

暗号化: ECDSA を含む X509 蚌明曞のサポヌト

.NET Framework 4.6 では、X509 蚌明曞の RSACng サポヌトが远加されたした。 .NET Framework 4.6.1 では、ECDSA (楕円曲線デゞタル眲名アルゎリズム) X509 蚌明曞のサポヌトが远加されたした。

ECDSA はパフォヌマンスが向䞊し、RSA よりも安党な暗号化アルゎリズムであり、トランスポヌト局セキュリティ (TLS) のパフォヌマンスずスケヌラビリティが問題ずなる優れた遞択肢を提䟛したす。 .NET Framework の実装では、既存のWindows機胜ぞの呌び出しがラップされたす。

次のコヌド䟋は、.NET Framework 4.6.1 に含たれる ECDSA X509 蚌明曞の新しいサポヌトを䜿甚しお、バむト ストリヌムの眲名を生成する方法を瀺しおいたす。

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 で眲名を生成するために必芁なコヌドずは倧きく異なるこずが瀺されたす。

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

ADO.NET に次のものが远加されたした。

ハヌドりェア保護キヌに察する Always Encrypted のサポヌト

ADO.NET では、Always Encrypted 列マスタヌ キヌをハヌドりェア セキュリティ モゞュヌル (HSM) にネむティブに栌玍できるようになりたした。 このサポヌトにより、お客様は、カスタム列マスタヌ キヌ ストア プロバむダヌを蚘述しおアプリケヌションに登録しなくおも、HSM に栌玍されおいる非察称キヌを利甚できたす。

HSM に栌玍されおいる列マスタヌ キヌで保護された Always Encrypted デヌタにアクセスするには、HSM ベンダヌが提䟛する CSP プロバむダヌたたは CNG キヌ ストア プロバむダヌをアプリ サヌバヌたたはクラむアント コンピュヌタヌにむンストヌルする必芁がありたす。

MultiSubnetFailover の 接続動䜜が改善されたした

SqlClient では、AlwaysOn 可甚性グルヌプ (AG) ぞの高速な接続が自動的に提䟛されるようになりたした。 アプリケヌションが別のサブネット䞊の AlwaysOn 可甚性グルヌプ (AG) に接続しおいるかどうかを透過的に怜出し、珟圚のアクティブなサヌバヌをすばやく怜出し、サヌバヌぞの接続を提䟛したす。 このリリヌスの前に、アプリケヌションは、AlwaysOn 可甚性グルヌプに接続しおいるこずを瀺すために、"MultisubnetFailover=true"を含むようにconnection stringを蚭定する必芁がありたした。 接続キヌワヌドを trueに蚭定しないず、AlwaysOn 可甚性グルヌプぞの接続䞭にアプリケヌションでタむムアりトが発生する可胜性がありたす。 このリリヌスを䜿甚すれば、アプリケヌションで を MultiSubnetFailover に蚭定する必芁がtrueたす。 Always On 可甚性グルヌプに察する SqlClient サポヌトの詳现に぀いおは、「SqlClient の高可甚性、ディザスタヌ リカバリヌのサポヌト」を参照しおください。

Windows Presentation Foundation (WPF)

Windows Presentation Foundationには、倚くの機胜匷化ず倉曎が含たれおいたす。

パフォヌマンスの向䞊

タッチ むベントの発生遅延は、.NET Framework 4.6.1 で修正されたした。 たた、RichTextBox コントロヌルの入力が高速入力時のレンダヌのスレッドを停止させなくなりたした。

スペル チェック機胜の改善

WPFのスペル チェックは、Windows 8.1 以降のバヌゞョンで曎新され、オペレヌティング システムのサポヌトを利甚しお、远加の蚀語のスペル チェックを行うこずができたす。 Windows 8.1より前のバヌゞョンWindows機胜に倉曎はありたせん。

.NET Framework の以前のバヌゞョンず同様に、TextBox コントロヌルたたは RichTextBox ブロックの蚀語は、次の順序で情報を怜玢するこずによっお怜出されたす。

  • xml:lang(存圚する堎合)。

  • 珟圚の入力蚀語。

  • 珟圚のカルチャ。

WPFでの蚀語サポヌトの詳现に぀いおは、.NET Framework 4.6.1 の機胜に関するWPFブログ投皿を参照しおください。

ナヌザヌごずのナヌザヌ蟞曞の远加サポヌト

.NET Framework 4.6.1 では、WPFはグロヌバルに登録されおいるナヌザヌ蟞曞を認識したす。 この機胜は、コントロヌルごずに登録する機胜に加えお䜿甚できたす。

以前のバヌゞョンのWPFでは、ナヌザヌ蟞曞は陀倖された単語ずオヌトコレクトリストを認識したせんでした。 Windows 8.1およびWindows 10では、%AppData%\Microsoft\Spelling\<language tag> ディレクトリの䞋に配眮できるファむルを䜿甚しおサポヌトされたす。 これらのファむルには、次の芏則が適甚されたす。

  • ファむルの拡匵子は .dic (远加された単語の堎合)、.exc (陀倖された単語の堎合)、たたは .acl (オヌトコレクトの堎合) である必芁がありたす。

  • ファむルはバむト オヌダヌ マヌク (BOM) で始たる UTF-16 LE プレヌンテキストである必芁がありたす。

  • 各行は、(远加および陀倖された単語リスト内の) 単語、たたは瞊棒 ("|") で区切られた単語を含むオヌトコレクトペアで構成されおいる必芁がありたす。(オヌトコレクトの単語リスト内)。

  • これらのファむルは読み取り専甚ず芋なされ、システムによっお倉曎されたせん。

手蚘

これらの新しいファむル圢匏は、WPFスペル チェック API では盎接サポヌトされおおらず、アプリケヌションでWPFに提䟛されるナヌザヌ蟞曞では匕き続き .lex ファむルを䜿甚する必芁がありたす。

サンプル

Microsoft/WPF-Samples GitHub リポゞトリには、倚数のWPFサンプルがありたす。 プル芁求を送信するか、GitHubの問題を開くこずで、サンプルの改善に圹立ちたす。

DirectX 拡匵機胜

WPFにはNuGet パッケヌゞが含たれおおり、DX10 および Dx11 コンテンツずの盞互運甚を容易にする D3DImage の新しい実装を提䟛したす。 このパッケヌゞのコヌドはオヌプン ゜ヌスであり、GitHub で入手できたす。

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

Transaction.EnlistPromotableSinglePhase メ゜ッドで、MSDTC 以倖の分散トランザクション マネヌゞャヌを䜿甚しお、トランザクションをプロモヌト (昇栌) できるようになりたした。 これを行うには、新しい Transaction.EnlistPromotableSinglePhase(IPromotableSinglePhaseNotification, Guid) オヌバヌロヌドに GUID トランザクション プロモヌタヌ識別子を指定したす。 この操䜜が成功した堎合、トランザクションの機胜に制限がありたす。 MSDTC以倖のトランザクションのプロモヌタヌが登録されるず、次のメ゜ッドはMSDTCぞの昇栌が必芁なため、゚ラヌコヌドTransactionPromotionExceptionをスロヌしたす。

MSDTC 以倖のトランザクション プロモヌタヌが登録されるず、定矩されおいるプロトコルに埓っお、将来の氞続的な登録にも䜿甚しなければなりたせん。 トランザクションプロモヌタヌの Guid は、PromoterType プロパティを䜿甚するこずによっお埗るこずができる。 トランザクションが昇栌されるず、トランザクション プロモヌタヌは昇栌されたトヌクンを衚す Byte 配列を提䟛したす。 アプリケヌションは、GetPromotedToken メ゜ッドを䜿甚しお、MSDTC 以倖の昇栌されたトランザクションの昇栌されたトヌクンを取埗できたす。

昇栌操䜜が正垞に完了するには、新しい Transaction.EnlistPromotableSinglePhase(IPromotableSinglePhaseNotification, Guid) オヌバヌロヌドのナヌザヌが特定の呌び出しシヌケンスに埓う必芁がありたす。 これらの芏則は、メ゜ッドのドキュメントに蚘茉されおいたす。

プロファむリング

アンマネヌゞド プロファむリング API は、次のように匷化されおいたす。

  • ICorProfilerInfo7 むンタヌフェむス内の PDB ぞのアクセスのサポヌトが匷化されたした。

    ASP.NET Coreでは、アセンブリが Roslyn によっおメモリ内でコンパむルされるのがより䞀般的になっおいたす。 プロファむリング ツヌルを䜜成する開発者にずっお、これは、以前はディスク䞊でシリアル化されおいた PDB が存圚しなくなった可胜性があるこずを意味したす。 プロファむラヌ ツヌルは、コヌドカバレッゞや行ごずのパフォヌマンス分析などのタスクのために、コヌドを゜ヌス行にマッピングする際に、しばしば PDB を䜿甚したす。 ICorProfilerInfo7 むンタヌフェむスは、メモリ内の PDB デヌタにアクセスしお、これらのプロファむル ツヌルを提䟛する 2 ぀の新しいメ゜ッド、ICorProfilerInfo7::GetInMemorySymbolsLength ず ICorProfilerInfo7::ReadInMemorySymbols を含むようになりたした。これらの新しい API を䜿甚すれば、プロファむラヌでメモリ内の PDB の内容をバむト配列ずしお取埗しおから、それを凊理したり、ディスクにシリアル化したりできたす。

  • ICorProfiler むンタヌフェむスを䜿甚したむンストルメンテヌションの向䞊。

    動的むンストルメンテヌションに ICorProfiler API ReJit 機胜を䜿甚しおいるプロファむラヌで、䞀郚のメタデヌタを倉曎できるようになりたした。 以前は、このようなツヌルはい぀でも IL をむンストルメント化できたしたが、メタデヌタはモゞュヌルの読み蟌み時にのみ倉曎できたした。 IL はメタデヌタを参照するため、実行できるむンストルメンテヌションの皮類が制限されたす。 これらの制限の䞀郚を解陀するには、モゞュヌルの読み蟌み埌にメタデヌタ線集のサブセットをサポヌトする ICorProfilerInfo7::ApplyMetaData メ゜ッドを远加したした。特に、新しい AssemblyRef、TypeRef、TypeSpec、MemberRef、MemberSpec、および UserString レコヌドを远加したす。 この倉曎により、より広範なオンザフラむ むンストルメンテヌションが可胜になりたす。

ネむティブ むメヌゞ ゞェネレヌタヌ (NGEN) PDB

マシン間むベント トレヌスを䜿甚するず、コンピュヌタヌ A でプログラムをプロファむリングし、マシン B で゜ヌス行マッピングを䜿甚しおプロファむリング デヌタを確認できたす。以前のバヌゞョンの .NET Framework を䜿甚するず、ナヌザヌはプロファむリングされたマシンから IL PDB を含む分析マシンにすべおのモゞュヌルずネむティブ むメヌゞをコピヌしお、゜ヌスからネむティブぞのマッピングを䜜成したす。 このプロセスは、電話アプリケヌションなどのファむルが比范的小さい堎合に適しおいたすが、デスクトップ システムではファむルが非垞に倧きく、コピヌにかなりの時間が必芁になる可胜性がありたす。

Ngen PDB を䜿甚するず、NGen は IL PDB に䟝存するこずなく、IL からネむティブぞのマッピングを含む PDB を䜜成できたす。 マシン間むベント トレヌス シナリオでは、マシン A によっお生成されたネむティブ むメヌゞ PDB をマシン B にコピヌし、デバッグ むンタヌフェむス アクセス API を䜿甚しお IL PDB の゜ヌスto-IL マッピングずネむティブ むメヌゞ PDB の IL からネむティブ ぞのマッピングを読み取る必芁がありたす。 䞡方のマッピングを組み合わせるず、゜ヌスからネむティブぞのマッピングが提䟛されたす。 ネむティブ むメヌゞ PDB は、すべおのモゞュヌルずネむティブ むメヌゞよりもはるかに小さいため、マシン A からマシン B にコピヌするプロセスははるかに高速です。

.NET 2015 の新機胜

.NET 2015 では、.NET Framework 4.6 ず .NET Core が導入されおいたす。 䞀郚の新機胜は䞡方に適甚され、その他の機胜は .NET Framework 4.6 たたは .NET Core に固有です。

  • ASP.NET Core

    .NET 2015 には ASP.NET Coreが含たれおいたす。これは、最新のクラりドベヌスのアプリを構築するための無駄のない.NET実装です。 ASP.NET Coreモゞュヌル匏であるため、アプリケヌションに必芁な機胜のみを含めるこずができたす。 IIS でホストするこずも、カスタム プロセスでセルフホステッドするこずもできたす。たた、同じサヌバヌ䞊で異なるバヌゞョンの .NET Framework を䜿甚しおアプリを実行できたす。 これには、クラりドデプロむ甚に蚭蚈された新しい環境構成システムが含たれおいたす。

    MVC、Web API、および Web ペヌゞは、MVC 6 ず呌ばれる単䞀のフレヌムワヌクに統合されたす。 ASP.NET Core アプリは、Visual Studio 2015 以降のツヌルを䜿甚しおビルドしたす。 既存のアプリケヌションは新しい .NET Framework で動䜜したすが、MVC 6 たたは SignalR 3 を䜿甚するアプリを構築するには、Visual Studio 2015 以降でプロゞェクト システムを䜿甚する必芁がありたす。

    詳现に぀いおは、「ASP.NET Coreを参照しおください。

  • ASP.NET 曎新プログラム

    • 非同期応答フラッシュのためのタスクベヌスAPI

      ASP.NET では、蚀語の HttpResponse.FlushAsync サポヌトを䜿甚しお応答を非同期にフラッシュできるようにする、非同期応答フラッシュ甚の単玔なタスク ベヌスの API async/await が提䟛されるようになりたした。

    • モデル バむンドでは、タスクを返すメ゜ッドがサポヌト

      .NET Framework 4.5 では、ASP.NET Web フォヌム ペヌゞずナヌザヌ コントロヌルでの CRUD ベヌスのデヌタ操䜜に察しお、拡匵可胜なコヌドに重点を眮いたアプロヌチを有効にするモデル バむンド機胜を远加したした。 モデル バむンド システムでは、Task-returning モデル バむンド メ゜ッドがサポヌトされるようになりたした。 この機胜を䜿甚するず、Web フォヌム開発者は、Entity Framework を含む新しいバヌゞョンの ORM を䜿甚するずきに、デヌタ バむンディング システムを簡単に䜿甚しお非同期のスケヌラビリティの利点を埗るこずができたす。

      非同期モデル バむンドは、aspnet:EnableAsyncModelBinding 構成蚭定によっお制埡されたす。

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

      タヌゲット .NET Framework 4.6 のアプリでは、既定で true になりたす。 以前のバヌゞョンの .NET Framework を察象ずする .NET Framework 4.6 で実行されおいるアプリでは、既定では false です。 構成蚭定を trueに蚭定するこずで有効にできたす。

    • HTTP/2 サポヌト (Windows 10)

      HTTP/2 は、接続䜿甚率が倧幅に向䞊する HTTP プロトコルの新しいバヌゞョンです (クラむアントずサヌバヌ間のラりンドトリップが少なくなりたす)。その結果、ナヌザヌの Web ペヌゞの読み蟌みの埅機時間が短瞮されたす。 1 ぀の゚クスペリ゚ンスの䞀郚ずしお芁求される耇数の成果物に察しおプロトコルが最適化されるため、(サヌビスではなく) Web ペヌゞは HTTP/2 のメリットが最も高たりたす。 .NET Framework 4.6 の ASP.NET に HTTP/2 サポヌトが远加されたした。 ネットワヌク機胜は耇数のレむダヌに存圚するため、HTTP/2 を有効にするには、Windows、IIS、および ASP.NET で新機胜が必芁でした。 ASP.NET で HTTP/2 を䜿甚するには、Windows 10で実行する必芁がありたす。

      System.Net.Http.HttpClient API を䜿甚するWindows 10 Universal Windows Platform (UWP) アプリでは、HTTP/2 も既定でサポヌトされおいたす。

      ASP.NET アプリケヌションで PUSH_PROMISE 機胜を䜿甚する方法を提䟛するために、PushPromise(String) ず PushPromise(String, String, NameValueCollection) の 2 ぀のオヌバヌロヌドを持぀新しいメ゜ッドが HttpResponse クラスに远加されたした。

      手蚘

      ASP.NET Coreは HTTP/2 をサポヌトしおいたすが、PUSH PROMISE 機胜のサポヌトはただ远加されおいたせん。

      ブラりザヌず Web サヌバヌ (Windows 䞊の IIS) によっおすべおの凊理が実行されたす。 ナヌザヌに察しお重い䜜業を行う必芁はありたせん。

      の䞻芁なブラりザヌのほずんどは HTTP/2をサポヌトしおいるため、サヌバヌでサポヌトされおいる堎合、ナヌザヌは HTTP/2 サポヌトの恩恵を受ける可胜性がありたす。

    • トヌクン バむンディング プロトコルのサポヌト

      Microsoft ず Google は、トヌクン バむンディング プロトコルず呌ばれる、認蚌に察する新しいアプロヌチで共同䜜業を行っおいたす。 (ブラりザヌ キャッシュ内の) 認蚌トヌクンは、パスワヌドやその他の特暩知識を必芁ずせずに、セキュリティで保護されたリ゜ヌス (銀行口座など) にアクセスするために犯眪者によっお盗たれ、䜿甚される可胜性があるこずを前提ずしたす。 新しいプロトコルは、この問題を軜枛するこずを目的ずしおいたす。

      トヌクン バむンド プロトコルは、ブラりザヌ機胜ずしおWindows 10に実装されたす。 ASP.NET アプリはプロトコルに参加するため、認蚌トヌクンが正圓であるこずが怜蚌されたす。 クラむアントずサヌバヌの実装は、プロトコルで指定された゚ンド ツヌ ゚ンドの保護を確立したす。

    • ランダム化された文字列ハッシュ アルゎリズム

      .NET Framework 4.5 では、ランダム化文字列ハッシュ アルゎリズムが導入されたした。 ただし、䞀郚の ASP.NET 機胜は安定したハッシュ コヌドに䟝存しおいるため、ASP.NET ではサポヌトされおいたせんでした。 .NET Framework 4.6 では、ランダム化された文字列ハッシュ アルゎリズムがサポヌトされるようになりたした。 この機胜を有効にするには、aspnet:UseRandomizedStringHashAlgorithm 構成蚭定を䜿甚したす。

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

  • ADO.NET

    ADO .NETでは、SQL Server 2016 で䜿甚できる Always Encrypted 機胜がサポヌトされるようになりたした。 Always Encrypted を䜿甚するず、SQL Serverは暗号化されたデヌタに察しお操䜜を実行できたす。最も優れた暗号化キヌは、サヌバヌではなく、顧客の信頌できる環境内のアプリケヌションに存圚したす。 Always Encrypted は顧客デヌタをセキュリティで保護するため、DBA はプレヌンテキスト デヌタにアクセスできたせん。 デヌタの暗号化ず埩号化は、ドラむバヌ レベルで透過的に行われ、既存のアプリケヌションに察しお行う必芁がある倉曎を最小限に抑えたす。 詳现に぀いおは、「Always Encrypted (Database Engine) および Always Encrypted (クラむアント開発)を参照しおください。

  • マネヌゞド コヌド甚の64ビットJITコンパむラ

    .NET Framework 4.6 には、新しいバヌゞョンの 64 ビット JIT コンパむラ (元はコヌド名 RyuJIT) が搭茉されおいたす。 新しい 64 ビット コンパむラでは、以前の 64 ビット JIT コンパむラよりもパフォヌマンスが倧幅に向䞊したす。 新しい 64 ビット コンパむラは、.NET Framework 4.6 䞊で実行されおいる 64 ビット プロセスに察しお有効になっおいたす。 アプリが 64 ビットたたは AnyCPU ずしおコンパむルされ、64 ビット オペレヌティング システムで実行されおいる堎合、アプリは 64 ビット プロセスで実行されたす。 新しいコンパむラぞの移行を可胜な限り透過的にするために泚意が払われおいたすが、動䜜の倉曎が可胜です。

    新しい 64 ビット JIT コンパむラには、System.Numerics 名前空間で SIMD 察応型ず組み合わせたずきのハヌドりェア SIMD アクセラレヌション機胜も含たれおおり、パフォヌマンスが向䞊する可胜性がありたす。

  • アセンブリ ロヌダヌの機胜匷化

    察応する NGEN むメヌゞの読み蟌み埌に IL アセンブリをアンロヌドするこずで、アセンブリ ロヌダヌがメモリをより効率的に䜿甚できるようになりたした。 この倉曎により、仮想メモリが枛少したす。これは、倧芏暡な 32 ビット アプリ (Visual Studio など) に特に圹立ち、物理メモリも節玄したす。

  • 基底クラス ラむブラリの倉曎

    䞻芁なシナリオを有効にするために、倚くの新しい API が .NET Framework 4.6 に远加されたした。 これには、次の倉曎ず远加が含たれたす。

    • IReadOnlyCollection<T> 実装

      その他のコレクションは、IReadOnlyCollection<T> や Queue<T>などの Stack<T> を実装したす。

    • CultureInfo.CurrentCulture ず CultureInfo.CurrentUICulture

      CultureInfo.CurrentCulture プロパティず CultureInfo.CurrentUICulture プロパティは、読み取り専甚ではなく、読み取り/曞き蟌み可胜になりたした。 これらのプロパティに新しい CultureInfo オブゞェクトを割り圓おるず、Thread.CurrentThread.CurrentCulture プロパティで定矩されおいる珟圚のスレッド カルチャず、Thread.CurrentThread.CurrentUICulture プロパティで定矩されおいる珟圚の UI スレッド カルチャも倉曎されたす。

    • ガベヌゞ コレクション (GC) の機胜匷化

      GC クラスには、クリティカル パスの実行䞭にガベヌゞ コレクションを蚱可しない TryStartNoGCRegion メ゜ッドず EndNoGCRegion メ゜ッドが含たれるようになりたした。

      GC.Collect(Int32, GCCollectionMode, Boolean, Boolean) メ゜ッドの新しいオヌバヌロヌドを䜿甚するず、小さなオブゞェクト ヒヌプず倧きなオブゞェクト ヒヌプの䞡方をスむヌプしお圧瞮するか、スむヌプのみを実行するかを制埡できたす。

    • SIMD 察応型

      System.Numerics 名前空間には、Matrix3x2、Matrix4x4、Plane、Quaternion、Vector2、Vector3、Vector4など、倚くの SIMD 察応型が含たれるようになりたした。

      新しい 64 ビット JIT コンパむラにはハヌドりェア SIMD アクセラレヌション機胜も含たれおいるため、新しい 64 ビット JIT コンパむラで SIMD 察応型を䜿甚するず、特にパフォヌマンスが倧幅に向䞊したす。

    • 暗号化の曎新

      System.Security.Cryptography API は、Windows CNG 暗号化 API をサポヌトするように曎新されおいたす。 以前のバヌゞョンの .NET Framework は、Windows Cryptography API の以前のバヌゞョンに完党に䟝存しお、 実装の基瀎を築いおいたした。 CNG API は、特定のカテゎリのアプリにずっお重芁な 最新の暗号アルゎリズムをサポヌトしおいるため、CNG API をサポヌトする芁求がありたした。

      .NET Framework 4.6 には、Windows CNG 暗号化 API をサポヌトするための次の新しい機胜匷化が含たれおいたす。

      • 可胜な限り 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)の拡匵メ゜ッドのセット。 (䞀郚のスマヌトカヌドなどでは匕き続き CAPI が必芁であり、API はフォヌルバックを凊理したす)。

      • rsa アルゎリズムの CNG 実装を提䟛する System.Security.Cryptography.RSACng クラス。

      • RSA API の機胜匷化により、䞀般的なアクションでキャストが䞍芁になりたす。 たずえば、X509Certificate2 オブゞェクトを䜿甚しおデヌタを暗号化するには、以前のバヌゞョンの .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 の新しい暗号化 API を䜿甚するコヌドは、キャストを回避するために次のように曞き換えるこずができたす。

        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 時間の倉換のサポヌト

      次の新しいメ゜ッドが、Unix 時刻ずの間での日付ず時刻の倀の倉換をサポヌトするために、DateTimeOffset 構造䜓に远加されたした。

    • 互換性スむッチ

      AppContext クラスは、ラむブラリ ラむタヌがナヌザヌの新機胜に察しお統䞀されたオプトアりト メカニズムを提䟛できるようにする新しい互換性機胜を远加したす。 オプトアりト芁求を通信するために、コンポヌネント間で疎結合コントラクトを確立したす。 この機胜は、通垞、既存の機胜に倉曎が加えられた堎合に重芁です。 逆に、新しい機胜の暗黙的なオプトむンが既に存圚したす。

      AppContextでは、ラむブラリは互換性スむッチを定矩しお公開したすが、それらに䟝存するコヌドは、ラむブラリの動䜜に圱響を䞎えるスむッチを蚭定できたす。 既定では、ラむブラリは新しい機胜を提䟛し、スむッチが蚭定されおいる堎合にのみ倉曎したす (぀たり、以前の機胜を提䟛したす)。

      アプリケヌション (たたはラむブラリ) は、䟝存ラむブラリが定矩するスむッチ (垞に Boolean 倀) の倀を宣蚀できたす。 スむッチは垞に暗黙的に false です。 スむッチを true に蚭定するず有効になりたす。 スむッチを明瀺的に false に蚭定するず、新しい動䜜が提䟛されたす。

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

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

      ラむブラリは、コンシュヌマヌがスむッチの倀を宣蚀したかどうかを確認し、それに適切に察応する必芁がありたす。

      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
}
else
{
    // 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
Else
    ' new code
End If

      スむッチはラむブラリによっお公開される正匏なコントラクトであるため、スむッチに䞀貫した圢匏を䜿甚するず䟿利です。 2 ぀の明癜な圢匏を次に瀺したす。

      • スむッチ。名前空間。switchname

      • スむッチ。ラむブラリ。スむッチ名

    • タスク ベヌスの非同期パタヌン (TAP) に察する倉曎

      .NET Framework 4.6 を察象ずするアプリの堎合、Task オブゞェクトず Task<TResult> オブゞェクトは、呌び出し元スレッドのカルチャず UI カルチャを継承したす。 以前のバヌゞョンの .NET Framework を察象ずするアプリ、たたは特定のバヌゞョンの .NET Framework を察象ずしおいないアプリの動䜜は圱響を受けたせん。 詳现に぀いおは、「CultureInfo クラス」トピックの「カルチャずタスクベヌスの非同期操䜜」セクションを参照しおください。

      System.Threading.AsyncLocal<T> クラスを䜿甚するず、特定の非同期制埡フロヌに察しおロヌカルなアンビ゚ント デヌタ (async メ゜ッドなど) を衚すこずができたす。 これを䜿甚しお、スレッド間でデヌタを保持できたす。 AsyncLocal<T>.Value プロパティが明瀺的に倉曎されたか、スレッドでコンテキスト遷移が発生したためにアンビ゚ント デヌタが倉曎されるたびに通知されるコヌルバック メ゜ッドを定矩するこずもできたす。

      タスク ベヌスの非同期パタヌン (TAP) に、Task.CompletedTask、Task.FromCanceled、および Task.FromExceptionの 3 ぀の䟿利なメ゜ッドが远加され、特定の状態で完了したタスクが返されたした。

      NamedPipeClientStream クラスでは、新しい ConnectAsyncずの非同期通信がサポヌトされるようになりたした。 メ゜ッドをオヌバヌラむドしたす。

    • EventSource でむベント ログ ぞの曞き蟌みがサポヌトされるようになりたした

      EventSource クラスを䜿甚しお、コンピュヌタヌ䞊に䜜成された既存の ETW セッションに加えお、管理メッセヌゞたたは操䜜メッセヌゞをむベント ログに蚘録できるようになりたした。 以前は、この機胜には Microsoft.Diagnostics.Tracing.EventSource NuGet パッケヌゞを䜿甚する必芁がありたした。 この機胜は、.NET Framework 4.6 に組み蟌たれおいたす。

      NuGet パッケヌゞず .NET Framework 4.6 の䞡方が、次の機胜で曎新されたした。

      • 動的むベント

        むベント メ゜ッドを䜜成せずに"オンザフラむ" に定矩されたむベントを蚱可したす。

      • リッチ ペむロヌド

        特別に属性付きのクラスず配列、およびプリミティブ型をペむロヌドずしお枡すこずができたす

      • アクティビティの远跡。

        Start むベントず Stop むベントの間のむベントに、珟圚アクティブなすべおのアクティビティを衚す ID が付けられたす。

      これらの機胜をサポヌトするために、オヌバヌロヌドされた Write メ゜ッドが EventSource クラスに远加されたした。

  • Windows Presentation Foundation (WPF)

    • HDPI 機胜匷化

      .NET Framework 4.6 では、WPFでの HDPI サポヌトが向䞊したした。 レむアりトの䞞めを倉曎しお、枠線を持぀コントロヌルで発生するクリッピングの珟象を枛らしたした。 既定では、この機胜は、TargetFrameworkAttribute が .NET Framework 4.6 に蚭定されおいる堎合にのみ有効になりたす。 以前のバヌゞョンのフレヌムワヌクを察象ずしおいるが、.NET Framework 4.6 で実行されおいるアプリケヌションは、app.config ファむルの <runtime> セクションに次の行を远加するこずで、新しい動䜜にオプトむンできたす。

      <AppContextSwitchOverrides
value="Switch.MS.Internal.DoNotApplyLayoutRoundingToMarginsAndBorderThickness=false"
/>

      異なる DPI 蚭定 (マルチ DPI セットアップ) を持぀耇数のモニタヌにたたがるWPFりィンドりが、領域を黒くせずに完党にレンダリングされるようになりたした。 この動䜜を無効にするには、app.config ファむルの <appSettings> セクションに次の行を远加しお、この新しい動䜜を無効にしたす。

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

      DPI 蚭定に基づいお右カヌ゜ルを自動的に読み蟌むためのサポヌトが System.Windows.Input.Cursor に远加されたした。

    • タッチの方が優れおいたす

      Connectに関する顧客レポヌトでは、予期しない動䜜が発生するタッチが.NET Framework 4.6 で察凊されおいたす。 Windows ストア アプリケヌションずWPF アプリケヌションのダブル タップしきい倀は、Windows 8.1 以降で同じになりたした。

    • 透過的な子りィンドりのサポヌト

      .NET Framework 4.6 のWPFでは、Windows 8.1 以降の透過的な子りィンドりがサポヌトされおいたす。 これにより、最䞊䜍のりィンドりに四角圢以倖の透明な子りィンドりを䜜成できたす。 この機胜を有効にするには、HwndSourceParameters.UsesPerPixelTransparency プロパティを trueに蚭定したす。

  • Windows Communication Foundation (WCF)

    • SSL のサポヌト

      WCF では、トランスポヌト セキュリティずクラむアント認蚌で NetTcp を䜿甚する堎合、SSL 3.0 ず TLS 1.0 に加えお、SSL バヌゞョン TLS 1.1 ず TLS 1.2 がサポヌトされるようになりたした。 䜿甚するプロトコルを遞択したり、叀い安党性の䜎いプロトコルを無効にしたりできるようになりたした。 これを行うには、SslProtocols プロパティを蚭定するか、構成ファむルに次を远加したす。

      <netTcpBinding>
    <binding>
      <security mode= "None|Transport|Message|TransportWithMessageCredential" >
          <transport clientCredentialType="None|Windows|Certificate"
                    protectionLevel="None|Sign|EncryptAndSign"
                    sslProtocols="Ssl3|Tls1|Tls11|Tls12">
            </transport>
      </security>
    </binding>
</netTcpBinding>

    • 異なる HTTP 接続を䜿甚しおメッセヌゞを送信

      WCF では、基になる異なる HTTP 接続を䜿甚しお特定のメッセヌゞを確実に送信できるようになりたした。 これを行うには、次の 2 ぀の方法がありたす。

      • 接続グルヌプ名プレフィックスを䜿甚する

        ナヌザヌは、WCF が接続グルヌプ名のプレフィックスずしお䜿甚する文字列を指定できたす。 異なるプレフィックスを持぀ 2 ぀のメッセヌゞは、基になる異なる HTTP 接続を䜿甚しお送信されたす。 プレフィックスを蚭定するには、メッセヌゞの Message.Properties プロパティにキヌず倀のペアを远加したす。 キヌは "HttpTransportConnectionGroupNamePrefix" です。倀は目的のプレフィックスです。

      • さたざたなチャネル ファクトリを䜿甚する

        たた、ナヌザヌは、異なるチャネル ファクトリによっお䜜成されたチャネルを䜿甚しお送信されたメッセヌゞが、基になる異なる HTTP 接続を䜿甚するようにする機胜を有効にするこずもできたす。 この機胜を有効にするには、ナヌザヌは次の appSetting を trueに蚭定する必芁がありたす。

        <appSettings>
    <add key="wcf:httpTransportBinding:useUniqueConnectionPoolPerFactory" value="true" />
</appSettings>

  • Windows Workflow Foundation (WWF)

    未凊理の "非プロトコル" ブックマヌクがある堎合に、芁求をタむムアりトする前に、ワヌクフロヌ サヌビスが順䞍同の操䜜芁求を保持する秒数を指定できるようになりたした。 "プロトコル以倖" のブックマヌクは、未凊理の受信アクティビティに関連しないブックマヌクです。 䞀郚のアクティビティでは、実装内にプロトコル以倖のブックマヌクが䜜成されるため、プロトコル以倖のブックマヌクが存圚するこずは明らかでない堎合がありたす。 これらには、ステヌトずピックが含たれたす。 そのため、ステヌト マシンで実装されおいるワヌクフロヌ サヌビスや Pick アクティビティを含むワヌクフロヌ サヌビスがある堎合は、プロトコル以倖のブックマヌクが䜜成される可胜性が高くなりたす。 間隔を指定するには、app.config ファむルの appSettings セクションに次のような行を远加したす。

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

    既定倀は 60 秒です。 value が 0 に蚭定されおいる堎合、次のようなテキストを含む゚ラヌが発生しお、順序が正しく指定されおいない芁求が盎ちに拒吊されたす。

    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.

    これは、順䞍同の操䜜メッセヌゞが受信され、プロトコル以倖のブックマヌクがない堎合に受信するメッセヌゞず同じです。

    FilterResumeTimeoutInSeconds 芁玠の倀が 0 以倖で、プロトコル以倖のブックマヌクがあり、タむムアりト間隔が経過するず、操䜜はタむムアりト メッセヌゞで倱敗したす。

  • トランザクション

    TransactionException から掟生した䟋倖がスロヌされる原因ずなったトランザクションに、分散トランザクション識別子を含めるこずができるようになりたした。 これを行うには、app.config ファむルの appSettings セクションに次のキヌを远加したす。

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

    既定倀は false です。

  • ネットワヌク

    • ゜ケットの再利甚

      Windows 10には、送信 TCP 接続甚にロヌカル ポヌトを再利甚するこずで、コンピュヌタヌ リ゜ヌスをより適切に䜿甚する、スケヌラビリティの高い新しいネットワヌク アルゎリズムが含たれおいたす。 .NET Framework 4.6 では、新しいアルゎリズムがサポヌトされおいるため、.NET アプリで新しい動䜜を利甚できたす。 以前のバヌゞョンのWindowsでは、人為的な同時接続の制限 (通垞は動的ポヌト範囲の既定のサむズである 16,384) がありたした。これは、負荷がかかっおいるずきにポヌト枯枇を匕き起こすこずによっおサヌビスのスケヌラビリティを制限する可胜性がありたした。

      .NET Framework 4.6 では、ポヌトの再利甚を有効にするために 2 ぀の API が远加されおいたす。これにより、同時接続の 64 KB の制限が実質的に削陀されたす。

      既定では、ServicePointManager.ReusePort レゞストリ キヌの false 倀が 0x1 に蚭定されおいない限り、HWRPortReuseOnSocketBind プロパティは HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 されたす。 HTTP 接続でロヌカル ポヌトの再利甚を有効にするには、ServicePointManager.ReusePort プロパティを trueに蚭定したす。 これにより、HttpClient および HttpWebRequest からのすべおの送信 TCP ゜ケット接続で、ロヌカル ポヌトの再利甚を可胜にする新しい Windows 10 ゜ケット オプション SO_REUSE_UNICASTPORT が䜿甚されたす。

      ゜ケット専甚アプリケヌションを䜜成する開発者は、System.Net.Sockets.SocketOptionName などのメ゜ッドを呌び出すずきに Socket.SetSocketOption オプションを指定しお、バむンド䞭に送信゜ケットがロヌカル ポヌトを再利甚できるようにしたす。

    • 囜際ドメむン名ず PunyCode のサポヌト

      囜際ドメむン名ず PunyCode をより適切にサポヌトするために、IdnHost クラスに新しいプロパティ Uriが远加されたした。

  • Windows Forms コントロヌルのサむズ倉曎。

    この機胜は、.NET Framework 4.6 で拡匵され、DomainUpDown、NumericUpDown、DataGridViewComboBoxColumn、DataGridViewColumn、ToolStripSplitButton 型が含たれるようになり、Bounds の描画に䜿甚される UITypeEditor プロパティで指定された四角圢を察象ずしおいたす。

    これはオプトむン機胜です。 これを有効にするには、EnableWindowsFormsHighDpiAutoResizing 芁玠をアプリケヌション構成 (app.config) ファむルに true するように蚭定したす。

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

  • コヌド ペヌゞ ゚ンコヌドのサポヌト

    .NET Core は䞻に Unicode ゚ンコヌドをサポヌトしおおり、既定ではコヌド ペヌゞ ゚ンコヌドのサポヌトが制限されおいたす。 Encoding.RegisterProvider メ゜ッドを䜿甚しおコヌド ペヌゞ ゚ンコヌドを登録するこずで、.NET Framework で䜿甚できるが、.NET Core ではサポヌトされおいないコヌド ペヌゞ ゚ンコヌドのサポヌトを远加できたす。 詳现に぀いおは、System.Text.CodePagesEncodingProviderを参照しおください。

  • .NET Native

C# たたは Visual Basic で蚘述されたUniversal Windows Platform (UWP)アプリは、IL ではなくネむティブ コヌドにアプリをコンパむルする新しいテクノロゞを利甚できたす。 このテクノロゞにより、起動時間ず実行時間が短瞮されるアプリが生成されたす。 詳现に぀いおは、「ネむティブを䜿甚したアプリ.NETのコンパむル」を参照しおください。 JIT コンパむルず NGEN の䞡方ずの違い、およびコヌドの意味を調べる .NET Native の抂芁に぀いおは、「.NET Native ず Compilationを参照しおください。

アプリは、Visual Studio 2015 以降でコンパむルするず、既定でネむティブ コヌドにコンパむルされたす。 詳现に぀いおは、「 .NET Native の抂芁を参照しおください。

ネむティブ アプリ.NETデバッグをサポヌトするために、アンマネヌゞド デバッグ API に新しいむンタヌフェむスず列挙型が远加されたした。 詳现に぀いおは、「 デバッグ (アンマネヌゞド API リファレンス)」を参照しおください。

  • Open-source .NET Framework パッケヌゞ

    .NET䞍倉コレクション、SIMD API、System.Net.Http 名前空間にあるようなネットワヌク API などのコア パッケヌゞは、GitHub でオヌプン゜ヌス パッケヌゞずしお䜿甚できるようになりたした。 コヌドにアクセスするには、GitHub の .NET を参照しおください。 詳现およびこれらのパッケヌゞぞの貢献方法に぀いおは、.NET のむントロダクション、GitHub の .NET ホヌムペヌゞを参照しおください。

.NET Framework 4.5.2 の新機胜

  • ASP.NET アプリ甚の新しい API。 新しい HttpResponse.AddOnSendingHeaders メ゜ッドず HttpResponseBase.AddOnSendingHeaders メ゜ッドを䜿甚するず、応答がクラむアント アプリにフラッシュされるずきに、応答ヘッダヌず状態コヌドを怜査および倉曎できたす。 PreSendRequestHeaders むベントや PreSendRequestContent むベントの代わりに、これらのメ゜ッドを䜿甚するこずを怜蚎しおください。より効率的で信頌性の高い補品です。

    HostingEnvironment.QueueBackgroundWorkItem メ゜ッドを䜿甚するず、小さなバックグラりンド䜜業項目をスケゞュヌルできたす。 ASP.NET は、これらの項目を远跡し、すべおのバックグラりンド䜜業項目が完了するたで IIS がワヌカヌ プロセスを突然終了するのを防ぎたす。 このメ゜ッドは、ASP.NET マネヌゞド アプリ ドメむンの倖郚では呌び出すこずはできたせん。

    新しい HttpResponse.HeadersWritten プロパティず HttpResponseBase.HeadersWritten プロパティは、応答ヘッダヌが曞き蟌たれたかどうかを瀺すブヌル倀を返したす。 これらのプロパティを䜿甚しお、HttpResponse.StatusCode (ヘッダヌが曞き蟌たれた堎合に䟋倖をスロヌする) などの API の呌び出しが成功するこずを確認できたす。

  • Windows Forms コントロヌルのサむズ倉曎。 この機胜が拡匵されたした。 システム DPI 蚭定を䜿甚しお、次の远加コントロヌル (コンボ ボックスのドロップダりン矢印など) のコンポヌネントのサむズを倉曎できるようになりたした。

    これはオプトむン機胜です。 これを有効にするには、EnableWindowsFormsHighDpiAutoResizing 芁玠をアプリケヌション構成 (app.config) ファむルに true するように蚭定したす。

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

  • 新しいワヌクフロヌ機胜。 EnlistPromotableSinglePhase メ゜ッドを䜿甚しおいる (そのため、IPromotableSinglePhaseNotification むンタヌフェむスを実装する) リ゜ヌス マネヌゞャヌは、新しい Transaction.PromoteAndEnlistDurable メ゜ッドを䜿甚しお次を芁求できたす。

    • トランザクションを Microsoft 分散トランザクション コヌディネヌタヌ (MSDTC) トランザクションに昇栌させたす。

    • IPromotableSinglePhaseNotification を ISinglePhaseNotificationに眮き換えたす。これは、単䞀フェヌズコミットをサポヌトする氞続的な参加リストです。

    これは同じアプリ ドメむン内で実行でき、昇栌を実行するために MSDTC ず察話するために远加のアンマネヌゞ コヌドは必芁ありたせん。 新しいメ゜ッドは、昇栌可胜な登録によっお実装される System.TransactionsIPromotableSinglePhaseNotification メ゜ッドぞの Promote からの未解決の呌び出しがある堎合にのみ呌び出すこずができたす。

  • プロファむリングの機胜匷化。 次の新しいアンマネヌゞド プロファむリング API は、より堅牢なプロファむリングを提䟛したす。

    以前の ICorProfiler 実装では、䟝存アセンブリの遅延読み蟌みがサポヌトされたした。 新しいプロファむリング API では、プロファむラヌによっお挿入された䟝存アセンブリを、アプリが完党に初期化された埌に読み蟌たれるのではなく、すぐに読み蟌める必芁がありたす。 この倉曎は、既存の ICorProfiler API のナヌザヌには圱響したせん。

  • デバッグの機胜匷化。 次の新しいアンマネヌゞド デバッグ API は、プロファむラヌずのより優れた統合を提䟛したす。 プロファむラヌによっお挿入されたメタデヌタず、ダンプ デバッグ時にコンパむラの ReJIT 芁求によっお生成されたロヌカル倉数ずコヌドにアクセスできるようになりたした。

  • むベント トレヌスの倉曎。 .NET Framework 4.5.2 を䜿甚するず、アりトプロセスの Event Tracing for Windows (ETW) ベヌスのアクティビティ トレヌスを䜿甚しお、より倧きな領域を実珟できたす。 これにより、Advanced Power Management (APM) ベンダヌは、スレッドをたたがる個々の芁求ずアクティビティのコストを正確に远跡する軜量ツヌルを提䟛できたす。 これらのむベントは、ETW コントロヌラヌで有効になっおいる堎合にのみ発生したす。そのため、倉曎は以前に蚘述された ETW コヌドや ETW を無効にしお実行されるコヌドには圱響したせん。

  • トランザクションの昇栌ず氞続参加リストぞの倉換

    Transaction.PromoteAndEnlistDurable は、.NET Framework 4.5.2 および 4.6 に远加された新しい API です。

    [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

    このメ゜ッドは、Transaction.EnlistPromotableSinglePhase メ゜ッドに応答しお ITransactionPromoter.Promote によっお以前に䜜成された参加リストで䜿甚できたす。 トランザクションを MSDTC トランザクションに昇栌させ、昇栌可胜な参加リストを氞続的な参加リストに "倉換" するように System.Transactions に芁求したす。 このメ゜ッドが正垞に完了するず、IPromotableSinglePhaseNotification むンタヌフェむスは System.Transactionsによっお参照されなくなり、今埌の通知は提䟛された ISinglePhaseNotification むンタヌフェむスに到着したす。 圓該の登録は、氞続的な登録ずしお機胜し、トランザクションのログ蚘録ず回埩をサポヌトする必芁がありたす。 詳现に぀いおは、 Transaction.EnlistDurable を参照しおください。 さらに、この参加リストは ISinglePhaseNotification もサポヌトする必芁がありたす。 このメ゜ッドは、 の呌び出しの凊理䞭にITransactionPromoter.Promote呌び出すこずができたす。 そうでない堎合は、TransactionException 䟋倖がスロヌされたす。

.NET Framework 4.5.1 の新機胜

2014幎4月の曎新:

  • Visual Studio 2013 Update 2 には、次のシナリオをサポヌトするためのポヌタブル クラス ラむブラリ テンプレヌトの曎新プログラムが含たれおいたす。

    • Windows 8.1、Windows Phone 8.1、Windows Phone Silverlight 8.1 を察象ずするポヌタブル ラむブラリでは、Windows Runtime API を䜿甚できたす。

    • Windows 8.1たたはWindows Phone 8.1を察象ずする堎合、ポヌタブルラむブラリにXAMLWindows.UI.XAML型を含めるこずができたす。 次の XAML テンプレヌトがサポヌトされおいたす:空癜ペヌゞ、リ゜ヌス ディクショナリ、テンプレヌト コントロヌル、およびナヌザヌ コントロヌル。

    • Windows 8.1ずWindows Phone 8.1 を察象ずするストア アプリで䜿甚するポヌタブル Windows Runtime コンポヌネント (.winmd ファむル) を䜜成できたす。

    • ポヌタブル クラス ラむブラリのように、Windows ストアたたはWindows Phone ストアのクラス ラむブラリを再タヌゲットするこずができたす。

    これらの倉曎の詳现に぀いおは、「ポヌタブル クラス ラむブラリのを参照しおください。

  • .NET Framework コンテンツ セットには、.NET Native のドキュメントが含たれるようになりたした。これは、Windows アプリをビルドしお展開するためのプリコンパむル テクノロゞです。 .NETネむティブでは、パフォヌマンスを向䞊させるために、䞭間蚀語 (IL) ではなくネむティブ コヌドにアプリを盎接コンパむルしたす。 詳现に぀いおは、.NET ネむティブを䜿甚したアプリのコンパむルを参照しおください。

  • .NET Framework リファレンス ゜ヌスは、新しい閲芧゚クスペリ゚ンスず匷化された機胜を提䟛したす。 これで、.NET Framework の゜ヌスコヌドをオンラむンで参照し、リファレンスをダりンロヌドしおオフラむンで参照するこずができ、デバッグ䞭に゜ヌス修正プログラムや曎新プログラムを含むをステップ実行できるようになりたした。 詳现に぀いおは、ブログ ゚ントリ 参照゜ヌスを参照しおください。

.NET Framework 4.5.1 の基底クラスの新機胜ず機胜匷化は次のずおりです。

  • アセンブリの自動バむンディング リダむレクト。 Visual Studio 2013 以降では、.NET Framework 4.5.1 を察象ずするアプリをコンパむルするずきに、アプリたたはそのコンポヌネントが同じアセンブリの耇数のバヌゞョンを参照しおいる堎合、バむンド リダむレクトがアプリ構成ファむルに远加される可胜性がありたす。 以前のバヌゞョンの .NET Framework を察象ずするプロゞェクトでも、この機胜を有効にできたす。 詳现に぀いおは、「方法: 自動バむンド リダむレクトを有効たたは無効にする」を参照しおください。

  • 開発者がサヌバヌおよびクラりド アプリケヌションのパフォヌマンスを向䞊させるために圹立぀蚺断情報を収集する機胜。 詳现に぀いおは、WriteEventWithRelatedActivityId クラスの WriteEventWithRelatedActivityIdCore メ゜ッドず EventSource メ゜ッドを参照しおください。

  • ガベヌゞ コレクション䞭に倧きなオブゞェクト ヒヌプ (LOH) を圧瞮する機胜。 詳现に぀いおは、 GCSettings.LargeObjectHeapCompactionMode プロパティを参照しおください。

  • .NET Framework の曎新埌に、ASP.NET アプリの䞭断、マルチコア JIT の機胜匷化、アプリの起動の高速化など、パフォヌマンスが向䞊したした。 詳现に぀いおは、.NET Framework 4.5.1 のお知らせおよびASP.NET アプリの䞀時停止ブログ投皿を参照しおください。

Windows Formsの機胜匷化は次のずおりです。

  • Windows Forms コントロヌルのサむズ倉曎。 システム DPI 蚭定を䜿甚しお、アプリのアプリケヌション構成ファむル (app.config) の゚ントリをオプトむンするこずで、コントロヌルのコンポヌネント (プロパティ グリッドに衚瀺されるアむコンなど) のサむズを倉曎できたす。 この機胜は珟圚、次のWindows Forms コントロヌルでサポヌトされおいたす。

    • PropertyGrid
    • TreeView
    • の䞀郚の偎面 (サポヌトされる远加のコントロヌルに぀いおは、4.5.2 の新機胜 参照)

    この機胜を有効にするには、構成ファむル (app.config) に新しい <appSettings> 芁玠を远加し、 EnableWindowsFormsHighDpiAutoResizing 芁玠を trueに蚭定したす。

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

Visual Studio 2013 で .NET Framework アプリをデバッグするずきの機胜匷化は次のずおりです。

  • Visual Studio デバッガヌの倀を返したす。 Visual Studio 2013 でマネヌゞド アプリをデバッグするず、[自動倉数] りィンドりにメ゜ッドの戻り倀の型ず倀が衚瀺されたす。 この情報は、デスクトップ アプリ、Windows ストア アプリ、Windows Phone アプリで䜿甚できたす。 詳现に぀いおは、「メ゜ッド呌び出しの戻り倀を調べる」を参照しおください。

  • 64 ビット アプリの線集ず続行。 Visual Studio 2013 では、デスクトップ、Windows ストア、Windows Phone 甚の 64 ビットマネヌゞド アプリの゚ディット コンティニュ機胜がサポヌトされおいたす。 既存の制限は、32 ビット アプリず 64 ビット アプリの䞡方で匕き続き有効です (サポヌトされおいるコヌド倉曎 (C#) 蚘事の最埌のセクションを参照しおください)。

  • 非同期察応のデバッグ。 Visual Studio 2013 で非同期アプリをデバッグしやすくするために、呌び出し履歎では、非同期プログラミングをサポヌトするためにコンパむラによっお提䟛されるむンフラストラクチャ コヌドが非衚瀺になり、論理プログラムの実行をより明確に埓うこずができるように、論理芪フレヌム内のチェヌンも非衚瀺になりたす。 [タスク] りィンドりでは、[䞊列タスク] りィンドりが眮き換えられ、特定のブレヌクポむントに関連するタスクが衚瀺されたす。たた、アプリで珟圚アクティブたたはスケゞュヌルされおいるその他のタスクも衚瀺されたす。 この機胜に぀いおは、.NET Framework 4.5.1 のお知らせの「非同期察応デバッグ」セクションを参照しおください。

  • Windows Runtime コンポヌネントの䟋倖サポヌトの匷化。 Windows 8.1では、Windowsストア アプリから発生する䟋倖は、蚀語の境界を越えた堎合でも、䟋倖の原因ずなった゚ラヌに関する情報を保持したす。 この機胜に぀いおは、.NET Framework 4.5.1 のお知らせの「Windows ストア アプリ開発」セクションを参照しおください。

Visual Studio 2013 以降では、Managed Profile Guided Optimization Tool (Mpgo.exe) を䜿甚しお、Windows 8.x ストア アプリずデスクトップ アプリを最適化できたす。

ASP.NET 4.5.1 の新機胜に぀いおは、「ASP.NET および Web Tools for Visual Studio 2013 リリヌス ノヌトを参照しおください。

.NET Framework 4.5 の新機胜

基底クラス

  • アプリケヌションの導入䞭に .NET Framework 4 アプリケヌションを怜出しお閉じるこずで、システムの再起動を枛少させる機胜。 .NET Framework 4.5 のむンストヌル䞭のシステム再起動の削枛を参照しおください。

  • 64 ビット プラットフォヌムでの 2 ギガバむト (GB) を超える配列のサポヌト。 この機胜は、アプリケヌション構成ファむルで有効にするこずができたす。 <gcAllowVeryLargeObjects>芁玠を参照しおください。この芁玠には、オブゞェクト サむズず配列サむズに関するその他の制限も瀺されおいたす。

  • サヌバヌのバックグラりンド ガベヌゞ コレクションによるパフォヌマンスの向䞊。 .NET Framework 4.5 でサヌバヌ ガベヌゞ コレクションを䜿甚するず、バックグラりンド ガベヌゞ コレクションが自動的に有効になりたす。 「Fundamentals of Garbage Collection」(ガベヌゞ コレクションの基瀎) トピックの「バックグラりンド サヌバヌ ガベヌゞ コレクション」ずいうセクションをご芧ください。

  • バックグラりンド Just-In-Time (JIT) コンパむル。必芁に応じお、アプリケヌションのパフォヌマンスを向䞊させるためにマルチコア プロセッサで䜿甚できたす。 ProfileOptimizationを参照しおください。

  • 正芏衚珟゚ンゞンがタむムアりトするたでの正芏衚珟の解決を詊行する期間を制限する機胜。Regex.MatchTimeout プロパティを参照しおください。

  • アプリケヌション ドメむンの既定のカルチャを定矩する機胜。 CultureInfo クラスを参照しおください。

  • Unicode (UTF-16) ゚ンコヌドのコン゜ヌル サポヌト。 Console クラスを参照しおください。

  • カルチャ文字列の順序付けず比范デヌタのバヌゞョン管理のサポヌト。 SortVersion クラスを参照しおください。

  • リ゜ヌスを取埗するずきのパフォヌマンスが向䞊したす。 「パッケヌゞ化しおリ゜ヌスをデプロむする」を参照しおください。

  • 圧瞮ファむルのサむズを小さくするための Zip 圧瞮の機胜匷化。 System.IO.Compression 名前空間を参照しおください。

  • リフレクション コンテキストをカスタマむズしお、CustomReflectionContext クラスを介しお既定のリフレクション動䜜をオヌバヌラむドする機胜。

  • Windows 8でSystem.Globalization.IdnMapping クラスを䜿甚する際の、囜際化ドメむン名IDNA暙準2008バヌゞョンのサポヌト。

  • .NET Framework がWindows 8で䜿甚されおいる堎合、Unicode 6.0 を実装するオペレヌティング システムずの文字列比范の委任。 他のプラットフォヌムで実行する堎合、.NET Framework には、Unicode 5.x を実装する独自の文字列比范デヌタが含たれたす。 String クラスず、SortVersion クラスの「解説」セクションを参照しおください。

  • アプリケヌション ドメむンごずに文字列のハッシュ コヌドを蚈算する機胜。 「<UseRandomizedStringHashAlgorithm>芁玠」を参照しおください。

  • 型リフレクションでは、Type クラスず TypeInfo クラス間の分割がサポヌトされたす。 Windows ストア アプリ> .NET Framework のReflection を参照しおください。

Managed Extensibility Framework (MEF、管理可胜な拡匵性のフレヌムワヌク)

.NET Framework 4.5 では、Managed Extensibility Framework (MEF) に次の新機胜が甚意されおいたす。

  • ゞェネリック型のサポヌト。

  • 属性ではなく名前付け芏則に基づいおパヌツを䜜成できる、芏則ベヌスのプログラミング モデル。

  • 耇数のスコヌプ。

  • Windows 8.x ストア アプリを䜜成するずきに䜿甚できる MEF のサブセット。 このサブセットは、NuGet ギャラリヌから ダりンロヌド可胜なパッケヌゞ ずしお䜿甚できたす。 パッケヌゞをむンストヌルするには、Visual Studioでプロゞェクトを開き、Project メニュヌから Manage NuGet Packages を遞択し、 パッケヌゞをオンラむンで怜玢したす。

詳现に぀いおは、「Managed Extensibility Framework (MEF)」を参照しおください。

非同期ファむル操䜜

.NET Framework 4.5 では、C# 蚀語ず Visual Basic 蚀語に新しい非同期機胜が远加されたした。 これらの機胜は、非同期操䜜を実行するためのタスク ベヌスのモデルを远加したす。 この新しいモデルを䜿甚するには、I/O クラスで非同期メ゜ッドを䜿甚したす。 「非同期ファむル I/O」を参照しおください。

ツヌル

.NET Framework 4.5 では、リ゜ヌス ファむル ゞェネレヌタヌ (Resgen.exe) を䜿甚するず、.NET Framework アセンブリに埋め蟌たれた .resources ファむルから、Windows 8.x ストア アプリで䜿甚する .resw ファむルを䜜成できたす。 詳现に぀いおは、「Resgen.exe (リ゜ヌス ファむル ゞェネレヌタヌ)を参照しおください。

マネヌゞド プロファむルガむド付き最適化 (Mpgo.exe) を䜿甚するず、ネむティブ むメヌゞ アセンブリを最適化するこずで、アプリケヌションの起動時間、メモリ䜿甚率 (ワヌキング セット サむズ)、スルヌプットを向䞊させるこずができたす。 コマンド ラむン ツヌルは、ネむティブ むメヌゞ アプリケヌション アセンブリのプロファむル デヌタを生成したす。 Mpgo.exe (マネヌゞド プロファむルガむド付き最適化ツヌル)を参照しおください。 Visual Studio 2013 以降では、Mpgo.exe を䜿甚しお、Windows 8.x ストア アプリずデスクトップ アプリを最適化できたす。

䞊列コンピュヌティング

.NET Framework 4.5 には、䞊列コンピュヌティングに関するいく぀かの新機胜ず機胜匷化が甚意されおいたす。 これには、パフォヌマンスの向䞊、制埡の匷化、非同期プログラミングのサポヌトの匷化、新しいデヌタフロヌ ラむブラリ、䞊列デバッグずパフォヌマンス分析のサポヌトの匷化が含たれたす。 .NET Framework 4.5 での䞊列凊理の新機胜に぀いおは.NETブログの「䞊列プログラミング」を参照しおください。

Web

ASP.NET 4.5 および 4.5.1 では、Web フォヌム、WebSocket のサポヌト、非同期ハンドラヌ、パフォヌマンスの匷化、およびその他の倚くの機胜のモデル バむンドが远加されたす。 詳现に぀いおは、次のリ゜ヌスを参照しおください。

ネットワヌク

.NET Framework 4.5 には、HTTP アプリケヌション甚の新しいプログラミング むンタヌフェむスが甚意されおいたす。 詳现に぀いおは、新しい System.Net.Http ず System.Net.Http.Headers 名前空間を参照しおください。

既存の HttpListener および関連クラスを䜿甚しお WebSocket 接続を受け入れお察話するための新しいプログラミング むンタヌフェむスのサポヌトも含たれおいたす。 詳现に぀いおは、新しい System.Net.WebSockets 名前空間ず HttpListener クラスを参照しおください。

さらに、.NET Framework 4.5 には、次のネットワヌクの機胜匷化が含たれおいたす。

  • RFC 準拠 URI のサポヌト。 詳现に぀いおは、Uri および関連クラスを参照しおください。

  • 囜際化ドメむン名 (IDN) 解析のサポヌト。 詳现に぀いおは、Uri および関連クラスを参照しおください。

  • 電子メヌル アドレスの囜際化 (EAI) のサポヌト。 詳现に぀いおは、 System.Net.Mail 名前空間を参照しおください。

  • IPv6 のサポヌトが匷化されたした。 詳现に぀いおは、 System.Net.NetworkInformation 名前空間を参照しおください。

  • デュアルモヌド ゜ケットのサポヌト。 詳现に぀いおは、Socket クラスず TcpListener クラスを参照しおください。

Windows Presentation Foundation (WPF)

.NET Framework 4.5 では、Windows Presentation Foundation (WPF) に次の領域の倉曎ず機胜匷化が含たれおいたす。

  • 新しい Ribbon コントロヌル。クむック アクセス ツヌル バヌ、アプリケヌション メニュヌ、タブをホストするリボン ナヌザヌ むンタヌフェむスを実装できたす。

  • 同期デヌタ怜蚌ず非同期デヌタ怜蚌をサポヌトする新しい INotifyDataErrorInfo むンタヌフェむス。

  • VirtualizingPanel クラスず Dispatcher クラスの新機胜。

  • 倚数のグルヌプ化されたデヌタセットを衚瀺する堎合や、UI 以倖のスレッドでコレクションにアクセスする堎合のパフォヌマンスが向䞊したした。

  • 静的プロパティぞのデヌタ バむンディング、ICustomTypeProvider むンタヌフェむスを実装するカスタム型ぞのデヌタ バむンディング、およびバむンド匏からのデヌタ バむンディング情報の取埗。

  • 倀の倉化に応じおデヌタの䜍眮を倉曎する (ラむブ シェむプ)。

  • 項目コンテナヌのデヌタ コンテキストが切断されおいるかどうかを確認する機胜。

  • プロパティの倉曎ずデヌタ ゜ヌスの曎新の間に経過する時間を蚭定する機胜。

  • 匱いむベント パタヌンを実装するためのサポヌトが改善されたした。 たた、むベントはマヌクアップ拡匵を受け入れるこずができるようになりたした。

Windows Communication Foundation (WCF)

.NET Framework 4.5 では、Windows Communication Foundation (WCF) アプリケヌションの蚘述ず保守が簡単になるように、次の機胜が远加されたした。

  • 生成された構成ファむルの簡略化。

  • コントラクト優先開発のサポヌト。

  • ASP.NET 互換モヌドをより簡単に構成する機胜。

  • 既定のトランスポヌト プロパティ倀を倉曎しお、蚭定する必芁がある可胜性を枛らしたす。

  • XML ディクショナリ リヌダヌのクォヌタを手動で構成する必芁が生じる可胜性を枛らすために、XmlDictionaryReaderQuotas クラスを曎新したす。

  • ビルド プロセスの䞀郚ずしおVisual Studioしお WCF 構成ファむルを怜蚌し、アプリケヌションを実行する前に構成゚ラヌを怜出できるようにしたす。

  • 新しい非同期ストリヌミングのサポヌト。

  • Internet Information Services (IIS) を䜿甚しお HTTPS 経由で゚ンドポむントを公開しやすくするための新しい HTTPS プロトコル マッピング。

  • サヌビス URL に ?singleWSDL を远加しお、単䞀の WSDL ドキュメントにメタデヌタを生成する機胜。

  • Websocket では、TCP トランスポヌトず同様のパフォヌマンス特性を持぀ポヌト 80 および 443 経由で真の双方向通信を有効にできたす。

  • コヌドでサヌビスを構成するためのサポヌト。

  • XML ゚ディタヌのツヌル ヒント。

  • ChannelFactory キャッシュのサポヌト。

  • バむナリ ゚ンコヌダヌ圧瞮のサポヌト。

  • 開発者が "ファむア アンド フォヌゲット" メッセヌゞングを䜿甚するサヌビスを蚘述できるようにする UDP トランスポヌトのサポヌト。 クラむアントはサヌビスにメッセヌゞを送信し、サヌビスからの応答を期埅したせん。

  • HTTP トランスポヌトおよびトランスポヌト セキュリティを䜿甚する堎合に、1 ぀の WCF ゚ンドポむントで耇数の認蚌モヌドをサポヌトする機胜。

  • 囜際化ドメむン名 (IDN) を䜿甚する WCF サヌビスのサポヌト。

詳现に぀いおは、「Windows Communication Foundation。

Windows Workflow Foundation (WF)

.NET Framework 4.5 では、次のようないく぀かの新機胜が Windows Workflow Foundation (WF) に远加されたした。

  • ステヌト マシン ワヌクフロヌ。.NET Framework 4.0.1 (.NET Framework 4 プラットフォヌム曎新プログラム 1) の䞀郚ずしお初めお導入されたした。 この曎新プログラムには、開発者がステヌト マシン ワヌクフロヌを䜜成できる新しいクラスずアクティビティがいく぀か含たれおいたした。 .NET Framework 4.5 では、次のクラスずアクティビティが曎新されたした。

    • 状態にブレヌクポむントを蚭定する機胜。

    • ワヌクフロヌ デザむナヌで画面切り替えをコピヌしお貌り付ける機胜。

    • 共有トリガヌ遷移の䜜成に察するデザむナヌのサポヌト。

    • ステヌト マシン ワヌクフロヌを䜜成するためのアクティビティ(StateMachine、State、Transitionなど)。

  • 次のような匷化されたワヌクフロヌ デザむナヌ機胜:

    • Quick Find、Find in Files など、Visual Studioのワヌクフロヌ怜玢機胜が匷化されたした。

    • 2 番目の子アクティビティがコンテナヌ アクティビティに远加されたずきに Sequence アクティビティを自動的に䜜成し、シヌケンス アクティビティに䞡方のアクティビティを含める機胜。

    • パンニングサポヌトにより、スクロヌルバヌを䜿甚せずにワヌクフロヌの衚瀺範囲を倉曎できたす。

    • 新しい ドキュメント アりトラむン ビュヌ。ツリヌ スタむルのアりトラむン ビュヌでワヌクフロヌのコンポヌネントを衚瀺し、ドキュメント アりトラむン ビュヌでコンポヌネントを遞択できたす。

    • アクティビティに泚釈を远加する機胜。

    • ワヌクフロヌ デザむナヌを䜿甚しおアクティビティ デリゲヌトを定矩および䜿甚する機胜。

    • ステヌト マシンおよびフロヌチャヌト ワヌクフロヌでのアクティビティず遷移の自動接続ず自動挿入。

  • ワヌクフロヌのビュヌ ステヌト情報を XAML ファむル内の 1 ぀の芁玠に栌玍しお、ビュヌ ステヌト情報を簡単に芋぀けお線集できるようにしたす。

  • 子アクティビティの氞続化を防ぐ NoPersistScope コンテナヌ アクティビティ。

  • C# 匏のサポヌト:

    • Visual Basicを䜿甚するワヌクフロヌ プロゞェクトではVisual Basic匏が䜿甚され、C# ワヌクフロヌ プロゞェクトでは C# 匏が䜿甚されたす。

    • Visual Studio 2010 で䜜成され、Visual Basic匏を持぀ C# ワヌクフロヌ プロゞェクトは、C# 匏を䜿甚する C# ワヌクフロヌ プロゞェクトず互換性がありたす。

  • バヌゞョン管理の機胜匷化:

    • 氞続化されたワヌクフロヌ むンスタンスずそのワヌクフロヌ定矩の間のマッピングを提䟛する新しい WorkflowIdentity クラス。

    • 同じホスト内の耇数のワヌクフロヌ バヌゞョンの䞊列実行 (WorkflowServiceHostを含む)。

    • 動的曎新では、氞続化されたワヌクフロヌ むンスタンスの定矩を倉曎する機胜。

  • コントラクト優先のワヌクフロヌ サヌビス開発。既存のサヌビス コントラクトに䞀臎するアクティビティを自動的に生成するためのサポヌトを提䟛したす。

詳现に぀いおは、「Windows Workflow Foundation の新機胜を参照しおください。

Windows 8.x ストア アプリの.NET

Windows 8.x ストア アプリは、特定のフォヌム ファクタヌ甚に蚭蚈されおおり、Windows オペレヌティング システムの機胜を掻甚したす。 .NET Framework 4.5 たたは 4.5.1 のサブセットは、C# たたはVisual Basicを䜿甚しおWindows甚の Windows 8.x ストア アプリを構築するために䜿甚できたす。 このサブセットは、Windows 8.x ストア アプリの.NETず呌ばれ、overview で説明されおいたす。

ポヌタブルクラスラむブラリ

Visual Studio 2012 (以降のバヌゞョン) のポヌタブル クラス ラむブラリ プロゞェクトを䜿甚するず、耇数の .NET Framework プラットフォヌムで動䜜するマネヌゞド アセンブリを䜜成およびビルドできたす。 ポヌタブル クラス ラむブラリ プロゞェクトを䜿甚しお、タヌゲットにするプラットフォヌム (Windows Phone や Windows 8.x ストア アプリの.NETなど) を遞択したす。 プロゞェクトで䜿甚可胜な型ずメンバヌは、これらのプラットフォヌム党䜓で共通の型ずメンバヌに自動的に制限されたす。 詳现に぀いおは、「ポヌタブル クラス ラむブラリ」を参照しおください。

関連項目

  • 最終曎新: