.NET Core 3.0 Preview 4 is now available and it includes a bunch of new updates to ASP.NET Core. Here’s the list of what’s new in this preview: Razor Components renamed back to server-side Blazor Client-side Blazor on WebAssembly now in official preview Resolve components based on @using _Imports.razor New component item template Reconnection to the same server Stateful reconnection after prerendering Render stateful interactive components from Razor pages and views Detect when the app is prerendering Configure the SignalR client for server-side Blazor apps Improved SignalR reconnect features Configure SignalR client for server-side Blazor apps Additional options for MVC service registration Endpoint routing updates New template for gRPC Design-time build for gRPC New Worker SDK Please see the release notes for additional details and known issues.

情報源: ASP.NET Blog | ASP.NET Core updates in .NET Core 3.0 Preview 4

Memo.

Client-side Blazor on WebAssembly now in official previewとか、こちらもいろいろ。

情報源: Announcing the .NET Framework 4.8 | .NET Blog

.NET Framework 4.8がリリースされました。恐らくメジャーなアップデートはこれが最後になるんじゃないかと。

Windows 10 May 2019 Update(19H1)にはこれが含まれています。それ以外のOS、バージョン向けには、以下よりダウンロードが可能です。

• Web Installer
• Offline Installer

サポートされるWindowsのバージョン

Windows Client

Windows 10 version 1903, Windows 10 version 1809, Windows 10 version 1803, Windows 10 version 1709, Windows 10 version 1703, Windows 10 version 1607, Windows 8.1, Windows 7 SP1

Windows Server

Windows Server 2019, Windows Server version 1803, Windows Server 2016, Windows Server 2012, Windows Server 2012 R2, Windows Server 2008 R2 SP1

.NET Framework 4.8での新機能

ランタイム – JITの改良

.NET 4.8のJITが.NET Core 2.1ベースとなりました。.NET Core 2.1のすべてのバグ修正と多くのコード生成ベースのパフォーマンス最適化は、.NET Frameworkで利用可能になりました。

ランタイム – NGENの改良

.NET FrameworkのNGENイメージには、書き込み可能セクションと実行可能セクションが含まれなくなりました。これは、実行されるメモリを変更することによって、任意のコードを実行しようとする攻撃に利用可能なサーフェースを減少させます。

実行時にはまだ書き込み可能な実行可能データがメモリに残っていますが、この変更によりNGENイメージからマップされたデータは削除され、イメージ内の実行可能/書き込み可能セクションを許可しない制限のある環境で実行できます。

BCL – ZLibのアップデート

.NET Framework 4.5以降、defrアルゴリズムの実装を提供するために、clrcompression.dllのhttp://zlib.netからネイティブバージョンのZLib（データ圧縮に使用されるネイティブ外部圧縮ライブラリ）を使用しました。 .NET Framework 4.8では、clrcompression.dllをバージョン1.2.11を使用するように更新しました。これには、いくつかの重要な改善と修正が含まれています。

BCL – 暗号化に対するFIPSの影響を減少させる

NET Framework 2.0以降には、システム暗号化ライブラリが「FIPSモード」で設定されている場合にCryptographicExceptionをスローするSHA256Managedなどの暗号化プロバイダクラスがあります。これらの例外は、システム暗号化ライブラリとは異なり、管理対象バージョンがFIPS（Federal Information Processing Standards）140-2認証を受けていないため（JITおよびNGENイメージ生成は両方とも認証を無効にするため）にスローされます。開発マシンが「FIPSモード」になっている開発者はほとんどいません。そのため、本番環境（または顧客システム）でこれらの例外が発生します。「FIPSモード」設定は、FIPS規則で承認されたアルゴリズムとは見なされなかった暗号化アルゴリズムをブロックするために.NET Frameworkでも使用されていました。

