次の方法で共有

Windows App SDK 1.0 の安定チャネルのリリース ノート

安定チャネルは、運用環境のアプリで使用するためにサポートされている Windows アプリ SDK のリリースを提供します。 Windows App SDK の安定したリリースを使用するアプリは、Microsoft Store にも公開できます。

重要なリンク:

最新の安定チャネル リリース:

Windows App SDK 用のダウンロード

注

Windows アプリ SDK Visual Studio 拡張機能（VSIX）は、現在は個別のダウンロードとして配布されていません。 それらは、Visual Studio内のVisual Studio Marketplaceで利用可能です。

バージョン 1.0.4

これは、1.0 リリースの重要なバグ修正を含む Windows App SDK のサービス リリースです。

バグ修正 (1.0.4)

  • Page.TopAppBar または Page.BottomAppBar として使用すると、AppBars が画面に表示されない問題を修正しました。
  • MUXControls.dll の WinUI コントロールを使用するパッケージ名が 12 文字以下のアプリが直ちにクラッシュする問題を修正しました。 詳細については、GitHub 問題 6360 を参照してください。
  • キーボード ショートカットやその他のシナリオで問題が発生するタッチ入力の問題を修正しました。 詳細については、GitHub 問題 6291 を参照してください。
  • MSIX でパッケージ化されたアプリ、または自己完結型として展開されたアプリが展開に失敗する問題を修正しました。
  • ドラッグ アンド ドロップ操作中にアプリがクラッシュすることがある問題を修正しました。 詳細については、GitHub 問題 7002 を参照してください。

バージョン 1.0.3

これは、1.0 リリースの重要なバグ修正を含む Windows App SDK のサービス リリースです。

バグ修正 (1.0.3)

  • C/C++ ランタイム (CRT) がインストールされていないときに、WebView2 を使用する C# アプリが起動時にクラッシュする問題を修正しました。
  • キーボード ショートカットやその他のシナリオで問題が発生するタッチ入力の問題を修正しました。 詳細については、GitHub 問題 6291 を参照してください。

注: 通常、サービス リリースでは機能を追加しませんが、このリリースの WebView2 修正プログラムでは、WebView2 SDK の最新バージョン (1020.46 から 1185.39) に更新する必要がありました。 WebView2 1.0.1185.39 についての追加情報は、WebView2 SDK の リリースノートを参照してください。また、WebView2 ランタイムについての追加情報については、「アプリと WebView2 ランタイムの配布 」をご覧ください。

バージョン 1.0.2

これは、1.0 リリースの重要なバグ修正を含む Windows App SDK のサービス リリースです。

バグ修正 (1.0.2)

  • ListView の末尾までスクロールするとアプリがクラッシュするレイアウト サイクルの問題を修正しました。 詳細については、GitHub 問題 6218 を参照してください。
  • C/C++ ランタイム (CRT) がインストールされていないときに C# アプリが起動時にクラッシュする問題を修正しました。 ただし、WebView2 を使用する C# アプリでは、CRT は引き続き必要です。 詳細については、GitHub 問題 2117 を参照してください。
  • 単一プロジェクト MSIX を使用するアプリケーションで .appinstaller ファイルが生成されない問題を修正しました。 詳細については、GitHub 問題 1821 を参照してください。
  • WinUI アプリケーションで .NET 6 dotnet buildがサポートされない問題を修正しました。

バージョン 1.0.1

これは、1.0 リリースの重要なバグ修正とマルチウィンドウ サポートを含む Windows App SDK のサービス リリースです。

