次の方法で共有

Windows アプリ SDK 1.0 の安定版チャネル リリース ノート

  • [アーティクル]

安定チャネルでは、運用環境のアプリによる使用がサポートされている Windows App SDK のリリースが提供されます。 Windows App SDK の安定リリースが使用されるアプリは、Microsoft Store に発行することもできます。

重要なリンク:

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

Windows App SDK 用のダウンロード

Note

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

バージョン 1.0.4

これは、1.0 リリースの重大なバグの修正が含まれている Windows App SDK のサービス リリースです。

バグ修正 (1.0.4)

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

バージョン 1.0.3

これは、1.0 リリースの重大なバグの修正が含まれている Windows App SDK のサービス リリースです。

バグ修正 (1.0.3)

  • C/C++ ランタイム (CRT) がインストールされていない場合に、WebView2 を使った C# アプリが起動時にクラッシュする問題を修正しました。
  • キーボード ショートカットやその他のシナリオで問題が発生するタッチ入力の問題を修正しました。 詳細については、GitHub の issue 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 の issue 6218 を参照してください。
  • C/C++ ランタイム (CRT) がインストールされていない場合に C# アプリが起動時にクラッシュする問題を修正しました。 ただし、WebView2 を使う C# アプリには、CRT が引き続き必要です。 詳細については、GitHub の issue 2117 を参照してください。
  • 単一プロジェクトの MSIX を使ったアプリケーションで .appinstaller ファイルが生成されない問題を修正しました。 詳細については、GitHub の issue 1821 を参照してください。
  • WinUI アプリケーションが .NET 6 dotnet build をサポートしない問題を修正しました。

Version 1.0.1

これは、1.0 リリースの重大なバグの修正と複数ウィンドウのサポートが含まれている Windows App SDK のサービス リリースです。

バグ修正 (1.0.1)

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

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

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

新機能

WinUI 3 アプリケーションの同一スレッド上で複数のウィンドウを作成する機能の安定化に取り組み、使用できるようになりました。 詳細については、issue 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 アプリ SDK) プロジェクトを作成する」を参照してください。
  • WinUI 3 プロジェクトでは、ターゲット バージョンを Windows 10 バージョン 1809 に下げて設定できるようになりました。 以前は、バージョン 1903 までしか設定できませんでした。
  • アプリ内ツールバーで、WinUI パッケージ アプリ用のホット リロードおよびライブ ビジュアル ツリーが Visual Studio 2022 プレビュー 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 の両方で、空のアプリ、パッケージ (デスクトップの WinUI 3) プロジェクト テンプレートを使用して単一プロジェクト MSIX で新しいアプリを作成する場合、Visual Studio を閉じて再度開くまで、プロジェクトを発行するコマンドがメニューに表示されません。
    • 単一プロジェクト MSIX を含む C# アプリは、"C++ (v14x) ユニバーサル Windows プラットフォーム ツール" オプション コンポーネントがインストールされないとコンパイルされません。 その他の情報については、「Windows App SDK のインストール ツール」を参照してください。
    • 参照される Windows ランタイム コンポーネントで定義されている型を使用する、単一プロジェクト MSIX を含むアプリでの潜在的な実行時エラー: 解決するには、アクティブ化可能なクラスのエントリを appxmanifest.xml に手動で追加します。
      • C# アプリケーションで予期されるエラーは、"COMException: クラスが登録されていません (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 であることを確認します。
    • NuGet パッケージを作成するために、Pack コマンドは 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 により、開発者は、表示トポロジでの変更を観察し、システムで現在定義されている DisplayArea を列挙することができます。

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

入力

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

新機能:

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

重要な制限事項:

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

アプリのライフサイクル

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

重要

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

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

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

重要な考慮事項:

  • リッチ アクティベーション: GetActivatedEventArgs

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

  • 単一または複数のインスタンス化

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

  • 電源/状態通知

既知の問題:

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

DWriteCore

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

機能：

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

重要な制限事項:

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

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

MRT Core

MRT Core は、Windows アプリ SDK の一部として配布される最新の Windows リソース管理システムの簡素化されたバージョンです。

重要な制限事項:

  • .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 を使用してリソースを管理する」を参照してください。

展開

新機能と機能の更新:

重要な制限事項:

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

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

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

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

      <TargetFramework>net6.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 の複数のバージョンがインストールされている場合 (たとえば、Release と Preview)、C++ および C# の両方に対して Windows アプリ SDK VSIX をインストールすると、2 番目のインストールは失敗します。 解決するには、1 つ目の言語 VSIX の後に Visual Studio 2019 用の単一プロジェクト MSIX パッケージング ツールをアンインストールします。 この問題の詳細については、このフィードバックを参照してください。

  • DispatcherQueue.TryEnqueue (ディスパッチャー キュー スレッドで実行を再開するため) の代わりの手段は、Windows Implementation Library (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); を指定します。