.NET Framework 4.8用に構築されたアプリケーションの場合、これらの例外はスローされなくなります（デフォルト）。代わりに、SHA256Managedクラス（および他のマネージ暗号化クラス）は暗号化操作をシステム暗号化ライブラリにリダイレクトします。このポリシーの変更により、コードが実行され、ネイティブコンポーネントと管理対象コンポーネントが同じ暗号化ポリシーの下で動作する開発環境と運用環境の間の潜在的に混乱を招く違いが効果的に排除されます。

.NET Framework 4.8をターゲットとするアプリケーションは自動的に新しい緩和されたポリシーに切り替わり、「FIPSモード」のときにMD5Cng、MD5CryptoServiceProvider、RC2CryptoServiceProvider、RIPEMD160Managed、およびRijndaelManagedから例外がスローされなくなります。以前のバージョンの例外に依存するアプリケーションは、AppContextスイッチの “Switch.System.Security.Cryptography.UseLegacyFipsThrow”を “true”に設定することで以前の動作に戻ることができます。

Windows Forms – ユーザー補助の機能強化

.NET Framework 4.8のWindows Formsでは、開発者がよりアクセスビリティ型回アプリケーションを開発できるように3つの新機能を追加しています。追加された機能は、視覚障害のあるユーザーへのアプリケーションデータのコミュニケーションをより堅牢にすることを目的にしています。ユーザーがキーボードを介して(コントロール間を)移動するときのツールチップのサポートを追加しました。一般的に使用される多くのコントロールにLive RegionsとNotificationイベントを追加しました(こうすることで視覚に障害を持っている方に対して、コントロールをタブなどで移動した際に。適切な言語で、どの様なコントローラに移動したのかナレーターに話させることが出来ます)。

これらの機能を有効にするには、アプリケーションのApp.Configファイルッデ次のAppContextSwitchesを行こうにする必要があります。

Windows Forms – ラベルとステータスストリップでのUIA　LiveRegionsのサポート

UIA Live Regionsを使用すると、アプリケーション開発者は、ユーザーが作業している場所とは別の場所にあるコントロール上のテキストの変更をスクリーンリーダーに通知できます。これが便利になる場所の例は、接続ステータスを示すStatusStripです。接続が切断されてステータスが変更された場合、開発者はこの変更をスクリーンリーダーに通知することをお勧めします。Windowsフォームは、LabelコントロールとStatusStripコントロールの両方にUIA LiveRegionsを実装しました。

ラベルコントロールでのLiveRegionの使用例

public Form1()
 {
   InitializeComponent();
   label1.AutomationLiveSetting = AutomationLiveSetting.Polite;
 }
 
…
Label1.Text = Ready!;

ユーザーがアプリケーションと対話している場所に関係なく、ナレータは「準備完了」をアナウンスします。
UserControlをLiveリージョンとして実装することもできます。

using System;
using System.Windows.Forms;
using System.Windows.Forms.Automation;
 
namespace WindowsFormsApplication
{
 public partial class UserControl1 : UserControl, IAutomationLiveRegion
  {
   public UserControl1()
    {
     InitializeComponent();
    }
 
    public AutomationLiveSetting AutomationLiveSetting { get; set; }
    private AutomationLiveSetting IAutomationLiveRegion.GetLiveSetting() 
     {
      return this.AutomationLiveSetting;
     }
 
    protected override void OnTextChanged(EventArgs e)
     {
      base.OnTextChanged(e);
      AutomationNotifications.UiaRaiseLiveRegionChangedEvent(this.AccessibilityObject);
     }
  }
}

Windows Forms – UIA通知イベント

Windows 10 Fall Creators Updateは、内容が変更されたことをアプリケーションにナレーターに通知させる新しい方法を導入しました、そしてナレーターは変更を発表するべきです。UIA通知イベントを使用すると、アプリでUIAイベントを発生させることができます。これにより、UIで対応するコントロールを使用することなく、イベントと共に提供されたテキストに基づいてナレーターがアナウンスを行うことができます。いくつかのシナリオでは、これはあなたのアプリのアクセシビリティを劇的に向上させるための直接的な方法かもしれません。UIA通知イベントの詳細については、このブログ投稿を参照してください。