バグ修正 (1.0.1)

  • 有効な ImplicitUsings で MddBootstrapAutoinitializer がコンパイルされない問題を修正しました。 詳細については、GitHub 問題 1686 を参照してください。
  • WebView2 のフォーカスが予期せず失われ、入力と選択の問題が発生する問題を修正しました。 詳細については、GitHub の 問題 5615 および 問題 5570 を参照してください。
  • WinUI 3 アプリでカスタム タイトル バーを使用すると、Visual Studio のアプリ内ツールバーがクリックできなくなる問題を修正しました。
  • WinUI 3 アプリでカスタム タイトル バーを使用しているときにスナップ レイアウトが表示されない問題を修正しました。 詳細については、GitHub の 問題 6333 および 問題 6246 を参照してください。
  • Window.SetTitlebar が読み込み中の UIElement で呼び出されたときに Window.ExtendsContentIntoTitleBar プロパティを設定するときに例外が発生する問題を修正しました。
  • 単一プロジェクトの MSIX アプリが dotnet buildをサポートしていない問題を修正しました。
  • パッケージ化されていないアプリをインストールした後に、パッケージ化されていないアプリがインストールされない問題を修正しました。 詳細については、GitHub 問題 1871 を参照してください。
  • マウスドラッグ操作中のパフォーマンス低下の問題を修正しました。
  • パッケージ化されていないアプリで GetWindowIdFromWindow() を呼び出すときのクラッシュを修正しました。 詳細については、GitHub ディスカッション 1891 を参照してください。

バージョン 1.0 の 制限事項と既知の問題 は、バージョン 1.0.1 にも適用されます。

さらに、カスタム タイトル バーを使用するアプリの場合は、このリリースで変更を加え (多数の問題を修正しました)、ドラッグ&ドロップ操作に使用されるガラス ウィンドウの修正が含まれています。 既定値と動作を使用することをお勧めします (試してみる)。 タイトル バーで既定のキャプション ボタンがインタラクティブになるように余白を使用している場合は、タイトル バーの背景を赤に設定し、余白を調整してドラッグ領域をキャプション コントロールに拡張することで、ドラッグ領域を視覚化することをお勧めします。

新機能

WinUI 3 アプリケーションで、同じスレッド で複数のウィンドウ 作成を安定させ、有効にしました。 詳細については 問題 5918 を参照してください。

バージョン 1.0

以降のセクションでは、1.0 の新機能と更新された機能、制限事項、既知の問題について説明します。

WinUI 3

WinUI 3 は、Windows App SDK のネイティブ ユーザー エクスペリエンス (UX) フレームワークです。 このリリースでは、Windows App SDK 0.8 から複数の新機能が追加され、1.0 プレビュー リリースの問題が安定しました。

新機能と更新プログラム:

  • 新しいコントロール (PipsPager、Expander、BreadcrumbBar) を追加し、既存のコントロールを更新して、WinUI 2.6の最新の Windows スタイルを反映しました。
  • WinUI では、「空のアプリ、パッケージ化」テンプレートを使用して新しいアプリケーションを作成することで、単一プロジェクトの MSIX パッケージ化がサポートされます。
  • Windows バージョン 1809 以降にパッケージ化されていない WinUI 3 アプリの展開がサポートされるようになりました。 詳しくは、 最初の WinUI 3 (Windows App SDK) プロジェクトの作成 に関するページをご覧ください。
  • WinUI 3 プロジェクトで、ターゲット バージョンを Windows 10 バージョン 1809 に設定できるようになりました。 以前は、バージョン 1903 ほどしか設定できませんでした。
  • アプリ内ツール バー、ホット リロード、および WinUI パッケージ アプリのライブ ビジュアル ツリーは、Visual Studio 2022 Preview 5 および GA でサポートされています。

