Przygotuj się do spakowania aplikacji na pulpit

W tym artykule wymieniono rzeczy, które musisz wiedzieć, zanim spakujesz swoją aplikację desktopową. Może nie być konieczne przygotowanie aplikacji do procesu pakowania, ale jeśli którykolwiek z poniższych elementów ma zastosowanie do aplikacji, musisz rozwiązać ten problem przed opakowaniem.

• Aplikacja .NET wymaga wersji programu .NET Framework starszej niż 4.6.2. Jeśli pakujesz aplikację .NET, zalecamy, aby aplikacja była skonfigurowana tak, aby korzystać z .NET Framework 4.6.2 lub nowszej wersji. Możliwość instalowania i uruchamiania spakowanych aplikacji klasycznych została po raz pierwszy wprowadzona w systemie Windows 10 w wersji 1607 (nazywanej również aktualizacją rocznicową), a ta wersja systemu operacyjnego domyślnie zawiera program .NET Framework 4.6.2. Nowsze wersje systemu operacyjnego obejmują nowsze wersje programu .NET Framework. Aby uzyskać pełną listę wersji platformy .NET zawartych w nowszych wersjach systemu Windows 10, zobacz ten artykuł.

  Celowanie w wersje .NET Framework starsze niż 4.6.2 w pakietach aplikacji desktopowych powinno działać w większości przypadków. Jeśli jednak celem jest wersja wcześniejsza niż 4.6.2, należy w pełni przetestować spakowaną aplikację komputerową przed jej dystrybucją do użytkowników.

  • 4.0 — 4.6.1: Aplikacje przeznaczone dla tych wersji programu .NET Framework powinny działać bez problemów w wersji 4.6.2 lub nowszej. W związku z tym te aplikacje powinny być instalowane i uruchamiane bez zmian w systemie Windows 10 w wersji 1607 lub nowszej z wersją programu .NET Framework dołączonego do systemu operacyjnego.

  • 2.0 i 3.5: W naszych testach spakowane aplikacje desktopowe przeznaczone dla tych wersji frameworku .NET zazwyczaj działają, ale mogą wykazywać problemy z wydajnością w niektórych scenariuszach. Aby te spakowane aplikacje były instalowane i uruchamiane, na maszynie docelowej musi być zainstalowana funkcja .NET Framework 3.5 (ta funkcja obejmuje również program .NET Framework 2.0 i 3.0). Należy również dokładnie przetestować te aplikacje po ich zapakowaniu.

• Aplikacja zawsze działa z podwyższonym poziomem uprawnień zabezpieczeń. Aplikacja musi działać podczas działania jako użytkownik interakcyjny. Użytkownicy, którzy instalują aplikację, mogą nie być administratorami systemu, dlatego wymaganie uruchomienia aplikacji z podwyższonym poziomem uprawnień oznacza, że nie będzie działać poprawnie dla użytkowników standardowych. Jeśli planujesz publikowanie aplikacji w sklepie Microsoft Store, aplikacje wymagające podniesienia uprawnień w żadnej części ich funkcji nie zostaną zaakceptowane w Sklepie.

• Aplikacja wymaga sterownika systemu Windows. MsiX nie obsługuje sterowników systemu Windows.

• Aplikacja wymaga usługi systemu Windows użytkownika. MsiX nie obsługuje usług systemu Windows dla poszczególnych użytkowników. MSIX obsługuje usługi sesji-0 (na maszynę) działające w ramach jednego ze zdefiniowanych kont systemowych (LocalSystem, LocalService lub NetworkService). Zamiast usługi systemu Windows użytkownika należy użyć zadania w tle.

• Moduły Twojej aplikacji są ładowane w procesach, które nie są zawarte w pakiecie aplikacji Windows. Nie jest to dozwolone, co oznacza, że rozszerzenia w procesie, takie jak rozszerzenia powłoki, nie są obsługiwane. Jeśli jednak masz dwie aplikacje w tym samym pakiecie, możesz wykonywać między nimi komunikację między procesami.

