アプリのパッケージ化の準備 (デスクトップ ブリッジ)

この記事では、デスクトップ アプリをパッケージ化する前に理解しておく必要のあることについて説明します。 パッケージ化プロセス用にアプリを準備するためには多くの作業を行う必要はありませんが、以下の項目のいずれかがアプリケーションに当てはまる場合には、パッケージ化の前に対処する必要があります。 ライセンスと自動更新は Windows ストアで処理されるため、これらのタスクに関連した機能はコードベースから削除できます。

  • アプリでバージョン 4.6.1 よりも前のバージョンの .NET を使用している。 .NET 4.6.1 のみがサポートされています。 パッケージ化する前に、アプリのターゲットを .NET 4.6.1に変更する必要があります。

  • 常に管理者特権のセキュリティ権限でアプリを実行する。 アプリは、対話ユーザーとして実行中にも機能する必要があります。 Windows ストアからアプリをインストールするユーザーはシステム管理者ではない可能性があります。そのため、アプリは、標準ユーザーでは正しく動作しない、管理者だけが実行できる方法で実行する必要があります。

  • アプリにカーネル モード ドライバーや Windows サービスが必要。 ブリッジはアプリには適していますが、システム アカウントで実行する必要があるカーネル モード ドライバーや Windows サービスはサポートしていません。 Windows サービスの代わりに、バックグラウンド タスクを使います。

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

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

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

  • アプリで、別のアプリを起動する手段として ddeexec レジストリ サブキーを使っている。 代わりに、アプリ パッケージ マニフェストのさまざまなアクティブ化可能* な拡張機能で構成する DelegateExecute verb ハンドラーの 1 つを使います。

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

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

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

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

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

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

  • アプリで UIAccess が必要。 アプリケーションが UAC マニフェストの requestedExecutionLevel 要素で UIAccess=true を指定している場合の UWP への変換は現在サポートされていません。 詳しくは、「UI オートメーション セキュリティの概要」をご覧ください。

  • COM オブジェクトをアプリで公開している。 パッケージ内のプロセスと拡張機能は、インプロセスとアウト プロセス (OOP) の両方で、COM サーバーおよび OLE サーバーを登録して使用できます。 Creators Update では、Packaged COM のサポートが追加されています。これにより、パッケージ外部で表示されるようになった OOP COM サーバーおよび OLE サーバーを登録できるようになります。 COM サーバーおよび 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 2015 は、現在のバージョンの CRT に対して、コードで共通の DLL ファイルを使用できるようにするダイナミック リンクと、コードに直接ライブラリをリンクするスタティック リンクの両方をサポートしています。 可能であれば、アプリで VS 2015 へのダイナミック リンクを使用することをお勧めします。

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

    Visual Studio のバージョンダイナミック リンクスタティック リンク
    2005 (VC 8)サポートされないサポートされる
    2008 (VC 9)サポートされないサポートされる
    2010 (VC 10)サポートされるサポートされる
    2012 (VC 11)サポートされるサポートされない
    2013 (VC 12)サポートされるサポートされない
    2015 (VC 14)サポートされるサポートされる

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

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

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

  • アプリが Dev11 VCLibs フレームワーク パッケージを使っている。 VCLibs 11 ライブラリは、Windows アプリ パッケージで依存関係として定義されている場合、Windows ストアから直接インストールできます。 これを行うには、<Dependencies> ノードの下に、以下を追加して変更する必要があります。
    <PackageDependency Name="Microsoft.VCLibs.110.00.UWPDesktop" MinVersion="11.0.24217.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
    Windows ストアからインストールするとき、アプリをインストールする前に VCLibs 11 フレームワークの適切なバージョン (x86 または x64) がインストールされます。
    アプリがサイドローディングによってインストールされる場合は、依存関係がインストールされません。 コンピューター上に依存関係を手動でインストールするには、VC 11.0 Desktop Bridge 用フレームワーク パッケージをダウンロードしてインストールする必要があります。 これらのシナリオについて詳しくは、「Using Visual C++ Runtime in Centennial project (Centennial プロジェクトで Visual C++ ラインタイムを使用する)」をご覧ください。

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

    • アプリのアーキテクチャが 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 を実行するシステムにユーザーが対象アプリをインストールした場合、アプリではこのようなユーティリティを一切起動できません。 Windows ストアへのアプリの申請がブロックされる可能性があります。これは、Windows ストアに申請されるすべてのアプリが Windows 10 S に対応している必要があるためです。

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

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

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

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

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

  • アプリが MAPI API を使用している。 現在、Outlook MAPI API はデスクトップ ブリッジ アプリでサポートされていません。

次のステップ

デスクトップ アプリの Windows アプリ パッケージを作成する

Windows アプリ パッケージを作成する」をご覧ください。

特定の質問に対する回答を見つける

マイクロソフトのチームでは、StackOverflow タグをチェックしています。

この記事に関するフィードバックを送信する

下のコメント セクションをご利用ください。