重要な制限事項:

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

    • C++ Windows ランタイム コンポーネントを参照する C++ または C# アプリの実行時エラー:

      • 解決するには、Windows ランタイム コンポーネントの.vcxprojの末尾に次のターゲットを追加します。
      <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>
      • 予期されるエラーは、WinRT 起源エラー - 0x80004005: 'ms-appx:///BlankPage.xaml からリソースを見つけることができません' に似ています。

  • 単一プロジェクトの MSIX (空のアプリ、パッケージ 化されたテンプレート) を使用する WinUI アプリケーションに関する既知の問題:

    • Visual Studio を再起動するまで、パッケージと発行メニュー項目がありません。 Visual Studio 2019 と Visual Studio 2022 の両方で、空のアプリ Packaged (デスクトップの WinUI 3) プロジェクト テンプレートを使用して単一プロジェクト MSIX を使用して新しいアプリを作成する場合、Visual Studio を閉じて再度開くまで、プロジェクトを発行するコマンドはメニューに表示されません。
    • 単一プロジェクト MSIX を使用する C# アプリは、"C++ (v14x) ユニバーサル Windows プラットフォーム ツール" オプション コンポーネントがインストールされていないとコンパイルされません。 詳細については、「Windows App SDK のインストール ツール」を参照してください。
    • 参照先の Windows ランタイム コンポーネントで定義された型を使用する単一プロジェクト MSIX を使用するアプリで発生する可能性のある実行時エラー: 解決するには、アクティブ化可能なクラス エントリ 手動で appxmanifest.xmlに 追加します。
      • C# アプリケーションで予期されるエラーは、"COMException: Class not registered (0x80040154 (REGDB_E_CLASSNOTREG)) です。
      • C++/WinRT アプリケーションで予期されるエラーは "winrt::hresult_class_not_registered" です。

  • パッケージ化されていない WinUI 3 アプリの既知の問題 (パッケージ化されていないアプリ):

  • winUI アプリケーションのパッケージ化と展開 に関する既知の問題:

    • Package コマンドは、単一プロジェクト MSIX (空のアプリ、パッケージ 化されたテンプレート) を使用する WinUI アプリではサポートされていません。 代わりに、Package & Publish コマンドを使用して MSIX パッケージを作成します。
    • Pack コマンドを使用して C# クラス ライブラリから NuGet パッケージを作成するには、アクティブな Configuration が Releaseされていることを確認します。
    • Pack コマンドは、NuGet パッケージを作成するための C++ Windows ランタイム コンポーネントではサポートされていません。

詳細については、または WinUI での開発を開始するには、次を参照してください。

ウィンドウ化

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

新機能:

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

詳細については、「 アプリ ウィンドウの管理 (Windows App SDK)」を参照してください。

インプット

これらは、WinUI をサポートし、開発者がより高度な入力操作を実現するための下位レベルの API サーフェスを提供する入力 API です。

新機能:

  • ポインター API: PointerPoint、PointerPointProperties、および PointerEventArgs を使用して、XAML 入力 API を使用したポインター イベント情報の取得をサポートします。
  • InputPointerSource API: レポート ポインター入力に登録されているオブジェクトを表し、XAML の SwapChainPanel API のポインター カーソルと入力イベント処理を提供します。
  • Cursor API: 開発者がカーソル ビットマップを変更できるようにします。
  • GestureRecognizer API: 開発者は、ポインター情報が与えられたときにドラッグ、ホールド、クリックなどの特定のジェスチャを認識できます。

重要な制限事項:

  • PointerPoint 静的ファクトリ関数がすべて削除されました:GetCurrentPoint、GetCurrentPointTransformed、GetIntermediatePoints、および GetIntermediatePointsTransformed。
  • Windows App SDK では、ポインター ID を持つ PointerPoint オブジェクトの取得 はサポートされていません。 代わりに、GetTransformedPoint PointerPoint メンバー関数を使用して、既存の PointerPoint オブジェクトの変換されたバージョンを取得できます。 中間ポイントに対しては、PointerEventArgs のメンバー関数 GetIntermediatePoints と GetTransformedIntermediatePointsを使用できます。
  • プラットフォーム SDK API Windows.UI.Core.CoreDragOperation を直接使用することは、WinUI アプリケーションでは機能しません。
  • PointerPoint プロパティ RawPosition と ContactRectRaw は、OS の通常の値と同じ非予測値を参照していたため、削除されました。 代わりに、位置 と ContactRect を使用します。 ポインター予測は、Microsoft.UI.Input.PointerPredictor API オブジェクトで処理されるようになりました。

アプリのライフサイクル

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

重要

UWP アプリで作業している場合は、「UWP から Windows App SDK に移行する」を参照してください。