• Upewnij się, że wszystkie rozszerzenia zainstalowane przez aplikację zainstalują miejsce instalacji aplikacji. System Windows umożliwia użytkownikom i menedżerom IT zmianę domyślnej lokalizacji instalacji pakietów. Zobacz "Ustawienia->System->Pamięć->Więcej ustawień pamięci-> Zmień miejsce, gdzie nowe treści są zapisywane -> Nowe aplikacje będą zapisywane w". Jeśli instalujesz rozszerzenie z aplikacją, upewnij się, że rozszerzenie nie ma dodatkowych ograniczeń folderu instalacyjnego. Na przykład niektóre rozszerzenia mogą wyłączyć instalowanie rozszerzenia na dyskach innych niż systemowe. Spowoduje to błąd 0x80073D01 (ERROR_DEPLOYMENT_BLOCKED_BY_POLICY), jeśli lokalizacja domyślna została zmieniona.

• Aplikacja używa niestandardowego identyfikatora modelu użytkownika aplikacji (AUMID). Jeśli proces wywołuje SetCurrentProcessExplicitAppUserModelID, aby ustawić własny identyfikator AUMID, może używać tylko identyfikatora AUMID wygenerowanego dla niego przez środowisko modelu aplikacji/pakiet aplikacji systemu Windows. Nie można zdefiniować niestandardowych identyfikatorów AUMID.

• Aplikacja modyfikuje gałąź rejestru HKEY_LOCAL_MACHINE (HKLM). Każda próba utworzenia klucza HKLM przez aplikację lub otwarcia go w celu modyfikacji spowoduje niepowodzenie odmowy dostępu. Pamiętaj, że aplikacja ma własny prywatny zwirtualizowany widok rejestru, więc pojęcie ula rejestru obejmującego użytkowników i maszynę (co określa HKLM) nie ma zastosowania. Konieczne będzie znalezienie innego sposobu, aby osiągnąć to, co zwykle realizowało się za pomocą HKLM, na przykład pisanie do HKEY_CURRENT_USER (HKCU).

• Aplikacja używa podklucza rejestru ddeexec jako środka uruchamiania innej aplikacji. Zamiast tego użyj jednego z programów obsługi czasowników DelegateExecute skonfigurowanych przez różne rozszerzenia activatable w manifeście pakietu aplikacji.

• Aplikacja zapisuje dane w folderze AppData lub w rejestrze z zamiarem udostępniania danych innej aplikacji. Po konwersji usługa AppData jest przekierowywana do lokalnego magazynu danych aplikacji, który jest prywatnym sklepem dla każdej aplikacji.

  Wszystkie wpisy zapisywane przez aplikację w gałęzi rejestru HKEY_LOCAL_MACHINE są przekierowywane do izolowanego pliku binarnego, a wszelkie wpisy zapisywane przez aplikację w gałęzi rejestru HKEY_CURRENT_USER są umieszczane w prywatnej lokalizacji dla każdego użytkownika i każdej aplikacji. Aby uzyskać więcej informacji na temat przekierowywania plików i rejestru, zobacz Za kulisami Platformy Desktop Bridge.

  Użyj innego środka współużytkowania danych między procesami. Aby uzyskać więcej informacji, zobacz Przechowywanie i pobieranie ustawień oraz innych danych aplikacji.

• Twoja aplikacja zapisuje w katalogu instalacyjnym dla Twojej aplikacji. Na przykład aplikacja zapisuje w pliku dziennika umieszczonym w tym samym katalogu co plik exe. Nie jest to obsługiwane, dlatego należy znaleźć inną lokalizację, taką jak lokalny magazyn danych aplikacji.

• Aplikacja używa bieżącego katalogu roboczego. Podczas uruchamiania spakowana aplikacja klasyczna nie uzyska tego samego katalogu roboczego, który został wcześniej określony w skrócie LNK na pulpicie. Jeśli dla działania twojej aplikacji ważne jest posiadanie właściwego katalogu, musisz zmienić bieżący katalog roboczy (CWD) podczas działania programu.

  Uwaga / Notatka

  Jeśli aplikacja musi zapisać w katalogu instalacyjnym lub użyć bieżącego katalogu roboczego, możesz również rozważyć dodanie poprawki uruchomieniowej przy użyciu Package Support Framework do pakietu. Aby uzyskać więcej informacji, zobacz ten artykuł.

• Instalacja aplikacji wymaga interakcji z użytkownikiem. Instalator aplikacji musi być w stanie działać w trybie dyskretnym i musi zainstalować wszystkie jego wymagania wstępne, które nie są domyślnie włączone na czystym obrazie systemu operacyjnego.

