Microsoft Windows App SDK 1.0 Stableがリリースされ、ダウンロード可能（リリースノート）

12分。読んだ

更新日 2021 年 11 月 18 日

上の更新 2021 年 11 月 18 日

読者は MSpoweruser のサポートを支援します。私たちのリンクを通じて購入すると、手数料が発生する場合があります。

いくつかのプレビュービルドの後、MicrosoftはWindows App SDK 1.0.0 Stableをリリースしました。これは、デスクトップアプリ開発者が最新のWindows UI、API、およびプラットフォーム機能を備えたアプリをビルドできるようにするツールキットです。

このリリースでは、MicrosoftはWindows App SDK 0.8から複数の新機能を追加し、1.0プレビューリリースから問題を安定させました。

[lwptoc title=”WindowsAppSDK 1.0 安定版” width=”30%” float=”right”]

WindowsUI 3

WinUI 3は、Windows App SDKのネイティブユーザーエクスペリエンス（UX）フレームワークです。

新機能とアップデート:

Microsoftは、新しいコントロール（PipsPager、Expander、BreadcrumbBar）を追加し、既存のコントロールを更新して、 WindowsUI 2.6.
単一プロジェクトのMSIXパッケージは、「空白のアプリ、パッケージ化された…」テンプレートを使用して新しいアプリケーションを作成することにより、WinUIでサポートされます。
Microsoftは、Windowsバージョン3以降でのMSIXパッケージなしのWinUI1809アプリの展開をサポートするようになりました。ご覧ください WinUI3のパッケージ化されていないデスクトップアプリを作成する追加情報について。
WinUI 3プロジェクトは、ターゲットバージョンをWindows 10、バージョン1809に設定できるようになりました。以前は、バージョン1903までしか設定できませんでした。
Visual Studio 2022 Preview 5およびGAでは、アプリ内ツールバー、ホットリロード、およびWinUIパッケージアプリのライブビジュアルツリーがサポートされています。

重要な制限:

の既知の問題 パッケージ化されたWinUIアプリケーションとパッケージ化されていないWinUIアプリケーションの両方:

C ++ Windowsランタイムコンポーネントを参照するC ++アプリのランタイムエラー： 解決するには、Windowsランタイムコンポーネントの.vcxprojの最後に以下のターゲットを追加します。

XML

<Target Name="GetPriIndexName">
<PropertyGroup>
    <!-- Winmd library targets use the default root namespace of the project for the App package name -->
    <PriIndexName Condition="'$(RootNamespace)' != ''">$(RootNamespace)</PriIndexName>
    <!-- If RootNamespace is empty fall back to TargetName -->
    <PriIndexName Condition="$(PriIndexName) == ''">$(TargetName)</PriIndexName>
</PropertyGroup>
</Target>

の既知の問題 シングルプロジェクトMSIXを使用したWinUIアプリケーション （空白のアプリ、パッケージ化されたテンプレート）：
- Visual Studioを再起動するまで、[パッケージと公開]メニュー項目がありません。 空白のアプリパッケージ（デスクトップのWinUI 2019）プロジェクトテンプレートを使用して、Visual Studio2022とVisualStudio 3の両方で単一プロジェクトMSIXを使用して新しいアプリを作成する場合、プロジェクトを公開するコマンドは、閉じるまでメニューに表示されません。 VisualStudioを再度開きます。
- シングルプロジェクトMSIXを使用するAC＃アプリは、「C ++（v14x）ユニバーサルWindowsプラットフォームツール」オプションコンポーネントがインストールされていないとコンパイルされません。意見開発者ツールをインストールする追加情報について。
- 参照されるWindowsランタイムコンポーネントで定義されたタイプを消費する単一プロジェクトMSIXを使用するアプリでの潜在的なランタイムエラー： 解決するには、手動で追加します起動可能なクラスエントリ appxmanifest.xmlに。
  - C＃アプリケーションで予想されるエラーは、「COMException：クラスが登録されていません（0x80040154（REGDB_E_CLASSNOTREG））」です。
  - C ++ / WinRTアプリケーションで予想されるエラーは、「winrt :: hresult_class_not_registered」です。
の既知の問題 MSIXパッケージなしのWinUIアプリケーション （パッケージ化されていないアプリ）：
- 一部のAPIはパッケージIDを必要とし、次のようなパッケージ化されていないアプリではサポートされていません。
  - アプリケーションデータ
  - StorageFile.GetFileFromApplicationUriAsync
  - StorageFile.CreateStreamedFileFromUriAsync
  - API情報（Windows 10ではサポートされていません）
  - パッケージ.現在
  - 内の任意のAPI Windows.ApplicationModel.Resources 名前空間
  - 内の任意のAPI Microsoft.Windows.ApplicationModel.Resources 名前空間
