Поделиться через


Подготовьте упаковку настольного приложения

В этой статье перечислены сведения, которые необходимо знать, прежде чем упаковать настольное приложение. Возможно, вам не придется многое сделать, чтобы приложение было готово к процессу упаковки, но если любой из указанных ниже элементов применяется к приложению, перед упаковкой его необходимо решить.

  • Для приложения .NET требуется версия .NET Framework ранее 4.6.2. Если вы упаковывают приложение .NET, рекомендуется использовать .NET Framework 4.6.2 или более поздней версии. Возможность установки и запуска упакованных классических приложений была впервые представлена в Windows 10 версии 1607 (также называемой юбилейным обновлением), и эта версия ОС включает .NET Framework 4.6.2 по умолчанию. Более поздние версии ОС включают более поздние версии .NET Framework. Полный список версий .NET, включенных в более поздние версии Windows 10, см. в этой статье.

    Ожидается, что в большинстве случаев использование версий платформы .NET Framework ранее 4.6.2 в упакованных настольных приложениях будет работать. Однако если вы нацелены на более раннюю версию, чем 4.6.2, необходимо полностью протестировать упакованое классическое приложение, прежде чем распространять его пользователям.

    • 4.0 — 4.6.1. Приложения, предназначенные для этих версий .NET Framework, должны выполняться без проблем в версии 4.6.2 или более поздней версии. Поэтому эти приложения должны устанавливать и запускаться без изменений в Windows 10 версии 1607 или более поздней версии с версией .NET Framework, которая входит в состав ОС.

    • 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 поддерживает службы session-0 — на уровне компьютера, работающие под одной из определенных системных учетных записей (LocalSystem, LocalService или NetworkService). Вместо пользовательской службы Windows используйте фоновую задачу.

  • Модули вашего приложения загружаются в процессы, отличные от тех, что находятся в пакете приложений Windows. Это не допускается, что означает, что расширения внутри процесса, такие как расширения оболочки, не поддерживаются. Но если у вас есть два приложения в одном пакете, вы можете выполнять межпроцессное взаимодействие между ними.

  • Убедитесь, что все расширения, установленные приложением, установят место установки приложения. Windows позволяет пользователям и ИТ-менеджерам изменять расположение установки по умолчанию для пакетов. См. раздел "Параметры->Система->Хранилище->Дополнительные параметры хранилища-> Изменить место сохранения нового содержимого -> Новые приложения будут сохраняться в". Если вы устанавливаете расширение с приложением, убедитесь, что расширение не имеет дополнительных ограничений на папку установки. Например, некоторые расширения могут отключить установку расширения на несистемные диски. Это приведет к ошибке 0x80073D01 (ERROR_DEPLOYMENT_BLOCKED_BY_POLICY), если расположение по умолчанию было изменено.

  • Приложение использует пользовательский идентификатор пользовательской модели приложения (AUMID). Если процесс вызывает SetCurrentProcessExplicitAppUserModelID для задания собственного AUMID, он может использовать только AUMID, созданный для него с помощью среды модели приложения или пакета приложения Windows. Нельзя задать пользовательские идентификаторы AUMID.

  • Ваше приложение изменяет ветвь реестра HKEY_LOCAL_MACHINE (HKLM). Любая попытка приложения создать ключ HKLM или открыть его для изменения приведет к сбою доступа. Помните, что приложение имеет собственное частное виртуализированное представление реестра, поэтому понятие куста реестра на уровне пользователя и компьютера (что такое HKLM) не применяется. Вам нужно будет найти другой способ достижения того, для чего вы использовали HKLM, например, записывать в HKEY_CURRENT_USER (HKCU) вместо этого.

  • Ваше приложение использует подраздел реестра ddeexec для запуска другого приложения. Вместо этого используйте один из обработчиков команд DelegateExecute, настроенных различными расширениями Activeable* в манифесте пакета приложения.

  • Приложение записывает данные в папку AppData или в реестр с намерением совместного использования данных с другим приложением. После преобразования AppData перенаправляется в локальное хранилище данных приложения, которое является частным хранилищем для каждого приложения.

    Все записи, записываемые вашим приложением в куст реестра HKEY_LOCAL_MACHINE, перенаправляются в отдельный двоичный файл, а все записи, записываемые вашим приложением в куст реестра HKEY_CURRENT_USER, помещаются в частное расположение для каждого пользователя и приложения. Дополнительные сведения о перенаправлении файлов и реестра см. в разделе "За кулисами" моста для настольных компьютеров.

    Используйте разные средства обмена данными между процессами. Дополнительные сведения см. в разделе сохранение и получение настроек и других данных приложения.

  • Ваше приложение записывает в каталог, в который оно установлено. Например, приложение записывает в файл журнала, который вы помещаете в тот же каталог, что и exe. Это не поддерживается, поэтому вам потребуется найти другое расположение, например локальное хранилище данных приложения.

  • Приложение использует текущий рабочий каталог. Во время выполнения ваше упакованное настольное приложение не получит тот же рабочий каталог, который был ранее указан в ярлыке .LNK. Необходимо изменить CWD во время выполнения, если для правильной работы приложения важно иметь правильный каталог.

    Замечание

    Если вашему приложению необходимо записать данные в каталог установки или использовать текущий рабочий каталог, вы также можете добавить исправление для среды выполнения с помощью Платформы Поддержки Пакетов в ваш пакет. Дополнительные сведения см. в этой статье.

  • Для установки приложения требуется взаимодействие с пользователем. Установщик приложения должен работать автоматически, и он должен установить все необходимые компоненты, которые не установлены по умолчанию на чистом образе ОС.

  • Приложение предоставляет COM-объекты. Процессы и расширения из пакета могут регистрировать и использовать серверы COM и OLE, как внутрипроцессные, так и внепроцессные (OOP). Обновление Creators Update добавляет пакетную поддержку COM, которая обеспечивает возможность регистрации серверов OOP COM и OLE, которые теперь видны за пределами пакета. См. поддержку COM-сервера и OLE Document для Desktop Bridge.

    Пакетная поддержка COM работает с существующими COM API, но не будет работать для расширений приложений, которые полагаются на прямое чтение реестра, поскольку Packaged COM находится в приватном месте.

  • Приложение предоставляет сборки GAC для использования другими процессами. Приложение не может предоставлять сборки GAC для использования процессами, исходящими из исполняемых файлов вне пакета приложения Windows. Процессы из пакета могут регистрировать и использовать сборки 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 были установлены в папке System32/SysWOW64 . В корне пакета создайте папку с именем VFS. В этой папке создайте папку SystemX64 и SystemX86 . Затем поместите 32-разрядную версию библиотеки DLL в папку SystemX86 и поместите 64-разрядную версию в папку SystemX64 .

  • Приложение использует пакет платформы VCLibs. Если вы конвертируете приложение C++ Win32, вы должны обработать развертывание среды выполнения Visual C++. Visual Studio 2019 и пакет SDK для Windows включают последние пакеты платформы для версии 11.0, 12.0 и 14.0 среды выполнения Visual C++ в следующих папках:

    • Пакеты платформы VC 14.0: C:\Program Files (x86)\Microsoft SDK\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 SDK\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs.Desktop.110\14.0

    Чтобы использовать один из этих пакетов, необходимо ссылаться на пакет как зависимость в манифесте пакета. Когда клиенты устанавливают розничную версию приложения из Microsoft Store, пакет будет установлен из Магазина вместе с приложением. Зависимости не будут установлены, если вы загружаете приложение на стороне. Чтобы установить зависимости вручную, необходимо установить соответствующий пакет платформы с помощью соответствующего пакета .appx для x86, x64 или ARM, расположенных в папках установки, перечисленных выше.

    Чтобы ссылаться на пакет платформы среды выполнения Visual C++ в приложении:

    1. Перейдите в папку установки пакета платформы, указанную выше, для версии среды выполнения Visual C++, используемой приложением.

    2. Откройте файл SDKManifest.xml в этой папке, найдите FrameworkIdentity-Debug или FrameworkIdentity-Retail атрибут (в зависимости от того, используете ли вы отладочную или розничную версию среды выполнения) и скопируйте Name значения MinVersion из этого атрибута. Например, вот FrameworkIdentity-Retail атрибут для текущего пакета платформы VC 14.0.

      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" />
      
  • Приложение содержит настраиваемый список переходов. Существует ряд проблем и предостережений, которые следует учитывать при использовании списков переходов.

    • Архитектура вашего приложения не соответствует ОС. Списки переходов в настоящее время не работают правильно, если архитектуры приложений и ОС не соответствуют (например, приложению x86, работающему в Windows x64). В настоящее время не существует обходного решения, кроме повторной компиляции приложения в соответствующую архитектуру.

    • Приложение создает записи списка переходов и вызывает ICustomDestinationList::SetAppID или SetCurrentProcessExplicitAppUserModelID. Не устанавливайте идентификатор приложения программным способом в коде. Это приведет к тому, что записи в списке переходов не будут отображаться. Если приложению требуется пользовательский идентификатор, укажите его с помощью файла манифеста. Инструкции см. в статье "Упаковка классического десктопного приложения вручную". Идентификатор приложения указывается в разделе YOUR_PRAID_HERE .

    • Ваше приложение добавляет ссылку оболочки в список переходов, которая ссылается на исполняемый файл в вашем пакете. Вы не можете напрямую запускать исполняемые файлы в пакете из списка переходов (за исключением абсолютного пути собственного .exeприложения). Вместо этого зарегистрируйте псевдоним запуска приложения (который позволяет упакованному приложению для рабочего стола начинать через ключевое слово, как если бы он был в переменной PATH) и задайте целевой путь ссылки на псевдоним. Дополнительные сведения об использовании расширения appExecutionAlias см. в статье Интеграция классического приложения с Windows 10. Обратите внимание, что если требуется, чтобы ресурсы ссылки в списке переходов соответствовали исходному .exe, необходимо задать такие ресурсы, как значок с помощью SetIconLocation и отображаемое имя с PKEY_Title, как и для других пользовательских записей.

    • Ваше приложение добавляет элементы списка переходов, которые ссылаются на ресурсы в пакете приложения с помощью абсолютных путей. Путь установки приложения может измениться при обновлении пакетов, изменении расположения ресурсов (таких как значки, документы, исполняемый файл и т. д.). Если записи списка переходов ссылаются на такие ресурсы по абсолютным путям, приложение должно периодически обновлять свой список переходов (например, при запуске приложения), чтобы обеспечить правильность разрешения путей. В качестве альтернативы используйте API UWP Windows.UI.StartScreen.JumpList, позволяющие ссылаться на строковые и графические ресурсы с помощью схемы ms-resource URI, связанной с пакетом (которая поддерживает языковые настройки, DPI и высокий контраст).

  • Приложение запускает служебную программу для выполнения задач. Избегайте запуска служебных программ команд, таких как PowerShell и Cmd.exe. На самом деле, если пользователи устанавливают приложение в систему под управлением Windows 10 S, приложение не сможет запускать их вообще. Это может заблокировать отправку приложения в Microsoft Store, так как все приложения, отправленные в Microsoft Store, должны быть совместимы с Windows 10 S.

    Запуск служебной программы часто может предоставить удобный способ получения информации из операционной системы, доступа к реестру или доступа к системным возможностям. Однако для выполнения таких задач можно использовать API UWP. Эти API являются более производительными, так как им не нужен отдельный исполняемый файл для выполнения, но, что более важно, они не позволяют приложению достичь вне пакета. Дизайн приложения остается в соответствии с изоляцией, доверием и безопасностью, которая поставляется с приложением, которое вы упаковали, и ваше приложение будет вести себя должным образом в системах под управлением Windows 10 S.

  • Приложение размещает надстройки, подключаемые модули или расширения. Во многих случаях расширения в стиле COM, скорее всего, будут продолжать работать до тех пор, пока расширение не будет упаковано и установлено с полным доверием. Это связано с тем, что эти установщики могут использовать свои возможности полного доверия для изменения реестра и размещения файлов расширений в любом месте, где ваше хост-приложение ожидает их найти.

    Однако если эти расширения упаковываются, а затем устанавливаются в качестве пакета приложений Windows, они не будут работать, так как каждый пакет (хост-приложение и расширение) будут изолированы друг от друга. Дополнительные сведения о том, как приложения изолированы от системы, см. в разделе "Behind the Scenes of the Desktop Bridge".

    Все приложения и расширения, устанавливаемые пользователями в систему под управлением Windows 10 S, должны быть установлены в виде пакетов приложений Windows. Таким образом, если вы планируете упаковать расширения или планируете поощрять участников упаковать их, рассмотрите возможность упрощения взаимодействия между пакетом ведущего приложения и любыми пакетами расширений. Одним из способов этого может быть использование службы приложений.

  • Приложение создает код. Приложение может создавать код, который он использует в памяти, но не записывать созданный код на диск, так как процесс сертификации приложений Windows не может проверить этот код до отправки приложения. Кроме того, приложения, которые записывают код на диск, не будут работать должным образом в системах под управлением Windows 10 S. Это может заблокировать отправку приложения в Microsoft Store, так как все приложения, отправленные в Microsoft Store, должны быть совместимы с Windows 10 S.

Это важно

После создания пакета приложений Windows проверьте приложение, чтобы убедиться, что оно работает правильно в системах под управлением Windows 10 S. Все приложения, отправленные в Microsoft Store, должны быть совместимы с приложениями Windows 10 S. Приложения, которые несовместимы, не будут приниматься в магазине. См. статью "Тестирование приложения Windows для Windows 10 S".