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

  • [アーティクル]

この記事では、デスクトップ アプリケーションをパッケージ化する前に理解しておく必要のある事柄について説明します。 パッケージ化プロセスに向けてアプリケーションを準備するためには多くの作業を行う必要はありませんが、以下の項目のいずれかがアプリケーションに当てはまる場合は、パッケージ化の前に対処する必要があります。

  • .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 以降で問題なく実行できることが予想されます。 そのため、これらのアプリケーションは、Windows 10 バージョン 1607 以降とその OS に付属するバージョンの .NET Framework に変更を加えることなく、インストールして実行できるはずです。

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

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

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

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

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

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

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

  • アプリケーションが HKEY_LOCAL_MACHINE (HKLM) レジストリ ハイブを変更する。 アプリケーションから HKLM キーを作成しようとしたり、変更のために開こうとしたりすると、アクセス拒否エラーが発生します。 アプリケーションには、レジストリを仮想化した独自のプライベート ビューがあることを思い出してください。そのため、ユーザーやマシン全体のレジストリ ハイブ (HKLM はこれに相当) という概念は適用されません。 HKLM を使って実現していたことを、HKEY_CURRENT_USER (HKCU) に書き込むなど、別の方法で実現する必要があります。

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

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

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

    プロセス間データ共有に別の方法を使います。 詳しくは、「設定と他のアプリ データを保存して取得する」をご覧ください。

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

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

    Note

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

  • アプリケーションのインストールでユーザーの対話式操作を求める。 アプリケーションのインストーラーはサイレント実行でき、クリーンな状態の OS イメージには既定では存在しないすべての前提条件をインストールする必要があります。

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

    Packaged COM のサポートは既存の COM API に使用できますが、Packaged COM の場所はプライベートであるため、レジストリの直接読み取りに依存するアプリケーションの拡張機能には使用できません。

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

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

    Visual Studio 2017 は、現在のバージョンの CRT に対して、コードで共通の DLL ファイルを使用できるようにするダイナミック リンクと、コードに直接ライブラリをリンクするスタティックリンクの両方をサポートしています。 可能であれば、アプリケーションで 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 フォルダーを作成します。 SystemX86 フォルダーには 32 ビット バージョンの DLL を配置し、SystemX64 フォルダーには 64 ビット バージョンのDLL を配置します。

  • アプリが 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.110\14.0

    • VC 12.0 のフレームワーク パッケージ: C:\Program Files (x86)\Microsoft SDKs\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 から自分のアプリの製品版をインストールすると、アプリと共に 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. アプリのパッケージ マニフェストで、<Dependencies> ノードの下に次の <PackageDependency> 要素を追加します。 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 を使用します。この API では、package-relative ms-resource URI スキーム (言語、DPI、ハイ コントラストにも対応) を使用して文字列アセットと画像アセットを参照できます。

  • タスクを実行するユーティリティがアプリケーションによって起動される。 PowerShell や Cmd.exe など、コマンド ユーティリティの起動は避けてください。 Windows 10 S を実行するシステムにユーザーがアプリケーションをインストールした場合、アプリケーションではこのようなユーティリティを一切起動できなくなります。 これにより、Microsoft Store へのアプリケーションの申請がブロックされる可能性があります。Microsoft Store に申請されるアプリはすべて Windows 10 S に対応している必要があるためです。

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

  • アプリケーションで、アドイン、プラグイン、または拡張機能をホストしている。 多くの場合、COM スタイルの拡張機能は動作し続けます。ただし、拡張機能がパッケージ化されておらず、完全信頼機能としてインストールされている場合に限られます。 これは、これらのインストーラーでは、完全信頼機能を使用してレジストリを変更し、ホスト アプリケーションで検出できる任意の場所に拡張機能ファイルを配置することが可能であるためです。

    ただし、これらの拡張機能がパッケージ化され、Windows アプリ パッケージとしてインストールされた場合は、各パッケージ (ホスト アプリケーションと拡張機能) が互いに分離されるため、正しく動作しません。 アプリケーションがシステムから分離されるしくみについて詳しくは、デスクトップ ブリッジの内側に関する記事をご覧ください。

    Windows 10 S を実行するシステムにユーザーがインストールするすべてのアプリケーションと拡張機能は、Windows アプリ パッケージとしてインストールされる必要があります。 このため、拡張機能をパッケージ化したり、共同作成者にパッケージ化を奨励したりする予定がある場合は、ホスト アプリケーション パッケージと拡張機能パッケージ間のやり取りをどのように実現するか検討してください。 1 つの方法として、アプリ サービスの使用が挙げられます。

  • アプリケーションでコードが生成される。 アプリケーションは、アプリケーション自体が使用するコードをメモリ内に生成できますが、生成されたコードをディスクに書き込むことは避けてください。このようなコードは、アプリの申請前に Windows アプリ認定プロセスで検証できないためです。 また、Windows 10 S を実行しているシステムでは、ディスクにコードを書き込むアプリは正しく動作しません。これにより、Microsoft Store へのアプリケーションの申請がブロックされる可能性があります。Microsoft Store に申請されるアプリはすべて Windows 10 S に対応している必要があるためです。

重要

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