の既知の問題 WinUIアプリケーションのパッケージ化と展開:
- 　 Package コマンドは、単一プロジェクトMSIX（空白のアプリ、パッケージ化されたテンプレート）を使用するWinUIアプリではサポートされていません。代わりに、 Package & Publish MSIXパッケージを作成するコマンド。
- C＃クラスライブラリからNuGetパッケージを作成するには Pack コマンド、アクティブであることを確認してください Configuration is Release.
- 　 Pack コマンドは、NuGetパッケージを作成するためのC ++ Windowsランタイムコンポーネントではサポートされていません。

ウィンドウ処理

Windows App SDKは、アプリウィンドウ以前の使いやすいWindows.UI.WindowManagement.AppWindowプレビュークラスを進化させ、Win32、WPF、およびWinFormsを含むすべてのWindowsアプリで使用できるようにするクラス。

新しい特徴

アプリウィンドウは、Windowsのユーザーエクスペリエンスや他のアプリとうまく統合できる、使いやすいウィンドウシナリオを可能にする高レベルのウィンドウAPIです。アプリのコンテンツのシステム管理コンテナの高レベルの抽象化を表します。これは、コンテンツがホストされるコンテナーであり、ユーザーがアプリのサイズを変更したり画面上で移動したりするときにユーザーが操作するエンティティを表します。 Win32に精通している開発者にとって、AppWindowはHWNDの高レベルの抽象化と見なすことができます。
表示領域 HMONITORの高レベルの抽象化を表し、AppWindowと同じ原則に従います。
DisplayAreaWatcher 開発者は、ディスプレイトポロジの変更を監視し、システムで現在定義されているDisplayAreasを列挙できます。

入力

これらは、WinUIをサポートし、開発者がより高度な入力インタラクションを実現するための低レベルのAPIサーフェスを提供する入力APIです。

新しい特徴

ポインターAPI：ポインターポイント, PointerPoint プロパティ, PointEventArgs XAML入力APIを使用したポインターイベント情報の取得をサポートします。
入力ポインターソース API：ポインター入力を報告するために登録されているオブジェクトを表し、XAMLのSwapChainPanelAPIのポインターカーソルと入力イベントの処理を提供します。
カーソルAPI：開発者がカーソルビットマップを変更できるようにします。
ジェスチャー認識 API：開発者は、ポインタ情報が与えられたときに、ドラッグ、ホールド、クリックなどの特定のジェスチャを認識できます。

重要な制限

すべてポインターポイント静的ファクトリ関数は削除されました： 現在のポイントを取得, GetCurrentPointTransformed, GetIntermediatePoints, GetIntermediatePointsTransformed.
Windows AppSDKは取得をサポートしていません ポインターポイント ポインタIDを持つオブジェクト。代わりに、 ポインターポイント メンバー関数 GetTransformedPoint 既存の変換されたバージョンを取得するには ポインターポイント 物体。中間点については、 PointEventArgs メンバー関数 GetIntermediatePoints & GetTransformedIntermediatePoints.
プラットフォームSDKAPIの直接使用 Windows.UI.Core.CoreDragOperation WinUIアプリケーションでは機能しません。
ポインターポイント プロパティ 生位置 & お問い合わせRectRaw OSの通常の値と同じ予測されていない値を参照しているため、削除されました。つかいます役職 & お問い合わせRect 代わりは。ポインタ予測は、 Microsoft.UI.Input.PointerPredictor APIオブジェクト。

アプリのライフサイクル

ほとんどのアプリライフサイクル機能はUWPプラットフォームに既に存在し、デスクトップアプリタイプ、特にパッケージ化されていないコンソールアプリ、Win32アプリ、Windowsフォームアプリ、およびWPFアプリで使用するためにWindows AppSDKに組み込まれています。これらの機能のWindowsApp SDK実装は、UWPプラットフォーム自体に同等の機能があるため、UWPアプリでは使用できません。

重要

UWPアプリで作業している場合は、を参照してください UWP移行ガイダンスアプリをWindowsAppSDKに移行する方法の詳細をご覧ください。

UWP以外のアプリもMSIXパッケージにパッケージ化できます。これらのアプリはWindowsApp SDKアプリのライフサイクル機能の一部を使用できますが、これが利用可能な場合はマニフェストアプローチを使用する必要があります。たとえば、Windows AppSDKを使用することはできません XXXアクティベーションの登録 APIであり、代わりにマニフェストを介してリッチアクティベーションに登録する必要があります。

パッケージ化されたアプリのすべての制約は、パッケージ化されたWinUIアプリにも適用され、以下に説明する追加の考慮事項があります。

重要な考慮事項:

豊富なアクティベーション： GetActivatedEventArgs
- パッケージ化されていないアプリ：完全に使用可能。
- パッケージ化されたアプリ：使用可能ですが、これらのアプリはプラットフォームも使用できます GetActivatedEventArgs。プラットフォームが定義することに注意してください Windows.ApplicationModel.AppInstance 一方、Windows AppSDKは Microsoft.Windows.AppLifecycle.AppInstance。そして、UWPアプリは ActivatedEventArgs などのクラス FileActivatedEventArgs & LaunchActivatedEventArgs、Windows App SDK AppLifecycle機能を使用するアプリは、クラスではなくインターフェイスを使用する必要があります（例： IFileActivatedEventArgs, ILaunchActivatedEventArgs、等々）。
- WinUiアプリ：WinUIのApp.OnLaunchedには Microsoft.UI.Xaml.LaunchActivatedEventArgs、一方、プラットフォーム GetActivatedEventArgs を返す Windows.ApplicationModel.IActivatedEventArgs、およびWindowsAppSDK GetActivatedEventArgs を返す Microsoft.Windows.AppLifecycle.AppActivationArguments プラットフォームを表すことができるオブジェクト LaunchActivatedEventArgs.
- 詳しくは、をご覧ください。豊富なアクティベーション.
リッチアクティベーションの登録/登録解除
- パッケージ化されていないアプリ：完全に使用可能。
- パッケージ化されたアプリ：使用できません。代わりにアプリのMSIXマニフェストを使用してください。
- 詳しくは、をご覧ください。豊富なアクティベーション.
シングル/マルチインスタンス化
- パッケージ化されていないアプリ：完全に使用可能。
- パッケージ化されたアプリ：完全に使用可能。
- WinUIアプリ：アプリが他のインスタンスを検出してアクティベーションをリダイレクトする場合は、できるだけ早く、ウィンドウなどを初期化する前に行う必要があります。これを有効にするには、アプリでDISABLE_XAML_GENERATED_MAINを定義し、カスタムMain（C＃）またはWinMain（C ++）で、検出とリダイレクトを実行できます。
- RedirectActivationToAsync は非同期呼び出しであり、アプリがSTAで実行されている場合は、非同期呼び出しを待つべきではありません。 WindowsフォームおよびC＃WinUIアプリの場合、必要に応じてMainを非同期として宣言できます。 C ++ WinUIおよびC＃WPFアプリの場合、Mainを非同期として宣言することはできないため、代わりにリダイレクト呼び出しを別のスレッドに移動して、STAをブロックしないようにする必要があります。
- 詳しくは、をご覧ください。アプリのインスタンス化.
電源/状態の通知
- パッケージ化されていないアプリ：完全に使用可能。
- パッケージ化されたアプリ：完全に使用可能。
- 詳しくは、をご覧ください。パワーマネジメント.

既知の問題:

ファイルタイプの関連付けは、Verbハンドラーのコマンドラインテンプレートを設定するときに％1を誤って％251にエンコードします。これにより、パッケージ化されていないWin32アプリがクラッシュします。部分的な回避策として、レジストリ値を手動で編集して％1にすることができます。ターゲットファイルのパスにスペースが含まれている場合でも失敗し、そのシナリオの回避策はありません。
これらのシングル/マルチインスタンス化のバグは、今後のサービスパッチで修正される予定です。
- x86用にコンパイルした場合、AppInstanceリダイレクトは機能しません
- キーを登録し、登録を解除し、再登録すると、アプリがクラッシュします

Dライトコア

DWriteCoreは、次のWindows AppSDK実装です。 DirectWrite、これは、高品質のテキストレンダリング、解像度に依存しないアウトラインフォント、および完全なUnicodeテキストとレイアウトのサポートのためのDirectXAPIです。 DWriteCoreは、Windows10からWindows1809、バージョン10.0（17763;ビルドXNUMX）までのバージョンで実行されるDirectWriteの形式であり、クロスプラットフォームで使用するための扉を開きます。

特徴 DWriteCoreには、いくつかの例外を除いて、DirectWriteのすべての機能が含まれています。

重要な制限

DWriteCoreには、次のDirectWrite機能は含まれていません。
- セッションごとのフォント
- エンドユーザー定義文字（EUDC）フォント
- フォントストリーミングAPI
低レベルのレンダリングAPIサポートは部分的です。
DWriteCoreはDirect2Dと相互運用しませんが、使用できます ID書き込みグリフ実行分析 & IDWriteBitmapRenderTarget.

MRTコア

MRT Coreは、最新のWindowsの合理化されたバージョンです。資源管理システムこれは、Windows AppSDKの一部として配布されています。

重要な制限

