次の方法で共有

デスクトップ アプリケーションのパッケージ化を準備する

この記事では、デスクトップ アプリケーションをパッケージ化する前に知っておくべきことの一覧を示します。 アプリケーションをパッケージ化プロセスの準備を整えるために多くの作業を行う必要がない場合がありますが、以下のいずれかの項目がアプリケーションに適用される場合は、パッケージ化する前に対処する必要があります。

  • .NET アプリケーションには、4.6.2 より前のバージョンの .NET Framework が必要です。 .NET アプリケーションをパッケージ化する場合は、アプリケーションで .NET Framework 4.6.2 以降をターゲットにすることをお勧めします。 パッケージ化されたデスクトップ アプリケーションをインストールして実行する機能は、Windows 10 バージョン 1607 (Anniversary Update とも呼ばれます) で初めて導入され、この OS バージョンには既定で .NET Framework 4.6.2 が含まれています。 以降の OS バージョンには、.NET Framework の新しいバージョンが含まれます。 以降のバージョンの Windows 10 に含まれる .NET のバージョンの完全な一覧については、 この記事を参照してください。

    パッケージ化されたデスクトップ アプリケーションで 4.6.2 より前のバージョンの .NET Framework を対象とすることは、ほとんどの場合に機能することが期待されます。 ただし、4.6.2 より前のバージョンを対象とする場合は、パッケージ化されたデスクトップ アプリケーションをユーザーに配布する前に完全にテストする必要があります。

    • 4.0 - 4.6.1: これらのバージョンの .NET Framework を対象とするアプリケーションは、4.6.2 以降で問題なく実行される予定です。 そのため、これらのアプリケーションは、OS に含まれている .NET Framework のバージョンを使用して、Windows 10 バージョン 1607 以降で変更を加えずにインストールして実行する必要があります。

    • 2.0 および 3.5: テストでは、これらのバージョンの .NET Framework を対象とするパッケージ化されたデスクトップ アプリケーションは一般的に機能しますが、一部のシナリオではパフォーマンスの問題が発生する可能性があります。 これらのパッケージ化されたアプリケーションをインストールして実行するには、 .NET Framework 3.5 機能 をターゲット コンピューターにインストールする必要があります (この機能には、.NET Framework 2.0 と 3.0 も含まれます)。 また、パッケージ化した後で、これらのアプリケーションを徹底的にテストする必要があります。

  • アプリケーションは常に、昇格されたセキュリティ特権で実行されます。 アプリケーションは、対話型ユーザーとして実行中に動作する必要があります。 アプリケーションをインストールするユーザーはシステム管理者ではない可能性があるため、アプリケーションを管理者特権で実行する必要は、標準ユーザーに対して正しく実行されないことを意味します。 アプリを Microsoft Store に公開する予定がある場合、その機能の一部に昇格を必要とするアプリはストアに受け入れられません。

  • アプリケーションには Windows ドライバーが必要です。 MSIX は Windows ドライバーをサポートしていません。

  • アプリケーションにはユーザー Windows サービスが必要です。 MSIX では、ユーザーごとの Windows サービスはサポートされていません。 MSIX では、定義済みのシステム アカウント (LocalSystem、LocalService、または NetworkService) のいずれかで実行されるセッション 0 (マシンごと) サービスがサポートされます。 ユーザー Windows サービスの代わりに、 バックグラウンド タスクを使用します。

  • アプリのモジュールは、Windows アプリ パッケージに含まれていないプロセスにインプロセスで読み込まれます。 これは許可されていません。つまり、シェル拡張機能などのインプロセス 拡張機能はサポートされていません。 ただし、同じパッケージに 2 つのアプリがある場合は、それらの間でプロセス間通信を行うことができます。

  • アプリケーションによってインストールされた拡張機能が、アプリケーションのインストール先にインストールされていることを確認します。 Windows では、ユーザーと IT マネージャーはパッケージの既定のインストール場所を変更できます。 「Settings->System->Storage->ストレージ設定の詳細-> 新しいコンテンツの保存先を -> New Apps の保存先に変更する」を参照してください。 アプリケーションで拡張機能をインストールする場合は、拡張機能に追加のインストール フォルダー制限がないことを確認します。 たとえば、一部の拡張機能では、システム以外のドライブへの拡張機能のインストールが無効になる場合があります。 既定の場所が変更された場合、エラー 0x80073D01 (ERROR_DEPLOYMENT_BLOCKED_BY_POLICY) が発生します。

  • アプリケーションでは、カスタム アプリケーション ユーザー モデル ID (AUMID) を使用します。 プロセスが SetCurrentProcessExplicitAppUserModelID を呼び出して独自の AUMID を設定する場合は、アプリケーション モデル環境/Windows アプリ パッケージによって生成された AUMID のみを使用できます。 カスタム AUMID は定義できません。

  • アプリケーションによって、HKEY_LOCAL_MACHINE (HKLM) レジストリ ハイブが変更されます。 アプリケーションが HKLM キーを作成しようとしたり、変更のために開いたりしようとすると、アクセス拒否エラーが発生します。 アプリケーションにはレジストリの独自のプライベート仮想化ビューがあるため、ユーザー全体とマシン全体のレジストリ ハイブ (HKLM とは同じ) の概念は適用されないことに注意してください。 代わりに HKEY_CURRENT_USER (HKCU) への書き込みなど、HKLM を使用して達成していたことを実現する別の方法を見つける必要があります。

  • アプリケーションは、別のアプリを起動する手段として ddeexec レジストリ サブキーを使用します。 代わりに、 アプリ パッケージ マニフェストのさまざまな Activatable* 拡張機能によって構成された DelegateExecute 動詞ハンドラーのいずれかを使用します。

  • アプリケーションは、別のアプリとデータを共有することを目的として、AppData フォルダーまたはレジストリに書き込みます。 変換後、AppData は、各アプリのプライベート ストアであるローカル アプリ データ ストアにリダイレクトされます。

    アプリケーションが HKEY_LOCAL_MACHINE レジストリ ハイブに書き込むすべてのエントリは分離されたバイナリ ファイルにリダイレクトされ、アプリケーションが HKEY_CURRENT_USER レジストリ ハイブに書き込むエントリは、ユーザーごとのプライベートのアプリごとの場所に配置されます。 ファイルとレジストリのリダイレクトの詳細については、「 デスクトップ ブリッジの背後にある」を参照してください。

    プロセス間データ共有の別の手段を使用します。 詳細については、「ストアと設定やその他のアプリ データのを取得する」を参照してください。

  • アプリケーションがアプリのインストール ディレクトリに書き込みます。 たとえば、アプリケーションは、exe と同じディレクトリに配置したログ ファイルに書き込みます。 これはサポートされていないため、ローカル アプリ データ ストアなどの別の場所を見つける必要があります。

  • アプリケーションは現在の作業ディレクトリを使用します。 実行時に、パッケージ化されたデスクトップ アプリケーションは、以前にデスクトップで指定したのと同じ作業ディレクトリを取得しません。LNK ショートカット。 アプリケーションが正しく機能するために正しいディレクトリが重要な場合は、実行時に CWD を変更する必要があります。

    注

    アプリがインストール ディレクトリに書き込む必要がある場合、または現在の作業ディレクトリを使用する必要がある場合は、 パッケージ サポート フレームワーク を使用してパッケージにランタイム修正プログラムを追加することも検討できます。 詳細については、こちらの記事を参照してください。

  • アプリケーションのインストールには、ユーザーの操作が必要です。 アプリケーション インストーラーはサイレントモードで実行でき、クリーンな OS イメージに既定ではオンになっていないすべての前提条件をインストールする必要があります。

  • アプリケーションは COM オブジェクトを公開します。 パッケージ内のプロセスと拡張機能は、プロセス内とアウトプロセス (OOP) の両方で、COM および OLE サーバーを登録して使用できます。 Creators Update は、パッケージの外部に表示される OOP COM および OLE サーバーを登録する機能を提供するパッケージ化された COM サポートを追加します。 デスクトップ ブリッジの COM サーバーと OLE ドキュメントのサポートを参照してください。

    パッケージ化された COM のサポートは既存の COM API と連携しますが、パッケージ化された COM の場所がプライベートな場所にあるため、レジストリの直接読み取りに依存するアプリケーション拡張機能では機能しません。

  • アプリケーションは、他のプロセスで使用するために GAC アセンブリを公開します。 アプリケーションは、Windows アプリ パッケージの外部にある実行可能ファイルから生成されたプロセスで使用するために GAC アセンブリを公開できません。 パッケージ内からのプロセスは、通常どおり GAC アセンブリを登録して使用できますが、外部からは表示されません。 つまり、OLE などの相互運用シナリオは、外部プロセスによって呼び出された場合は機能しません。

  • アプリケーションがサポートされていない方法で C ランタイム ライブラリ (CRT) をリンクしています。 Microsoft C/C++ ランタイム ライブラリには、Microsoft Windows オペレーティング システムのプログラミングのためのルーチンが用意されています。 これらのルーチンは、C および C++ 言語によって提供されない多くの一般的なプログラミング タスクを自動化します。 アプリケーションで C/C++ ランタイム ライブラリを利用する場合は、サポートされている方法でリンクされていることを確認する必要があります。

    Visual Studio 2017 では、静的リンクと動的リンクの両方がサポートされており、コードで共通 DLL ファイルまたは静的リンクを使用してライブラリをコードに直接リンクし、現在のバージョンの CRT にリンクできます。 可能であれば、アプリケーションで VS 2017 との動的リンクを使用することをお勧めします。

    以前のバージョンの Visual Studio でのサポートは異なります。 詳しくは、以下の表をご覧ください。

    Visual Studio のバージョン動的リンク静的リンク
    2005 (VC 8)サポートされていませんサポートされています
    2008 (VC 9)サポートされていませんサポートされています
    2010 (VC 10)サポートされていますサポートされています
    2012 (VC 11)サポートされていますサポートされていません
    2013 (VC 12)サポートされていますサポートされていません
    2015 および 2017 (VC 14)サポートされていますサポートされています

    注: いずれの場合も、公開されている最新の CRT にリンクする必要があります。

  • アプリケーションは、Windows のサイド バイ サイド フォルダーからアセンブリをインストールして読み込みます。 たとえば、アプリケーションは C ランタイム ライブラリ VC8 または VC9 を使用し、Windows のサイド バイ サイド フォルダーから動的にリンクしています。つまり、コードは共有フォルダーの共通 DLL ファイルを使用しています。 これはサポートされていません。 コードに再頒布可能なライブラリファイルを直接リンクすることで、静的にリンクする必要があります。

  • アプリケーションでは、System32/SysWOW64 フォルダー内の依存関係を使用します。 これらの DLL を機能させるには、Windows アプリ パッケージの仮想ファイル システム部分に DLL を含める必要があります。 これにより、アプリケーションは、DLL が System32/SysWOW64 フォルダーにインストールされているかのように動作します。 パッケージのルートで、 VFS という名前のフォルダーを作成します。 そのフォルダー内に SystemX64 フォルダーと SystemX86 フォルダーを作成します。 次に、32 ビット バージョンの DLL を SystemX86 フォルダーに配置し、64 ビット バージョンを SystemX64 フォルダーに配置します。

  • アプリは VCLibs フレームワーク パッケージを使用します。 C++ Win32 アプリを変換する場合は、Visual C++ ランタイムのデプロイを処理する必要があります。 Visual Studio 2019 と Windows SDK には、Visual C++ ランタイムのバージョン 11.0、12.0、14.0 の最新のフレームワーク パッケージが次のフォルダーに含まれています。

    • VC 14.0 フレームワーク パッケージ: C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs.Desktop\14.0

    • VC 12.0 フレームワーク パッケージ: C:\Program Files (x86)\Microsoft SDK\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs.Desktop.120\14.0

    • VC 11.0 フレームワーク パッケージ: C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs.Desktop.110\14.0

    これらのパッケージのいずれかを使用するには、パッケージ マニフェストで依存関係としてパッケージを参照する必要があります。 顧客が Microsoft Store からアプリのリテール バージョンをインストールすると、パッケージはアプリと共にストアからインストールされます。 アプリをサイド ロードした場合、依存関係はインストールされません。 依存関係を手動でインストールするには、上記のインストール フォルダーにある x86、x64、または ARM 用の適切な.appx パッケージを使用して、適切なフレームワーク パッケージをインストールする必要があります。

    アプリで Visual C++ ランタイム フレームワーク パッケージを参照するには:

    1. アプリで使用される Visual C++ ランタイムのバージョンについては、上記のフレームワーク パッケージのインストール フォルダーに移動します。

    2. そのフォルダー内の SDKManifest.xml ファイルを開き、(ランタイムのデバッグ バージョンと製品版のどちらを使用しているかに応じて) FrameworkIdentity-Debug 属性または FrameworkIdentity-Retail 属性を見つけて、その属性から Name 値と MinVersion 値をコピーします。 たとえば、現在の VC 14.0 フレームワーク パッケージの FrameworkIdentity-Retail 属性を次に示します。

      FrameworkIdentity-Retail = "Name = Microsoft.VCLibs.140.00.UWPDesktop, MinVersion = 14.0.27323.0, Publisher = 'CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US'"

    3. アプリのパッケージ マニフェストで、<PackageDependency> ノードの下に次の<Dependencies>要素を追加します。 NameとMinVersionの値は、前の手順でコピーした値に置き換えてください。 次の例では、VC 14.0 フレームワーク パッケージの現在のバージョンの依存関係を指定します。

      <PackageDependency Name="Microsoft.VCLibs.140.00.UWPDesktop" MinVersion="14.0.27323.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />

  • アプリケーションにカスタムジャンプリストが含まれています。 ジャンプ リストを使用する場合に注意すべきいくつかの問題と注意事項があります。

    • アプリのアーキテクチャが OS と一致しません。 現在、ジャンプ リストは、アプリケーションと OS アーキテクチャが一致しない場合に正しく機能しません (たとえば、x64 Windows で実行されている x86 アプリケーション)。 現時点では、一致するアーキテクチャにアプリケーションを再コンパイルする以外の回避策はありません。

    • アプリケーションがジャンプ リスト エントリを作成し、ICustomDestinationList::SetAppID または SetCurrentProcessExplicitAppUserModelID を呼び出します。 コードで AppID をプログラムで設定しないでください。 これを行うと、ジャンプ リストのエントリが表示されなくなります。 アプリケーションでカスタム ID が必要な場合は、マニフェスト ファイルを使用して指定します。 手順については、「 デスクトップ アプリケーションを手動でパッケージ化 する」を参照してください。 アプリケーションの AppID は 、YOUR_PRAID_HERE セクションで指定します。

    • アプリケーションによって、パッケージ内の実行可能ファイルを参照するジャンプ リスト シェル リンクが追加されます。 ジャンプ リストからパッケージ内の実行可能ファイルを直接起動することはできません (アプリ独自の .exeの絶対パスを除く)。 代わりに、アプリの実行エイリアス (パッケージ化されたデスクトップ アプリケーションが PATH 上にあるかのようにキーワードを使用して開始できるようにする) を登録し、代わりにリンク ターゲット パスをエイリアスに設定します。 appExecutionAlias 拡張機能の使用方法の詳細については、「 デスクトップ アプリケーションと Windows 10 の統合」を参照してください。 ジャンプ リスト内のリンクのアセットを元の .exeと一致させる必要がある場合は、 SetIconLocation を使用したアイコンや、他のカスタム エントリと同様にPKEY_Title表示名などのアセットを設定する必要があることに注意してください。

    • アプリケーションは、絶対パスでアプリのパッケージ内の資産を参照するジャンプ リスト エントリを追加します。 アプリケーションのインストール パスは、パッケージの更新時に変更され、資産の場所 (アイコン、ドキュメント、実行可能ファイルなど) が変更される可能性があります。 ジャンプ リスト エントリが絶対パスでこのような資産を参照する場合、パスが正しく解決されるように、アプリケーションはジャンプ リストを定期的に更新する必要があります (アプリケーションの起動時など)。 または、代わりに UWP Windows.UI.StartScreen.JumpList API を使用します。これにより、パッケージ相対 ms-resource URI スキーム (言語、DPI、ハイ コントラスト対応) を使用して文字列と画像アセットを参照できます。

  • アプリケーションは、タスクを実行するユーティリティを起動します。 PowerShell や Cmd.exeなどのコマンド ユーティリティを起動しないでください。 ユーザーが Windows 10 S で動作するシステムにあなたのアプリケーションをインストールした場合、そのアプリケーションはまったく起動できません。 これにより、Microsoft Store に送信されるすべてのアプリが Windows 10 S と互換性を持つ必要があるため、アプリケーションが Microsoft Store に提出されるのをブロックする可能性があります。

    ユーティリティを起動すると、多くの場合、オペレーティング システムから情報を取得したり、レジストリにアクセスしたり、システム機能にアクセスしたりするための便利な方法を提供できます。 ただし、代わりに UWP API を使用して、このようなタスクを実行できます。 これらの API は、実行するために別の実行可能ファイルを必要としないため、パフォーマンスが高くなりますが、さらに重要なのは、アプリケーションがパッケージの外部に到達しないようにすることです。 アプリの設計は、パッケージ化したアプリケーションに付属する分離、信頼、セキュリティと一貫性を保ち、Windows 10 S を実行しているシステムでアプリケーションが期待どおりに動作します。

  • アプリケーションは、アドイン、プラグイン、または拡張機能をホストします。 多くの場合、COM スタイルの拡張機能は、拡張機能がパッケージ化されておらず、完全な信頼としてインストールされている限り、引き続き機能します。 これは、これらのインストーラーが完全信頼機能を使用してレジストリを変更し、ホスト アプリケーションで見つかると思われる場所に拡張ファイルを配置できるためです。

    ただし、これらの拡張機能がパッケージ化され、Windows アプリ パッケージとしてインストールされている場合、各パッケージ (ホスト アプリケーションと拡張機能) が互いに分離されるため、機能しません。 アプリケーションをシステムから分離する方法の詳細については、 デスクトップ ブリッジの背後を参照してください。

    ユーザーが Windows 10 S を実行しているシステムにインストールするすべてのアプリケーションと拡張機能は、Windows アプリ パッケージとしてインストールする必要があります。 そのため、拡張機能をパッケージ化する場合、または共同作成者にパッケージ化を促す場合は、ホスト アプリケーション パッケージと拡張機能パッケージ間の通信を容易にする方法を検討してください。 これを行うことができる方法の 1 つは、 App Service を使用することです。

  • アプリケーションによってコードが生成されます。 アプリケーションはメモリ内で使用するコードを生成できますが、Windows アプリ認定プロセスではアプリの送信前にそのコードを検証できないため、生成されたコードをディスクに書き込むのを避けることができます。 また、ディスクにコードを書き込むアプリは、Windows 10 S を実行しているシステムでは正常に動作しません。これにより、Microsoft Store に送信されるすべてのアプリが Windows 10 S と互換性を持つ必要があるため、アプリケーションが Microsoft Store に提出されるのをブロックする可能性があります。

Von Bedeutung

Windows アプリ パッケージを作成したら、アプリケーションをテストして、Windows 10 S を実行するシステムで正しく動作することを確認してください。Microsoft Store に提出されるすべてのアプリは、Windows 10 S と互換性がある必要があります。互換性のないアプリは、ストアでは受け入れられません。 「 Windows 10 S 用の Windows アプリをテストする」を参照してください。

  • Last updated on