UWP 以外のアプリは、MSIX パッケージにパッケージ化することもできます。 これらのアプリは、Windows App SDK アプリ ライフサイクル機能の一部を使用できますが、これを利用できるマニフェスト アプローチを使用する必要があります。 たとえば、Windows App SDK RegisterForXXXActivation API を使用することはできず、代わりにマニフェストを使用してリッチ アクティブ化に登録する必要があります。

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

重要な考慮事項:

  • リッチアクティブ化: GetActivatedEventArgs

    • パッケージ化されていないアプリの: 完全に使用できます。
    • パッケージアプリ:使用可能ですが、これらのアプリはプラットフォーム GetActivatedEventArgsを使用することもできます。 プラットフォームでは Windows.ApplicationModel.AppInstance が定義されているのに対し、Windows App SDK では 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 はプラットフォーム を表すことができる LaunchActivatedEventArgs オブジェクトを返します。
    • 詳細については、 アプリ ライフサイクル API を使用したリッチ アクティブ化に関するページを参照してください。

  • リッチ アクティベーションの登録/登録解除

  • 単一/複数インスタンス化

    • パッケージ化されていないアプリの: 完全に使用できます。
    • パッケージ アプリ: 完全に利用可能です。
    • WinUI アプリの: アプリが他のインスタンスを検出してアクティブ化をリダイレクトする場合は、できるだけ早く、またはウィンドウを初期化する前などに行う必要があります。これを有効にするには、アプリでDISABLE_XAML_GENERATED_MAINを定義し、検出とリダイレクトを実行できるカスタム Main (C#) または WinMain (C++) を記述する必要があります。
    • RedirectActivationToAsync は非同期呼び出しであり、アプリが STA で実行されている場合は非同期呼び出しを待つべきではありません。 Windows フォームおよび C# WinUI アプリの場合は、必要に応じて Main を非同期として宣言できます。 C++ WinUI および C# WPF アプリの場合、Main を非同期として宣言することはできません。代わりに、STA をブロックしないようにリダイレクト呼び出しを別のスレッドに移動する必要があります。
    • 詳細については、 アプリ ライフサイクル API を使用したアプリのインスタンス化に関するページを参照してください。

  • 電源/状態通知

既知の問題:

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

DWriteCore(ドライトコア)

DWriteCore は、DirectWriteの Windows App SDK 実装です。これは、高品質のテキスト レンダリング、解像度に依存しないアウトライン フォント、および Unicode テキストとレイアウトの完全なサポートのための DirectX API です。 DWriteCore は、DirectWrite の一種であり、Windows 10 バージョン 1809 (10.0; ビルド 17763) までのバージョンで動作し、クロスプラットフォームで使用するための扉を開きます。

機能:

DWriteCore には DirectWrite のすべての機能が含まれていますが、いくつかの例外があります。

重要な制限事項:

  • DWriteCore には、次の DirectWrite 機能は含まれていません。
    • セッションごとのフォント
    • エンドユーザー定義文字 (EUDC) フォント
    • フォント ストリーミング API
  • 低レベルのレンダリング API のサポートは部分的です。
  • DWriteCore は Direct2D と相互運用できませんが、IDWriteGlyphRunAnalysis を使用し、IDWriteBitmapRenderTargetを利用できます。

詳細については、DWriteCore の概要を参照してください。

MRTコア

MRT Core は、Windows App SDK の一部として配布される最新の Windows Resource Management System の合理化されたバージョンです。

重要な制限事項:

  • .NET プロジェクトでは、アプリが既にビルドされている場合、プロジェクト フォルダーに貼り付けたリソース ファイルのインデックスは F5 に作成されません。 回避策として、アプリをリビルドします。 詳細については、問題 1503 参照してください。

  • .NET プロジェクトでは、Visual Studio UI を使用してリソース ファイルがプロジェクトに追加されると、ファイルのインデックスが既定で作成されないことがあります。 詳細については、問題 1786 を参照してください。 この問題を回避するには、CSPROJ ファイル内の以下のエントリを削除してください。

    <ItemGroup>
    <Content Remove="<image file name>" />
</ItemGroup>
<ItemGroup>
    <PRIResource Remove="<resw file name>" />
</ItemGroup>

  • パッケージ化されていない C++ WinUI アプリの場合、リソース URI が正しくビルドされていません。 この問題を回避するには、vcxproj に次を追加します。

    <!-- Add the following after <Import Project="$(VCTargetsPath)\Microsoft.Cpp.props" /> -->

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

詳細については、「MRT Coreを使用したリソースの管理 」を参照してください。

デプロイメント

新機能と更新プログラム:

  • WindowsPackageType project プロパティを使用して Windows アプリ SDK を自動初期化して、Windows App SDK ランタイムを読み込み、Windows App SDK API を呼び出すことができます。 手順については、「 初めての WinUI 3 (Windows App SDK) プロジェクトを作成する」 を参照してください。
  • パッケージ化されていないアプリは、スタンドアロンの Windows App SDK .exe インストーラーを既存の MSI またはセットアップ プログラムに統合することで、Windows App SDK を展開できます。 詳細については、「外部の場所またはパッケージ化されていないでパッケージ化されたフレームワーク依存アプリの Windows App SDK 展開ガイド」を参照してください。
  • パッケージ化されていない .NET アプリでは、ブートストラップ API の .NET ラッパーを使用して、実行時に Windows App SDK フレームワーク パッケージへの依存関係を動的に取得することもできます。 .NET ラッパーの詳細については、.NET ラッパー ライブラリ参照してください。
  • パッケージ 化されたアプリでは、デプロイ API を使用して、必要なすべてのパッケージがマシンにインストールされていることを確認し、確認できます。 デプロイ API のしくみの詳細については、フレームワーク依存のパッケージ アプリWindows App SDK の展開ガイドを参照してください。

重要な制限事項:

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

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

  • CPU ビルド構成をサポートしない: 既存の .NET アプリケーションまたは任意の CPUをサポートするコンポーネントに Windows App SDK を追加 場合は、必要なアーキテクチャ (、、または ) を指定する必要があります。

  • .NET 5 から .NET 6 へのアップグレード: Visual Studio UI でアップグレードすると、ビルド エラーが発生する可能性があります。 回避策として、プロジェクト ファイルの TargetFrameworkPackage を手動で次のように更新します。

      <TargetFramework>net8.0-windows10.0.19041.0</TargetFramework>

  • C++ UWP ツールがインストールされていない場合、C# 単一プロジェクト MSIX アプリはコンパイルされません。 C# 単一プロジェクト MSIX プロジェクトがある場合は、C++ (v14x) ユニバーサル Windows プラットフォーム ツール オプション コンポーネントをインストールする必要があります。

  • Visual Studio 2019 の複数のバージョンがインストールされている場合、後続の言語 VSIX は Visual Studio 2019 へのインストールに失敗します。 Visual Studio 2019 の複数のバージョンがインストールされている場合 (リリースとプレビューなど)、C++ と C# の両方に Windows App SDK VSIX をインストールすると、2 回目のインストールは失敗します。 解決するには、単一プロジェクトの MSIX Packaging Tools for Visual Studio 2019 を最初の言語 VSIX の後にアンインストールします。 この問題 関する追加情報については、このフィードバック をご覧ください。

  • DispatcherQueue.TryEnqueue (ディスパッチャー キュー スレッドでの実行を再開する場合) の代わりに、Windows 実装ライブラリ (WIL)で resume_foreground ヘルパー関数を使用します。

    1. プロジェクトへの参照を Microsoft.Windows.ImplementationLibrary NuGet パッケージに追加します。
    2. #include <wil/cppwinrt_helpers.h>に pch.h を追加します。
    3. #include <winrt/Microsoft.UI.Dispatching.h>に pch.h を追加します。
    4. 今 co_await wil::resume_foreground(your_dispatcherqueue);.