.NETプロジェクトでは、アプリが既にビルドされている場合、プロジェクトフォルダーにコピーアンドペーストされたリソースファイルはF5でインデックス付けされません。回避策として、アプリを再構築します。見る発行1503 詳細はこちら
.NETプロジェクトでは、Visual Studio UIを使用してリソースファイルをプロジェクトに追加すると、デフォルトでファイルのインデックスが作成されない場合があります。見る発行1786 詳細については。この問題を回避するには、CSPROJファイルの以下のエントリを削除してください。

XML
```
<ItemGroup>
    <Content Remove="<image file name>" />
</ItemGroup>
<ItemGroup>
    <PRIResource Remove="<resw file name>" />
</ItemGroup>
```
パッケージ化されていないC ++ WinUIアプリの場合、リソースURIが正しく構築されていません。この問題を回避するには、vcxprojに以下を追加します。

XML
```


<PropertyGroup>
    <AppxPriInitialPath></AppxPriInitialPath>   
</PropertyGroup>
```

展開

新機能とアップデート

Windows App SDKは、次の方法で自動初期化できます。 WindowsPackageType project プロパティを使用して、Windows App SDKランタイムをロードし、Windows App SDKAPIを呼び出します。見る WinUI3アプリを作成する手順を参照してください。
パッケージ化されていないアプリは、スタンドアロンのWindows App SDKに統合することで、Windows AppSDKをデプロイできます .exe 既存のMSIまたはセットアッププログラムへのインストーラー。詳細については、を参照してください。パッケージ化されていないアプリのWindowsAppSDK展開ガイド.
パッケージ化されていない.NETアプリは、.NETラッパーを使用することもできます。ブートストラップ API 実行時にWindowsAppSDKフレームワークパッケージへの依存関係を動的に取得します。 .NETラッパーの詳細については、を参照してください。 .NETラッパーライブラリ.
パッケージ化されたアプリは、デプロイメントAPIを使用して、必要なすべてのパッケージがマシンにインストールされていることを確認および確認できます。デプロイAPIの仕組みの詳細については、パッケージ化されたアプリのデプロイガイド.

重要な制限

bootstrapper APIの.NETラッパーは、Windows AppSDKへのアクセスを簡素化するためにパッケージ化されていない.NETアプリケーションでのみ使用することを目的としています。
完全に信頼されている、またはパッケージ管理制限された機能には、デプロイメントAPIを使用してメインパッケージとシングルトンパッケージの依存関係をインストールする権限があります。部分信頼パッケージアプリのサポートは、今後のリリースで提供される予定です。
F5がを使用するx86アプリをテストする場合 DeploymentManager.Initialize x64システムのメソッドでは、x64フレームワークが最初にインストールされていることを確認します。 WindowsAppRuntimeInstall.exe。そうでなければ、あなたは遭遇するでしょう 見つかりません Visual Studioがx64フレームワークを展開していないためにエラーが発生します。これは通常、ストアの展開またはサイドローディングによって発生します。

その他の制限と既知の問題

CPUビルド構成はサポートされていません：いつ Windows AppSDKの追加サポートする既存の.NETアプリケーションまたはコンポーネントへ 任意の CPU、目的のアーキテクチャを指定する必要があります。 x86, x64 or arm64.
.NET5から.NET6へのアップグレード：Visual Studio UIでアップグレードすると、ビルドエラーが発生する場合があります。回避策として、プロジェクトファイルのTargetFrameworkPackageを手動で以下に更新します。

XML
```
    <TargetFramework>net6.0-windows10.0.19041.0</TargetFramework> 
```
C ++ UWPツールがインストールされていない場合、C＃単一プロジェクトMSIXアプリはコンパイルされません。 C＃シングルプロジェクトMSIXプロジェクトがある場合は、 C ++（v14x）ユニバーサルWindowsプラットフォームツール オプションのコンポーネント。
Visual Studio 2019の複数のバージョンがインストールされている場合、後続の言語VSIXはVisual Studio2019にインストールできません。 Visual Studio 2019の複数のバージョン（リリースとプレビューなど）をインストールしてから、両方のC ++用のWindowsApp SDKVSIXをインストールする場合 & C＃、2019番目のインストールは失敗します。解決するには、第一言語VSIXの後に、Visual StudioXNUMX用の単一プロジェクトMSIXパッケージツールをアンインストールします。意見このフィードバックこの問題の詳細については。
あなたがしたい場合 co_await DispatcherQueue.TryEnqueue メソッド、次に使用します再開_フォアグラウンドのヘルパー関数 Windows実装ライブラリ（WIL）:
1. への参照を追加します Microsoft.Windows.ImplementationLibrary NuGetパッケージ。
2. 加えます #include <wil/cppwinrt_helpers.h> コードファイルへのステートメント。
3. 　 wil::resume_foreground(your_dispatcher); 〜へ co_await 結果。