通知が便利になる可能性がある場所の例は、時間がかかる可能性のあるプロセスの進行状況を通知することです。

Notificationイベントを発生させる例：

MethodInfo raiseMethod = typeof(AccessibleObject).GetMethod("RaiseAutomationNotification");
if (raiseMethod != null) {
raiseMethod.Invoke(progressBar1.AccessibilityObject, new object[3] {/*Other*/ 4, /*All*/ 2, "The progress is 50%." });

Windows Forms – キーボードアクセスに関するツールチップ

現在、コントロールツールチップは、マウスポインタをコントロールに移動することによってのみポップアップ表示させることができます。この新しい機能により、キーボードユーザーは、Tabキーまたは矢印キーを使用してコントロールキーにフォーカスを合わせることで、コントロールのツールチップを表示させることができます。次の例に示すように、この特定のアクセシビリティ強化には追加のAppContextSwitchが必要です。

1．新しいWinFormsアプリケーションを作成する。
2．App.configファイルに次のXMLを追加します。

3．アプリケーションのフォームに複数のボタンとツールヒントコントロールを追加します。
4．ボタンのツールチップを設定します。
5．アプリケーションを実行し、キーボードを使用してボタン間を移動します。

Windows Forms – DataGridViewコントロールによるアクセス可能な階層の変更

詳細は情報源参照。

WCF – ServiceHealthBehavior

正常性エンドポイントには多くの利点があり、サービスの正常性状態に基づいてサービスを管理するためにオーケストレーションツールによって広く使用されています。ヘルスチェックは、監視ツールでサービスの可用性とパフォーマンスを追跡してアラートを出すためにも使用できます。これらのツールは、初期の問題の指標として機能します。

ServiceHealthBehaviorは、IServiceBehaviorを拡張するWCFサービスビヘイビアーです。ServiceDescription.Behaviorsコレクションに追加すると、以下が有効になります。

• HTTP応答コードを使用してサービスの正常性状態を返す：HTTP / GET正常性プローブ要求のHTTP状態コードをクエリ文字列で指定できます。
• サービス状態の公開：サービス状態、スロットル数、および容量を含むサービス固有の詳細は、 “？health”クエリ文字列を使用したHTTP / GET要求を使用して表示されます。不正なWCFサービスをトラブルシューティングするときは、表示されている情報を知っていて簡単にアクセスできることが重要です。

Config ServiceHealthBehavior：

正常性エンドポイントを公開してWCFサービス正常性情報を公開する方法は2つあります。コードを使用する方法と構成ファイルを使用する方法です。

1．コードを使用してヘルスエンドポイントを有効にする

ServiceHost host = new ServiceHost(typeof(Service1), 
        new Uri("http://contoso:81/Service1")); 
    ServiceHealthBehavior healthBehavior = 
                host.Description.Behaviors.Find(); 
    if (healthBehavior == null) 
     { 
        healthBehavior = new ServiceHealthBehavior(); 
     } 
    host.Description.Behaviors.Add(healthBehavior); 

2．設定を使用してヘルスエンドポイントを有効にする

HTTP応答コードを使用してサービスの正常性状態を返す

正常性状態は、クエリパラメータ（OnServiceFailure、OnDispatcherFailure、OnListenerFailure、OnThrottlePercentExceeded）によって照会できます。各照会パラメーターにHTTP応答コード（200 – 599）を指定できます。HTTP応答コードがクエリパラメータで省略されている場合、デフォルトで503 HTTP応答コードが使用されます。

1. OnServiceFailure:
   • 例：https://contoso：81/Service1?health&OnServiceFailure = 450を照会することにより、ServiceHost.StateがCommunicationState.Openedより大きい場合は、450のHTTP応答ステータスコードが返されます。
2. OnDispatcherFailure：
   • 例：https://contoso：81/Service1?health&OnDispatcherFailure = 45 5を照会して、いずれかのチャネルディスパッチャの状態がCommunicationState.Openedより大きい場合、455 HTTP応答ステータスコードが返されます。
3. OnListenerFailure：
   • 例：https://contoso：81/Service1?health&OnListenerFailure = 4 65を照会して、いずれかのチャネルリスナーの状態がCommunicationState.Openedより大きい場合、465 HTTP応答ステータスコードが返されます。
4. OnThrottlePercentExceeded：応答をトリガーするパーセンテージ{1 – 100}とそのHTTP応答コード{200 – 599}を指定します。
   • 例：https://contoso：81/ Service1?health＆OnThrottlePercentExceeded = 70：350、95：500を照会することにより、スロットルの割合が95％以上の場合、HTTP応答コード500が返されます。パーセンテージが70％以上95％未満の場合、350が返されます。それ以外の場合は、200が返されます。

サービスヘルスの公開：

ヘルスエンドポイントを有効にした後、サービスの健全性ステータスは、html（クエリ文字列：https://contoso：81/Service1?healthを指定）またはxml（クエリ文字列：https://contoso:81/Service1?health&Xmlの指定）で表示できます。 形式。https://contoso:81/Service1?health&NoContentは空のHTMLページを返します。

注意：

常にサービスヘルスエンドポイントへのアクセスを制限することをお勧めします。以下のメカニズムを使用してアクセスを制限できます。

1. ヘルスエンドポイントには、他のサービスに使用されているものとは異なるポートを使用し、アクセスを制御するためにファイアウォールルールを使用します。
2. ヘルスエンドポイントバインディングに望ましい認証と承認を追加します。

WPF – スクリーンナレーターは折りたたみまたは非表示の可視性を持つ要素を発表しなくなりました

折りたたみまたは非表示の可視性を持つ要素は、スクリーンリーダーによって発表されなくなりました。表示が「折りたたまれている」または「隠されている」の要素を含むユーザーインターフェイスは、そのような要素がユーザーに通知されると、スクリーンリーダーによって誤って表示される可能性があります。.NET Framework 4.8では、WPFはUIAutomationツリーのコントロールビューに折りたたみまたは非表示の要素を含まなくなり、スクリーンリーダーはこれらの要素をアナウンスできなくなりました。

WPF – Adornerに基づかないテキスト選択で使用するためのSelectionTextBrushプロパティ

詳細は情報源参照。

WPF – 高DPIの機能強化

詳細は情報源参照。

WPF – UIAutomationのControllerForプロパティをサポート

詳細は情報源参照。

WPF – キーボードアクセスに関するツールチップ

現在、ツールチップは、ユーザーがコントロールの上にマウスカーソルを置いたときにのみ表示されます。.NET Framework 4.8では、WPFは、ショートカットキーと同様にツールチップをキーボードフォーカスで表示できるようにする機能を追加しています。

この機能を有効にするには、アプリケーションは、AppContextスイッチ「Switch.UseLegacyAccessibilityFeatures.3」および「Switch.UseLegacyToolTipDisplay」を介して.NET Framework 4.8をターゲットにするか、オプトインする必要があります。

サンプルApp.configファイル：

有効にすると、ツールヒントを含むすべてのコントロールは、コントロールがキーボードフォーカスを受け取るとそれを表示し始めます。ツールチップは、時間の経過とともに、またはキーボードのフォーカスが変わったときに消去されます。ユーザーは新しいキーボードショートカットCtrl + Shift + F10を使って手動でツールチップを閉じることもできます。ツールチップがいったん解除されると、同じキーボードショートカットを使って再び表示することができます。

注：リボンコントロールのRibbonToolTipsはキーボードフォーカスでは表示されません – キーボードショートカットでのみ表示されます。

WPF – SizeOfSetおよびPositionInSet UIAutomationプロパティのサポートを追加しました

詳細は情報源参照。

リリースノート

.NET Framework 4.8 Release Notes