• Aplikacja uwidacznia obiekty COM. Procesy i rozszerzenia z pakietu mogą rejestrować i używać serwerów COM i OLE, zarówno w procesie, jak i poza procesem (OOP). Aktualizacja Twórców dodaje obsługę "Packaged COM", co pozwala na rejestrowanie serwerów OOP COM i OLE, które są teraz widoczne poza pakietem. Zobacz Obsługę serwera COM i dokumentu OLE dla Desktop Bridge.

  Obsługa spakowanego modelu COM działa z istniejącymi interfejsami API COM, ale nie będzie działać w przypadku rozszerzeń aplikacji, które polegają na bezpośrednim odczytywaniu rejestru, ponieważ lokalizacja spakowanego modelu COM znajduje się w lokalizacji prywatnej.

• Aplikacja uwidacznia zestawy GAC do użycia przez inne procesy. Aplikacja nie może uwidocznić zestawów GAC do użycia przez procesy pochodzące z plików wykonywalnych spoza pakietu aplikacji systemu Windows. Procesy z poziomu pakietu mogą rejestrować i używać zestawów GAC w normalny sposób, ale nie będą widoczne zewnętrznie. Oznacza to, że scenariusze międzyoperacyjności, takie jak OLE, nie będą działać w przypadku wywołania przez procesy zewnętrzne.

• Aplikacja łączy biblioteki środowiska uruchomieniowego języka C (CRT) w sposób nieobsługiwany. Biblioteka środowiska uruchomieniowego Microsoft C/C++ zawiera procedury programowania dla systemu operacyjnego Microsoft Windows. Te procedury automatyzują wiele typowych zadań programistycznych, które nie są udostępniane przez języki C i C++. Jeśli aplikacja korzysta z biblioteki środowiska uruchomieniowego C/C++, musisz upewnić się, że jest ona połączona w obsługiwany sposób.

  Program Visual Studio 2017 obsługuje zarówno łączenie statyczne, jak i dynamiczne, aby umożliwić kodowi używanie typowych plików DLL lub łączenie statyczne w celu połączenia biblioteki bezpośrednio z kodem z bieżącą wersją narzędzia CRT. Jeśli to możliwe, zalecamy, aby aplikacja korzystała z łączenia dynamicznego z programem VS 2017.

  Obsługa w poprzednich wersjach programu Visual Studio różni się. Aby uzyskać szczegółowe informacje, zobacz następującą tabelę:

  Wersja programu Visual Studio	Łączenie dynamiczne	Łączenie statyczne
  2005 (VC 8)	Niewspierane	Wsparte
  2008 (VC 9)	Niewspierane	Wsparte
  2010 (VC 10)	Wsparte	Wsparte
  2012 (VC 11)	Wsparte	Niewspierane
  2013 (VC 12)	Wsparte	Niewspierane
  2015 i 2017 (VC 14)	Wsparte	Wsparte

  Uwaga: We wszystkich przypadkach należy połączyć się z najnowszą publicznie dostępną usługą CRT.

• Aplikacja instaluje i ładuje biblioteki z folderu współistniejącego systemu Windows. Na przykład aplikacja używa bibliotek środowiska uruchomieniowego języka C VC8 lub VC9 i dynamicznie łączy je z folderu równoległego systemu Windows, co oznacza, że kod używa typowych plików DLL z folderu udostępnionego. Nie jest to obsługiwane. Należy połączyć je statycznie, bezpośrednio linkując do plików biblioteki redystrybucyjnej w kodzie.

• Aplikacja używa zależności w folderze System32/SysWOW64. Aby te biblioteki DLL działały, należy uwzględnić je w wirtualnej części systemu plików pakietu aplikacji systemu Windows. Dzięki temu aplikacja zachowuje się tak, jakby biblioteki DLL zostały zainstalowane w folderze System32/SysWOW64 . W katalogu głównym pakietu utwórz folder o nazwie VFS. Wewnątrz tego folderu utwórz folder SystemX64 i SystemX86 . Następnie umieść 32-bitową wersję biblioteki DLL w folderze SystemX86 i umieść 64-bitową wersję w folderze SystemX64 .

