デスクトップ アプリケーションのパッケージ化の準備Prepare to package a desktop application

この記事では、デスクトップ アプリケーションをパッケージ化する前に理解しておく必要のある事柄について説明します。This article lists the things you need to know before you package your desktop application. パッケージ化プロセスに向けてアプリケーションを準備するためには多くの作業を行う必要はありませんが、以下の項目のいずれかがアプリケーションに当てはまる場合は、パッケージ化の前に対処する必要があります。You might not have to do much to get your application ready for the packaging process, but if any of the items below apply to your application, you need to address it before packaging.

  • .NET アプリケーションで 4.6.2 より前のバージョンの .NET Framework が必要Your .NET application requires a version of the .NET Framework earlier than 4.6.2. .NET アプリケーションをパッケージ化する場合は、アプリケーションのターゲットを .NET Framework 4.6.2 以降にすることをお勧めします。If you are packaging a .NET application, we recommend that your application target .NET Framework 4.6.2 or later. パッケージ化されたデスクトップ アプリケーションをインストールして実行する機能は、Windows 10 バージョン 1607 (Anniversary Update とも呼ばれます) で初めて導入されました。この OS バージョンには .NET Framework 4.6.2 が既定で含まれています。The ability to install and run packaged desktop applications was first introduced in Windows 10, version 1607 (also called the Anniversary Update), and this OS version includes the .NET Framework 4.6.2 by default. それ以降のバージョンの OS には、新しいバージョンの .NET Framework が含まれています。Later OS versions include later versions of the .NET Framework. 新しいバージョンの Windows 10 に含まれている .NET のバージョンの完全な一覧については、こちらの記事をご覧ください。For a full list of what versions of .NET are included in later versions of Windows 10, see this article.

    パッケージ化されたデスクトップ アプリケーションで 4.6.2 より前のバージョンの .NET Framework をターゲットにしても、ほとんどの場合は機能するはずです。Targeting versions of the .NET Framework earlier than 4.6.2 in packaged desktop applications is expected to work in most cases. ただし、4.6.2 よりも前のバージョンをターゲットにする場合は、パッケージ化されたデスクトップ アプリケーションをユーザーに配布する前に、十分にテストする必要があります。However, if you target an earlier version than 4.6.2, you should fully test your packaged desktop application before distributing it to users.

    • 4.0 - 4.6.1:これらのバージョンの .NET Framework をターゲットとするアプリケーションは、4.6.2 以降で問題なく実行できることが予想されます。4.0 - 4.6.1: Applications that target these versions of the .NET Framework are expected to run without issues on 4.6.2 or later. そのため、これらのアプリケーションは、Windows 10 バージョン 1607 以降とその OS に付属するバージョンの .NET Framework に変更を加えることなく、インストールして実行できるはずです。Therefore, these applications should install and run without changes on Windows 10, version 1607 or later with the version of the .NET Framework that is included with the OS.

    • 2.0 および 3.5:私たちのテストでは、これらのバージョンの .NET Framework をターゲットとするパッケージ化されたデスクトップ アプリケーションは、通常は機能します。ただし、一部のシナリオではパフォーマンス上の問題が発生する可能性があります。2.0 and 3.5: In our testing, packaged desktop applications that target these versions of the .NET Framework generally work but may exhibit performance issues in some scenarios. これらのパッケージ化されたアプリケーションをインストールして実行するには、.NET Framework 3.5 の機能をターゲット コンピューターにインストールする必要があります (この機能には、.NET Framework 2.0 と 3.0 も含まれます)。In order for these packaged applications to install and run, the .NET Framework 3.5 feature must be installed on the target machine (this feature also includes .NET Framework 2.0 and 3.0). また、これらのアプリケーションをパッケージ化した後、十分にテストする必要もあります。You should also test these applications thoroughly after you package them.

  • 常に管理者のセキュリティ特権でアプリケーションを実行するYour application always runs with elevated security privileges. アプリケーションは、対話ユーザーとして実行中にも機能する必要があります。Your application needs to work while running as the interactive user. アプリケーションをインストールするユーザーはシステム管理者ではない可能性があります。そのため、管理者特権でアプリケーションを実行するように求めることは、標準ユーザーでは正しく動作しないことを意味します。Users who install your application may not be system administrators, so requiring your application to run elevated means that it won't run correctly for standard users. Microsoft Store にアプリを発行することを計画している場合、機能の一部で昇格を必要とするアプリは、Store では受け入れられません。If you plan on publishing your app to the Microsoft Store, apps that require elevation for any part of their functionality won't be accepted into the Store.

  • アプリケーションにカーネル モード ドライバーや Windows サービスが必要Your application requires a kernel-mode driver or a Windows service. MSIX では、システム アカウントで実行する必要があるカーネル モード ドライバーや Windows サービスはサポートされていません。MSIX does not support a kernel-mode driver or a Windows service that needs to run under a system account. Windows サービスの代わりに、バックグラウンド タスクを使います。Instead of a Windows service, use a background task.

  • アプリのモジュールが、Windows アプリ パッケージに含まれていないプロセスに読み込まれるインプロセスであるYour app's modules are loaded in-process to processes that are not in your Windows app package. これは許可されていません。つまり、シェルの拡張機能などのインプロセスの拡張機能はサポートされていません。This isn't permitted, which means that in-process extensions, like shell extensions, aren't supported. ただし、同じパッケージに 2 つのアプリが含まれている場合に、そのアプリ間でプロセス間通信することはできます。But if you have two apps in the same package, you can do inter-process communication between them.

  • アプリケーションによってインストールされる拡張機能が、必ずそのアプリケーションのインストール先にインストールされるようにするEnsure that any extensions installed by the application will install where the application is installed. Windows では、ユーザーと IT 管理者がパッケージの既定のインストール場所を変更できます。Windows allows users and IT managers to change the default install location for packages. [設定] > [システム] > [ストレージ] > [その他のストレージ設定] > [新しいコンテンツの保存先を変更する] > [新しいアプリの保存先] を参照してください。See "Settings->System->Storage->More Storage Settings-> Change where new content is saved to -> New Apps will save to". アプリケーションを使用して拡張機能をインストールする場合は、拡張機能にインストール フォルダーの追加の制限がないことを確認してください。If you are installing an extension with your application, make sure that the extension does not have additional installation folder restrictions. たとえば、一部の拡張機能では、システム ドライブ以外への拡張機能のインストールが無効になっている場合があります。For example, some extensions may disable installing their extension to non-system drives. 既定の場所が変更されていた場合、これによりエラー 0x80073D01 (ERROR_DEPLOYMENT_BLOCKED_BY_POLICY) が発生します。This will result in an error 0x80073D01 (ERROR_DEPLOYMENT_BLOCKED_BY_POLICY) if the default location has been changed.

  • アプリケーションでカスタム アプリケーション ユーザー モデル ID (AUMID) を使うYour application uses a custom Application User Model ID (AUMID). プロセスから SetCurrentProcessExplicitAppUserModelID を呼び出して独自の AUMID を設定する場合、そのためにアプリケーション モデル環境/Windows アプリ パッケージによって生成された AUMID しか使えません。If your process calls SetCurrentProcessExplicitAppUserModelID to set its own AUMID, then it may only use the AUMID generated for it by the application model environment/Windows app package. カスタムの AUMID を定義することはできません。You can't define custom AUMIDs.

  • アプリケーションが HKEY_LOCAL_MACHINE (HKLM) レジストリ ハイブを変更するYour application modifies the HKEY_LOCAL_MACHINE (HKLM) registry hive. アプリケーションから HKLM キーを作成しようとしたり、変更のために開こうとしたりすると、アクセス拒否エラーが発生します。Any attempt by your application to create an HKLM key, or to open one for modification, will result in an access-denied failure. アプリケーションには、レジストリを仮想化した独自のプライベート ビューがあることを思い出してください。そのため、ユーザーやマシン全体のレジストリ ハイブ (HKLM はこれに相当) という概念は適用されません。Remember that your application has its own private virtualized view of the registry, so the notion of a user- and machine-wide registry hive (which is what HKLM is) does not apply. HKLM を使って実現していたことを、HKEY_CURRENT_USER (HKCU) に書き込むなど別の方法で実現する必要があります。You will need to find another way of achieving what you were using HKLM for, like writing to HKEY_CURRENT_USER (HKCU) instead.

  • アプリケーションで、別のアプリを起動する手段として ddeexec レジストリ サブキーを使っているYour application uses a ddeexec registry subkey as a means of launching another app. 代わりに、アプリ パッケージ マニフェストのさまざまなアクティブ化可能* な拡張機能で構成する DelegateExecute verb ハンドラーの 1 つを使います。Instead, use one of the DelegateExecute verb handlers as configured by the various Activatable* extensions in your app package manifest.

  • アプリケーションが、別のアプリとデータを共有するために AppData フォルダーまたはレジストリに書き込みを行うYour application writes to the AppData folder or to the registry with the intention of sharing data with another app. 変換後、AppData はローカル アプリ データ ストアにリダイレクトされます。このストアは、各アプリのプライベート ストアです。After conversion, AppData is redirected to the local app data store, which is a private store for each app.

    アプリケーションが HKEY_LOCAL_MACHINE レジストリ ハイブに書き込んだすべてのエントリが、分離されたバイナリ ファイルにリダイレクトされ、アプリケーションが HKEY_CURRENT_USER レジストリ ハイブに書き込んだすべてのエントリが、ユーザーごと、アプリごとのプライベートな場所に配置されます。All entries that your application writes to the HKEY_LOCAL_MACHINE registry hive are redirected to an isolated binary file and any entries that your application writes to the HKEY_CURRENT_USER registry hive are placed into a private per-user, per-app location. ファイルとレジストリのリダイレクトの詳細については、「デスクトップ ブリッジの内側」をご覧ください。For more details about file and registry redirection, see Behind the scenes of the Desktop Bridge.

    プロセス間データ共有に別の方法を使います。Use a different means of inter-process data sharing. 詳しくは、「設定と他のアプリ データを保存して取得する」をご覧ください。For more info, see Store and retrieve settings and other app data.

  • アプリケーションが、アプリのインストール ディレクトリに書き込みを行うYour application writes to the install directory for your app. たとえば、exe と同じディレクトリに置いたログ ファイルにアプリケーションが書き込む場合などです。For example, your application writes to a log file that you put in the same directory as your exe. この書き込みは、サポートされていないため、ローカル アプリ データ ストアなどの別の場所にする必要があります。This isn't supported, so you'll need to find another location, like the local app data store.

  • アプリケーションで現在の作業ディレクトリを使うYour application uses the current working directory. パッケージ化されたデスクトップ アプリケーションでは、実行時に、デスクトップの .LNK ショートカットで以前に指定していたのと同じ作業ディレクトリが取得されません。At runtime, your packaged desktop application won't get the same working directory that you previously specified in your desktop .LNK shortcut. アプリケーションを正しく動作させるために現在のディレクトリを取得することが重要な場合は、実行時に CWD を変更する必要があります。You need to change your CWD at runtime if having the correct directory is important for your application to function correctly.

    注意

    アプリでインストール ディレクトリに書き込んだり、現在の作業ディレクトリを使用したりする必要がある場合は、パッケージに対してパッケージ サポート フレームワークを使用したランタイム修正の追加を検討することもできます。If your app needs to write to the installation directory or use the current working directory, you can also consider adding a runtime fixup using the Package Support Framework to your package. 詳細については、こちらの記事を参照してください。For more details, see this article.

  • アプリケーションのインストールでユーザーの対話式操作を求めるYour application installation requires user interaction. アプリケーションのインストーラーはサイレント実行でき、クリーンな状態の OS イメージには既定では存在しないすべての前提条件をインストールする必要があります。Your application installer must be able to run silently, and it must install all of its prerequisites that aren't on by default on a clean OS image.

  • アプリケーションに UIAccess が必要Your application requires UIAccess. アプリケーションが UAC マニフェストの requestedExecutionLevel 要素で UIAccess=true を指定している場合、現時点では MSIX への変換はサポートされていません。If your application specifies UIAccess=true in the requestedExecutionLevel element of the UAC manifest, conversion to MSIX isn't supported currently. 詳しくは、「UI オートメーション セキュリティの概要」をご覧ください。For more info, see UI Automation Security Overview.

  • アプリケーションで COM オブジェクトを公開するYour application exposes COM objects. パッケージ内のプロセスと拡張機能は、インプロセスとアウト プロセス (OOP) の両方で、COM サーバーおよび OLE サーバーを登録して使用できます。Processes and extensions from within the package can register and use COM & OLE servers, both in-process and out-of-process (OOP). Creators Update では、Packaged COM のサポートが追加されています。これにより、パッケージ外部で表示されるようになった OOP COM サーバーおよび OLE サーバーを登録できるようになります。The Creators Update adds Packaged COM support which provides the ability to register OOP COM & OLE servers that are now visible outside the package. COM サーバーおよび OLE ドキュメントのデスクトップ ブリッジ用サポートに関するブログをご覧ください。See COM Server and OLE Document support for Desktop Bridge.

    Packaged COM のサポートは、既存の COM API に使用できますが、Packaged COM の場所はプライベートであるため、レジストリの読み取りに直接依存するアプリケーションの拡張機能には使用できません。Packaged COM support works with existing COM APIs, but will not work for application extensions that rely upon directly reading the registry, as the location for Packaged COM is in a private location.

  • 他のプロセスで使用できるようにアプリケーションで GAC アセンブリを公開するYour application exposes GAC assemblies for use by other processes. アプリケーションでは、Windows アプリ パッケージ外部の実行可能ファイルから生成されたプロセスで使用できるように GAC アセンブリを公開することはできません。Your application cannot expose GAC assemblies for use by processes originating from executables external to your Windows app package. パッケージ内のプロセスは、通常どおり、GAC アセンブリを登録して使用できますが、外部からは認識されません。Processes from within the package can register and use GAC assemblies as normal, but they will not be visible externally. つまり、OLE などの相互運用機能のシナリオは、外部プロセスによって呼び出された場合、機能しません。This means interop scenarios like OLE will not function if invoked by external processes.

  • アプリケーションが C ランタイム ライブラリ (CRT) をサポートされていない方法でリンクするYour application is linking C runtime libraries (CRT) in an unsupported manner. Microsoft C/C++ ランタイム ライブラリは、Microsoft Windows オペレーティング システムのプログラミングのルーチンを提供します。The Microsoft C/C++ runtime library provides routines for programming for the Microsoft Windows operating system. これらのルーチンは、C および C++ 言語では提供されない、多くの一般的なプログラミング タスクを自動化します。These routines automate many common programming tasks that are not provided by the C and C++ languages. アプリケーションで C/C++ ランタイム ライブラリを使用している場合、サポートされている方法でリンクされることを確認する必要があります。If your application utilizes C/C++ runtime library, you need to ensure it is linked in a supported manner.

    Visual Studio 2017 は、現在のバージョンの CRT に対して、コードで共通の DLL ファイルを使用できるようにするダイナミック リンクと、コードに直接ライブラリをリンクするスタティック リンクの両方をサポートしています。Visual Studio 2017 supports both static and dynamic linking, to let your code use common DLL files, or static linking, to link the library directly into your code, to the current version of the CRT. 可能であれば、アプリケーションで VS 2017 へのダイナミック リンクを使用することをお勧めします。If possible, we recommend your application use dynamic linking with VS 2017.

    以前のバージョンの Visual Studio でのサポートは異なります。Support in previous versions of Visual Studio varies. 詳しくは、次の表をご覧ください。See the following table for details:

    Visual Studio のバージョンVisual Studio versionダイナミック リンクDynamic linkingスタティック リンクStatic linking
    2005 (VC 8)2005 (VC 8)サポートされていません。Not supportedサポートSupported
    2008 (VC 9)2008 (VC 9)サポートされていません。Not supportedサポートSupported
    2010 (VC 10)2010 (VC 10)サポートSupportedサポートSupported
    2012 (VC 11)2012 (VC 11)サポートSupportedサポートされていません。Not supported
    2013 (VC 12)2013 (VC 12)サポートSupportedサポートされていません。Not supported
    2015 および 2017 (VC 14)2015 and 2017 (VC 14)サポートSupportedサポートSupported

    注: いずれの場合も、最新の公開されている CRT にリンクする必要があります。Note: In all cases, you must link to the latest publicly available CRT.

  • アプリケーションが Windows サイドバイサイド フォルダーからアセンブリのインストールや読み込みを行うYour application installs and loads assemblies from the Windows side-by-side folder. たとえば、アプリケーションが C ランタイム ライブラリ VC8 または VC9 を使用しており、それらを Windows サイドバイサイド フォルダーから動的にリンクしている、つまり、コードが共有フォルダーから共通の DLL ファイルを使用しているとします。For example, your application uses C runtime libraries VC8 or VC9 and is dynamically linking them from Windows side-by-side folder, meaning your code is using the common DLL files from a shared folder. これはサポートされていません。This is not supported. 再頒布可能なライブラリ ファイルをコードに直接リンクして、静的にリンクする必要があります。You will need to statically link them by linking to the redistributable library files directly into your code.

  • アプリケーションが、System32/SysWOW64 フォルダーの依存関係を使っているYour application uses a dependency in the System32/SysWOW64 folder. DLL が機能するためには、Windows アプリ パッケージの仮想ファイル システム部分にそれらの DLL を含める必要があります。To get these DLLs to work, you must include them in the virtual file system portion of your Windows app package. これにより、アプリケーションは DLL が System32/SysWOW64 フォルダーにインストールされている場合と同じように動作します。This ensures that the application behaves as if the DLLs were installed in the System32/SysWOW64 folder. パッケージのルートで VFS という名前のフォルダーを作成します。In the root of the package, create a folder called VFS. そのフォルダー内に、SystemX64 フォルダーと SystemX86フォルダーを作成します。Inside that folder create a SystemX64 and SystemX86 folder. SystemX86 フォルダーに DLL の 32 ビット バージョンを格納し、SystemX64 フォルダーに 64 ビット バージョンを格納します。Then, place the 32-bit version of your DLL in the SystemX86 folder, and place the 64-bit version in the SystemX64 folder.

  • アプリが VCLibs フレームワーク パッケージを使っているYour app uses a VCLibs framework package. C++ Win32 アプリを変換する場合は、Visual C++ ランタイムの配置を処理する必要があります。If you are converting a C++ Win32 app, you must handle the deployment of the Visual C++ Runtime. Visual Studio 2019 と Windows SDK では、以下のフォルダーに、Visual C++ ランタイムのバージョン 11.0、12.0、14.0 用の最新のフレームワーク パッケージが含まれています。Visual Studio 2019 and the Windows SDK include the latest framework packages for version 11.0, 12.0 and 14.0 of the Visual C++ Runtime in the following folders:

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

    • VC 12.0 のフレームワーク パッケージ:C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs.Desktop.120\14.0VC 12.0 framework packages: 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.0VC 11.0 framework packages: C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs.Desktop.110\14.0

    これらのパッケージのいずれかを使用するには、パッケージ マニフェストでそのパッケージを依存関係として参照する必要があります。To use one of these packages, you must reference the package as a dependency in your package manifest. 顧客が Microsoft Store から自分のアプリの製品版をインストールすると、アプリと共に Store からパッケージがインストールされます。When customers install the retail version of your app from the Microsoft Store, the package will be installed from the Store along with your app. アプリをサイドロードする場合、依存関係はインストールされません。The dependencies will not get installed if you side load your app. 依存関係を手動でインストールするには、上に示したインストール フォルダーにある、x86、x64、または ARM 用の適切な .appx パッケージを使用して、適切なフレームワーク パッケージをインストールする必要があります。To install the dependencies manually, you must install the appropriate framework package using the appropriate .appx package for x86, x64, or ARM located in the installation folders listed above.

    アプリで Visual C++ ランタイム フレームワーク パッケージを参照するには:To reference a Visual C++ Runtime framework package in your app:

    1. アプリで使用される Visual C++ ランタイムのバージョン用の、上記のフレームワーク パッケージのインストール フォルダーに移動します。Go to the framework package install folder listed above for the version of the Visual C++ Runtime used by your app.

    2. そのフォルダー内の SDKManifest.xml ファイルを開き、FrameworkIdentity-Debug または FrameworkIdentity-Retail 属性 (使用しているのがランタイムのデバッグ バージョンか製品版かによって異なります) を見つけて、NameMinVersion の値をその属性からコピーします。Open the SDKManifest.xml file in that folder, locate the FrameworkIdentity-Debug or FrameworkIdentity-Retail attribute (depending on whether you're using the debug or retail version of the runtime), and copy the Name and MinVersion values from that attribute. たとえば、現在の VC 14.0 フレームワーク パッケージの FrameworkIdentity-Retail 属性を次に示します。For example, here's the FrameworkIdentity-Retail attribute for the current VC 14.0 framework package.

      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> 要素を追加します。In the package manifest for your app, add the following <PackageDependency> element under the <Dependencies> node. NameMinVersion の値は、前の手順でコピーした値に置き換えてください。Make sure you replace the Name and MinVersion values with the values you copied in the previous step. 次の例では、現在のバージョンの VC 14.0 フレームワーク パッケージ用の依存関係を指定します。The following example specifies a dependency for the current version of the VC 14.0 framework package.

      <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" />
      
  • アプリケーションにカスタム ジャンプ リストが含まれるYour application contains a custom jump list. ジャンプ リストを使用する場合は、いくつかの問題と注意事項があります。There are several issues and caveats to be aware of when using jump lists.

    • アプリのアーキテクチャが OS と一致しない。Your app's architecture does not match the OS. 現在、アプリケーションと OS のアーキテクチャが一致しない場合 (x64 Windows で実行されている x86 アプリケーションなど)、ジャンプ リストは正しく機能しません。Jump lists currently do not function correctly if the application and OS architectures do not match (e.g., an x86 application running on x64 Windows). 現時点では、アプリケーションを再コンパイルしてアーキテクチャを一致させる以外に回避策はありません。At this time, there is no workaround other than to recompile your application to the matching architecture.

    • アプリケーションがジャンプ リストの項目を作成して、ICustomDestinationList::SetAppID または SetCurrentProcessExplicitAppUserModelID を呼び出すYour application creates jump list entries and calls ICustomDestinationList::SetAppID or SetCurrentProcessExplicitAppUserModelID. プログラムによって AppID をコードに設定しないでください。Do not programmatically set your AppID in code. そうすると、ジャンプ リストの項目が表示されません。Doing so will cause your jump list entries to not appear. アプリケーションにカスタム ID が必要な場合は、マニフェスト ファイルを使用して指定してください。If your application needs a custom Id, specify it using the manifest file. 手順については、デスクトップ アプリケーションを手動でパッケージ化する方法に関する記事を参照してください。Refer to Package a desktop application manually for instructions. アプリケーションの AppID は YOUR_PRAID_HERE セクションに指定されます。The AppID for your application is specified in the YOUR_PRAID_HERE section.

    • アプリケーションが、パッケージ内の実行可能ファイルを参照するジャンプ リスト シェル リンクを追加するYour application adds a jump list shell link that references an executable in your package. ジャンプ リストから直接、パッケージ内の実行可能ファイルを起動することはできません (アプリ自体の .exe の絶対パスを使用する場合は除く)。You cannot directly launch executables in your package from a jump list (with the exception of the absolute path of an app’s own .exe). 代わりに、アプリの実行エイリアスを登録し (これにより、PATH に指定されているようにキーワードを使ってパッケージ化されたデスクトップ アプリケーションを起動できます)、リンク先のパスをこのエイリアスに設定します。Instead, register an app execution alias (which allows your packaged desktop application to start via a keyword as though it were on the PATH) and set the link target path to the alias instead. appExecutionAlias 拡張機能の使用方法の詳細については、デスクトップ アプリケーションを Windows 10 と統合する方法に関する記事をご覧ください。For details on how to use the appExecutionAlias extension, see Integrate your desktop application with Windows 10. 元の .exe に一致するジャンプ リストのリンク アセットが必要な場合は、他のカスタム項目と同様に、SetIconLocation を使用してアイコンなどのアセットを設定し、PKEY_Title を使用して名前を表示します。Note that if you require assets of the link in jump list to match the original .exe, you will need to set assets such as the icon using SetIconLocation and the display name with PKEY_Title like you would for other custom entries.

    • アプリケーションが、絶体パスを使用して、アプリのパッケージ内のアセットを参照するジャンプ リスト項目を追加するYour application adds a jump list entries that references assets in the app's package by absolute paths. アプリケーションのインストール パスが、そのパッケージの更新時に変更され、アセット (アイコン、ドキュメント、実行可能ファイルなど) の場所が変わる場合があります。The installation path of an application may change when its packages are updated, changing the location of assets (such as icons, documents, executable, and so on). ジャンプ リストの項目が、そのようなアセットを絶対パスで参照している場合、アプリケーションはそのジャンプ リストを定期的に (アプリケーションの起動時など) 更新して、パスが正しく解決されるようにする必要があります。If jump list entries reference such assets by absolute paths, then the application should refresh its jump list periodically (such as on application launch) to ensure paths resolve correctly. または、UWP Windows.UI.StartScreen.JumpList API を使用します。この API では、package-relative ms-resource URI スキーマ (これは言語、DPI、ハイ コントラストにも対応します) を使用して、文字列アセットと画像アセットを参照できます。Alternatively, use the UWP Windows.UI.StartScreen.JumpList APIs instead, which allow you to reference string and image assets using the package-relative ms-resource URI scheme (which is also language, DPI, and high contrast aware).

  • タスクを実行するユーティリティがアプリケーションによって起動されるYour application starts a utility to perform tasks. PowerShell や Cmd.exe など、コマンド ユーティリティの起動は避けてください。Avoid starting command utilities such as PowerShell and Cmd.exe. Windows 10 S を実行するシステムにユーザーがアプリケーションをインストールした場合、アプリケーションではこのようなユーティリティを一切起動できなくなります。In fact, if users install your application onto a system that runs the Windows 10 S, then your application won’t be able to start them at all. これにより、Microsoft Store へのアプリケーションの申請がブロックされる可能性があります。Microsoft Store に申請されるアプリはすべて Windows 10 S に対応している必要があるためです。This could block your application from submission to the Microsoft Store because all apps submitted to the Microsoft Store must be compatible with Windows 10 S.

    ユーティリティの起動は、オペレーティング システムからの情報の取得、レジストリへのアクセス、システム機能へのアクセスなどを行うための手段として便利であることが少なくありません。Starting a utility can often provide a convenient way to obtain information from the operating system, access the registry, or access system capabilities. ただし、このような作業を実行するには、代わりに UWP API を使用することができます。However, you can use UWP APIs to accomplish these sorts of tasks instead. 実行のために個別の実行可能ファイルを必要としないため、これらの API の方が高効率ですが、さらに重要な点は、これらによってアプリケーションからパッケージの外部にアクセスできなくなるということです。Those APIs are more performant because they don’t need a separate executable to run, but more importantly, they keep the application from reaching outside of the package. アプリの設計において、パッケージ化したアプリケーションで提供される分離性、信頼性、およびセキュリティとの一貫性が維持されるため、アプリケーションは Windows 10 S を実行しているシステム上で想定どおりに動作します。The app’s design stays consistent with the isolation, trust, and security that comes with an application that you've packaged, and your application will behave as expected on systems running Windows 10 S.

  • アプリケーションで、アドイン、プラグイン、または拡張機能をホストしているYour application hosts add-ins, plug-ins, or extensions. 多くの場合、COM スタイルの拡張機能は、引き続き動作します。ただし、拡張機能がパッケージ化されておらず、完全信頼としてインストールされている場合に限られます。In many cases, COM-style extensions will likely continue to work as long as the extension has not been packaged, and it installs as full trust. これは、これらのインストーラーでは、完全信頼機能を使用してレジストリを変更し、ホスト アプリケーションで検出できる任意の場所に拡張機能ファイルを配置することが可能であるためです。That's because those installers can use their full-trust capabilities to modify the registry and place extension files wherever your host application expects to find them.

    ただし、これらの拡張機能がパッケージ化され、Windows アプリ パッケージとしてインストールされた場合は、各パッケージ (ホスト アプリケーションと拡張機能) が互いに分離されるため、正しく動作しません。However, if those extensions are packaged, and then installed as a Windows app package, they won't work because each package (the host application and the extension) will be isolated from one another. アプリケーションがシステムから分離されるしくみについて詳しくは、デスクトップ ブリッジの内側に関する記事をご覧ください。To read more about how applications are isolated from the system, see Behind the scenes of the Desktop Bridge.

    Windows 10 S を実行するシステムにユーザーがインストールするすべてのアプリケーションおよび拡張機能は、Windows アプリ パッケージとしてインストールされる必要があります。All applications and extensions that users install to a system running Windows 10 S must be installed as Windows App packages. このため、拡張機能をパッケージ化したり、共同作成者にパッケージ化を奨励したりする予定がある場合は、ホスト アプリケーション パッケージと拡張機能パッケージ間のやり取りをどのように実現するか検討してください。So if you intend to package your extensions, or you plan to encourage your contributors to package them, consider how you might facilitate communication between the host application package and any extension packages. 1 つの方法として、アプリ サービスを使用することもできます。One way that you might be able to do this is by using an app service.

  • アプリケーションでコードが生成されるYour application generates code. アプリケーションは、メモリ内に自分が使用するコードを生成できますが、生成されたコードはディスクに書き込まないでください。このようなコードは、アプリの提出前に Windows アプリ認定プロセスで検証することができないためです。Your application can generate code that it consumes in memory, but avoid writing generated code to disk because the Windows App Certification process can't validate that code prior to app submission. また、Windows 10 S を実行しているシステムでは、ディスクにコードを書き込むアプリは正しく動作しません。これにより、Microsoft Store へのアプリケーションの申請がブロックされる可能性があります。Microsoft Store に申請されるアプリはすべて Windows 10 S に対応している必要があるためです。Also, apps that write code to disk won’t run properly on systems running Windows 10 S. This could block your application from submission to the Microsoft Store because all apps submitted to the Microsoft Store must be compatible with Windows 10 S.

重要

Windows アプリ パッケージを作成したら、アプリケーションをテストして Windows 10 S を実行するシステム上で正常に動作することを確認してください。Microsoft Store に提出するすべてのアプリは、Windows 10 S に対応している必要があります。互換性のないアプリはストアに受け入れられません。After you've created your Windows app package, please test your application to ensure that it works correctly on systems that run Windows 10 S. All apps submitted to the Microsoft Store must be compatible with Windows 10 S. Apps that aren't compatible won't be accepted in the store. Windows アプリの Windows 10 S 対応をテストする」をご覧ください。See Test your Windows app for Windows 10 S.