데스크톱 애플리케이션 패키지 준비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(1주년 업데이트라고도 함)에서 처음 도입되었으며, 이 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. 따라서 이러한 애플리케이션은 OS에 포함된 .NET Framework 버전을 사용하여 Windows 10 버전 1607 이상에서 변경 없이 설치하고 실행해야 합니다.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. 앱을 Macirosoft 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.

  • 앱의 모듈은 in-process 방식으로 Windows 앱 패키지에 없는 프로세스에 로드됩니다. .Your app's modules are loaded in-process to processes that are not in your Windows app package. 이것은 허용되지 않습니다. 즉 셸 확장과 같은 in-process 확장은 지원되지 않습니다.This isn't permitted, which means that in-process extensions, like shell extensions, aren't supported. 그렇지만 두 앱이 같은 패키지에 있는 경우 두 앱의 프로세스 간 통신을 수행할 수 있습니다.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.

  • 애플리케이션은 사용자 지정 AUMID(애플리케이션 사용자 모델 ID)를 사용합니다.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.

  • 애플리케이션은 HKLM(HKEY_LOCAL_MACHINE) 레지스트리 하이브를 수정합니다.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. 대신 HKEY_CURRENT_USER(HKCU)에 쓰는 것과 같은 HKLM 사용 목적을 달성할 수 있는 다른 방법을 찾아야 합니다.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. 대신 앱 패키지 매니페스트의 다양 한 Activatable* 확장에 의해 구성된 DelegateExecute 동사 처리기 중 하나를 사용합니다.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. 패키지 내의 프로세스와 확장은 in-process 및 OOP(out-of-process) 방식 모두에서 COM 및 OLE 서버를 등록하고 사용할 수 있습니다.Processes and extensions from within the package can register and use COM & OLE servers, both in-process and out-of-process (OOP). 크리에이터스 업데이트에는 이제 패키지 외부에서 볼 수 있는 OOP COM 및 OLE 서버를 등록하는 기능을 제공하는 패키지된 COM 지원이 추가되었습니다.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.

    패키지된 COM 지원은 기존 COM API에서 작동하지만, 패키지된 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와 같은 interop 시나리오는 외부 프로세스에서 호출되는 경우 작동하지 않습니다.This means interop scenarios like OLE will not function if invoked by external processes.

  • 애플리케이션에서 CRT(C 런타임 라이브러리)를 지원하지 않는 방식으로 연결하고 있습니다.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이 작동하도록 하려면 해당 DLL을 Windows 앱 패키지의 가상 파일 시스템 부분에 포함시켜야 합니다.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. 해당 폴더 안에 SystemX64SystemX86 폴더를 만듭니다.Inside that folder create a SystemX64 and SystemX86 folder. 그런 다음 32비트 버전의 DLL은 SystemX86 폴더에 넣고 64비트 버전은 SystemX64 폴더에 넣습니다.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에서 앱의 일반 정품 버전을 설치하면 스토어에서 앱과 함께 패키지가 설치됩니다.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. 앱의 패키지 매니페스트에서 다음 <PackageDependency> 요소를 <Dependencies> 노드 아래에 추가합니다.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. 또는 package-relative ms-resource URI 스키마(언어, DPI 및 고대비 인식 가능)를 사용하여 문자열 및 이미지 자산을 참조할 수 있는 UWP Windows.UI.StartScreen.JumpList API를 사용하세요.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에 제출된 모든 앱이 Windows 10 S와 호환되어야 하므로 애플리케이션이 Microsoft Store에 제출되지 않을 수 있습니다.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. 이를 수행할 수 있는 한 가지 방법은 앱 서비스를 사용하는 것입니다.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에 제출된 모든 앱이 Windows 10 S와 호환되어야 하므로 애플리케이션이 Microsoft Store에 제출되지 않도록 차단할 수 있습니다.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 10 S용 Windows 앱 테스트를 참조하세요.See Test your Windows app for Windows 10 S.