• Aplikacja używa pakietu platformy VCLibs. Jeśli konwertujesz aplikację Win32 w języku C++, musisz obsługiwać wdrażanie środowiska uruchomieniowego Visual C++. Programy Visual Studio 2019 i Windows SDK obejmują najnowsze pakiety struktury dla wersji 11.0, 12.0 i 14.0 środowiska uruchomieniowego visual C++ w następujących folderach:

  • Pakiety struktury VC 14.0: C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs.Desktop\14.0

  • Pakiety struktury VC 12.0: C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs.Desktop.120\14.0

  • Pakiety struktury VC 11.0: C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs.Desktop.110\14.0

  Aby użyć jednego z tych pakietów, należy odwołać się do niego jako zależność w manifeście pakietu. Gdy klienci zainstalują wersję detaliczną aplikacji ze sklepu Microsoft Store, pakiet zostanie zainstalowany ze Sklepu wraz z twoją aplikacją. Zależności nie zostaną zainstalowane, jeśli zainstalujesz aplikację ręcznie. Aby zainstalować zależności ręcznie, należy zainstalować odpowiedni pakiet platformy przy użyciu odpowiedniego pakietu .appx dla architektury x86, x64 lub ARM znajdującej się w folderach instalacyjnych wymienionych powyżej.

  Aby odwołać się do pakietu Visual C++ Runtime w aplikacji:

  1. Przejdź do folderu instalacji pakietu platformy wymienionego powyżej, aby uzyskać wersję środowiska uruchomieniowego Visual C++ używanego przez aplikację.

  2. Otwórz plik SDKManifest.xml w tym folderze, znajdź atrybut FrameworkIdentity-Debug lub FrameworkIdentity-Retail (w zależności od tego, czy używasz wersji debugowania, czy detalicznej środowiska uruchomieniowego), a następnie skopiuj wartości Name oraz MinVersion tego atrybutu. Na przykład oto FrameworkIdentity-Retail atrybut dla bieżącego pakietu struktury 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. W manifeście pakietu aplikacji dodaj następujący <PackageDependency> element w węźle <Dependencies> . Upewnij się, że zastąpisz wartości Name i MinVersion wartościami skopiowanymi w poprzednim kroku. Poniższy przykład określa zależność dla bieżącej wersji pakietu struktury 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" />
     

• Aplikacja zawiera niestandardową listę skoków. Istnieje kilka problemów i zastrzeżeń, które należy wziąć pod uwagę podczas korzystania z list szybkiego dostępu.

  • Architektura aplikacji nie jest zgodna z systemem operacyjnym. Listy szybkiego dostępu nie działają poprawnie, jeśli architektury aplikacji i systemu operacyjnego nie są zgodne (np. aplikacja x86 działająca na systemie Windows x64). Obecnie nie ma obejścia innego niż ponowne skompilowanie aplikacji do zgodnej architektury.

  • Aplikacja tworzy wpisy listy szybkiego dostępu i wywołuje ICustomDestinationList::SetAppID lub SetCurrentProcessExplicitAppUserModelID. Nie ustawiaj AppID w kodzie automatycznie. Spowoduje to, że wpisy listy skoków nie będą wyświetlane. Jeśli aplikacja potrzebuje niestandardowego identyfikatora, określ go przy użyciu pliku manifestu. Aby uzyskać instrukcje, zobacz Ręczne tworzenie pakietu aplikacji na pulpit . Identyfikator aplikacji jest określony w sekcji YOUR_PRAID_HERE .

  • Aplikacja dodaje skrót powłoki listy szybkiego dostępu, który odwołuje się do pliku wykonywalnego w pakiecie. Nie można bezpośrednio uruchamiać plików wykonywalnych w pakiecie z listy skrótów (z wyjątkiem ścieżki bezwzględnej własnej aplikacji .exe). Zamiast tego zarejestruj alias wykonywania aplikacji (który umożliwia spakowanej aplikacji klasycznej rozpoczęcie za pomocą słowa kluczowego tak, jakby znajdował się on w ścieżce PATH) i ustawić ścieżkę docelową łącza do aliasu. Aby uzyskać szczegółowe informacje na temat korzystania z rozszerzenia appExecutionAlias, zobacz Integrowanie aplikacji klasycznej z systemem Windows 10. Należy pamiętać, że jeśli chcesz, aby zasoby linku na liście skoków dokładnie odpowiadały oryginałowi .exe, musisz ustawić takie zasoby, jak ikona, używając polecenia SetIconLocation, a nazwę wyświetlaną przy użyciu PKEY_Title, podobnie jak dla innych wpisów niestandardowych.

  • Aplikacja dodaje wpisy do listy szybkiego dostępu, które odwołują się do zasobów w pakiecie aplikacji przez ścieżki bezwzględne. Ścieżka instalacji aplikacji może ulec zmianie po zaktualizowaniu pakietów, zmianie lokalizacji zasobów (takich jak ikony, dokumenty, plik wykonywalny itd.). Jeśli wpisy listy szybkiego dostępu odnoszą się do takich zasobów za pomocą ścieżek bezwzględnych, aplikacja powinna okresowo odświeżać tę listę (na przykład podczas uruchamiania aplikacji), aby zapewnić prawidłowe rozwiązywanie ścieżek. Alternatywnie należy użyć interfejsów API UWP Windows.UI.StartScreen.JumpList które umożliwiają odwoływanie się do zasobów tekstowych i graficznych przy użyciu schematu identyfikatora URI ms-resource związanego z pakietem (który uwzględnia także język, DPI i duży kontrast).

• Aplikacja uruchamia narzędzie do wykonywania zadań. Unikaj uruchamiania narzędzi poleceń, takich jak program PowerShell i Cmd.exe. W rzeczywistości, jeśli użytkownicy instalują aplikację w systemie z systemem Windows 10 S, aplikacja nie będzie mogła ich uruchomić w ogóle. Może to zablokować przesyłanie aplikacji do sklepu Microsoft Store, ponieważ wszystkie aplikacje przesłane do Sklepu Microsoft muszą być zgodne z systemem Windows 10 S.

  Uruchomienie narzędzia może często zapewnić wygodny sposób uzyskiwania informacji z systemu operacyjnego, uzyskiwania dostępu do rejestru lub uzyskiwania dostępu do funkcji systemu. Można jednak użyć interfejsów API platformy UWP do realizacji tego rodzaju zadań. Te interfejsy API są bardziej wydajne, ponieważ nie wymagają oddzielnego pliku wykonywalnego do uruchomienia, ale co ważniejsze, uniemożliwiają aplikacji dotarcie poza pakiet. Projekt aplikacji pozostaje zgodny z izolacją, zaufaniem i zabezpieczeniami, które towarzyszą spakowanej aplikacji, a aplikacja będzie działać zgodnie z oczekiwaniami w systemach z systemem Windows 10 S.

• Aplikacja hostuje dodatki, wtyczki lub rozszerzenia. W wielu przypadkach rozszerzenia w stylu modelu COM prawdopodobnie będą nadal działać tak długo, jak rozszerzenie nie zostało spakowane i jest instalowane jako pełny dostęp zaufania. Dzieje się tak, ponieważ te instalatory mogą używać ich funkcji pełnego zaufania do modyfikowania rejestru i umieszczania plików rozszerzeń wszędzie tam, gdzie aplikacja hosta oczekuje ich znalezienia.

  Jeśli jednak te rozszerzenia są spakowane, a następnie instalowane jako pakiet aplikacji systemu Windows, nie będą działać, ponieważ każdy pakiet (aplikacja hosta i rozszerzenie) będą odizolowane od siebie. Aby dowiedzieć się więcej na temat sposobu izolowania aplikacji od systemu, zobacz Za kulisami Desktop Bridge.

  Wszystkie aplikacje i rozszerzenia instalowane przez użytkowników w systemie z systemem Windows 10 S muszą być zainstalowane jako pakiety aplikacji systemu Windows. Jeśli więc zamierzasz spakować rozszerzenia lub planujesz zachęcić współautorów do ich spakowania, rozważ, jak można ułatwić komunikację między pakietem aplikacji hosta a wszelkimi pakietami rozszerzeń. Jednym ze sposobów, w jaki można to zrobić, jest użycie usługi app service.

• Aplikacja generuje kod. Aplikacja może wygenerować kod używany w pamięci, ale uniknąć pisania wygenerowanego kodu na dysku, ponieważ proces certyfikacji aplikacji systemu Windows nie może zweryfikować tego kodu przed przesłaniem aplikacji. Ponadto aplikacje, które piszą kod na dysku, nie będą działać prawidłowo w systemach z systemem Windows 10 S. Może to zablokować przesyłanie aplikacji do sklepu Microsoft Store, ponieważ wszystkie aplikacje przesłane do Sklepu Microsoft muszą być zgodne z systemem Windows 10 S.