Aplikacje systemu Windows: pakowanie, wdrażanie i przetwarzanie

W tym temacie omówiono opcje dotyczące następujących kwestii:

  • Którą opcję pakowania wybrać dla swojej aplikacji (spakowana, spakowana z lokalizacją zewnętrzną czy niespakowana).
  • Sposób wdrażania/dystrybuowania aplikacji oraz sposobu jej instalowania.
  • Proces działania Twojej aplikacji w czasie wykonywania, w tym stopień jej izolacji i to, jakie interfejsy API będą dla niej dostępne.

Możesz podjąć te decyzje zarówno dla nowych, jak i istniejących aplikacji. Jeśli jednak nadal pracujesz na etapie planowania nowej aplikacji, zanim zaczniesz myśleć o powyższych zagadnieniach, najpierw zdecyduj, jaka platforma deweloperska i struktura interfejsu użytkownika będą używane dla aplikacji. W przypadku tej decyzji zobacz Omówienie opcji programowania systemu Windows.

Opcje pakowania: spakowany, spakowany z lokalizacją zewnętrzną lub niespakowany

Decyzja o tym, która opcja pakowania do użycia dla aplikacji jest najpierw określana przez koncepcję znaną jako tożsamość pakietu. Z wielu funkcji rozszerzania systemu Windows (zadań w tle, scenariuszy powiadomień push korzystających z dostarczania w tle lub aktywacji COM, niestandardowych rozszerzeń menu kontekstowego oraz obiektów docelowych udostępniania) aplikacja może korzystać tylko wtedy, gdy ma tożsamość pakietu w czasie działania, ponieważ system operacyjny musi mieć możliwość zidentyfikowania podmiotu wywołującego odpowiedni interfejs API. Tylko spakowane aplikacje (w tym aplikacje spakowane z lokalizacją zewnętrzną) mają tożsamość pakietu.

Aby uzyskać pełne wyjaśnienie modeli pakietowanych, pakietowanych z lokalizacją zewnętrzną i niepakietowanych oraz tego, jak wybrać odpowiedni model, zobacz temat Omówienie pakowania. Aby zapoznać się z funkcjami zależnymi od tożsamości pakietu, zobacz Funkcje wymagające tożsamości pakietu.

Aby uzyskać informacje o tym, jak skonfigurować aplikację w formie spakowanej lub rozpakowanej:

Zobacz również sekcję Windows Menedżer pakietów i klienta WinGet w tym temacie.

Wdrażanie/dystrybucja/instalacja

Spakowana aplikacja jest zarówno spakowana, jak i zainstalowana przy użyciu pliku MSIX. Jeśli zdecydujesz się spakować aplikację z użyciem lokalizacji zewnętrznej, będzie to model „przynieś własny instalator” („bring-your-own-installer”), więc nadal musisz samodzielnie przygotować instalator (zobacz Nadawanie tożsamości pakietu przez pakowanie z użyciem lokalizacji zewnętrznej). Rozpakowana aplikacja w ogóle nie obejmuje pliku MSIX.

Pakietyzacja ma znaczenie, ponieważ MSIX zapewnia użytkownikom bezproblemowy proces instalacji, odinstalowywania i aktualizacji, obsługuje przyrostowe i automatyczne aktualizacje, jest optymalizowany przez Microsoft Store, współpracuje z funkcją MSIX app attach na platformie Azure Virtual Desktop oraz po podpisaniu korzysta z silnej ochrony przed manipulacją.

Aby uzyskać wskazówki dotyczące wdrażania i dystrybucji, zobacz Omówienie pakietu i wdrażania oraz Wybierz ścieżkę dystrybucji. Zobacz również sekcję Windows Menedżer pakietów i klienta WinGet w tym temacie.

AppContainer lub średni IL

Opcja uruchomienia aplikacji w AppContainerze lub bez niego to kwestia bezpieczeństwa. Proces aplikacji AppContainer i jej procesy podrzędne są uruchamiane wewnątrz lekkiego kontenera aplikacji, w którym mogą dostępować tylko do zasobów, które zostały im specjalnie przyznane. Są one izolowane przy użyciu systemu plików i wirtualizacji rejestru. W związku z tym aplikacje zaimplementowane w aplikacji AppContainer nie mogą zostać zhakowane, aby umożliwić złośliwe działania poza ograniczonymi przypisanymi zasobami.

Spakowane lub rozpakowane aplikacje można skonfigurować do uruchamiania w aplikacji AppContainer. Jednak proces jest bardziej prosty w przypadku spakowanych aplikacji. Jeśli aplikacja nie jest aplikacją AppContainer, jest to aplikacja Medium IL .

Aby uzyskać więcej informacji, zobacz AppContainer dla starszych aplikacji i aplikacji MSIX AppContainer.

Jak skonfigurować aplikację do uruchamiania w AppContainer lub Medium IL:

  • Aplikacje WinUI (zestaw SDK aplikacji systemu Windows). Zobacz atrybut manifestu pakietu aplikacji uap10:TrustLevel w Konfigurowanie projektu WinUI dla AppContainer.
  • Aplikacje pulpitowe. Zobacz właściwość projektu Visual Studio w aplikacjach MSIX AppContainer (w sekcji odpowiedniej dla rodzaju twojej aplikacji).
  • aplikacje Universal Windows Platform (UWP). Aplikacje platformy UWP są już skonfigurowane do uruchamiania w aplikacji AppContainer; nie można zmienić tej konfiguracji.

Pamiętaj, że niezapakowane aplikacje nie mają manifestu pakietu aplikacji. W przypadku aplikacji rozpakowanych należy zadeklarować decyzję AppContainer-or-Medium-IL w pliku project zamiast w manifeście pakietu aplikacji.

Izolacja aplikacji Win32

Izolacja aplikacji Win32 to funkcja zabezpieczeń (dostępna w Windows 11 w wersji 24H2 lub nowszej), która pomaga w usuwaniu szkód w przypadku naruszenia zabezpieczeń aplikacji i zabezpiecza opcje prywatności użytkowników. Jest ona oparta na elementach AppContainers i składnikach, które wirtualizują zasoby i zapewniają dostęp obsługiwany przez brokera. Aby uzyskać więcej informacji, zobacz omówienie izolacji aplikacji Win32 oraz repozytorium GitHub izolacji aplikacji Win32.

Możliwości aplikacji

Możliwości aplikacji (na przykład InternetClient, lokalizacja, mikrofon i bluetooth) mają zastosowanie głównie do spakowanych aplikacji uruchamianych w aplikacji AppContainer. Obejmuje to wszystkie aplikacje Universal Windows Platform (UWP) oraz niektóre aplikacje pulpitowe.

Istnieją jednak pewne scenariusze, w których nawet aplikacja Medium IL (czyli nie aplikacja AppContainer) powinna zadeklarować możliwość. Przykładem jest ograniczona funkcja runFullTrust.

Aby uzyskać więcej informacji na temat możliwości aplikacji, rodzajów aplikacji, do których mają zastosowanie, oraz sposobu ich konfigurowania, zobacz Deklaracje możliwości aplikacji. Możliwości można skonfigurować w manifeście pakietu aplikacji; dlatego mają zastosowanie tylko do spakowanych aplikacji.

Rodzaje aplikacji

Aplikacje klasyczne i aplikacje Universal Windows Platform (UWP) to dwa główne rodzaje aplikacji, chociaż w rodzinie aplikacji klasycznych istnieje kilka rodzajów aplikacji. Wybór struktury interfejsu użytkownika (WinForms, WPF, Win32, Direct 2D/3D lub WinUI 3) jest w pewnym stopniu niezależny od konfiguracji opisanych w tym temacie.

Przyjrzyjmy się jednak temu, jak te rodzaje aplikacji mogą się różnić od siebie pod względem tworzenia pakietów, wdrażania i przetwarzania.

Najpierw wszystkie aplikacje platformy UWP są pakowane i uruchamiane w aplikacji AppContainer. Jednak w przypadku aplikacji desktopowych kwestie są bardziej elastyczne. Możesz zdecydować się spakować swoją aplikację desktopową lub nie. Niezależnie od tej decyzji możesz również skonfigurować aplikację komputerową jako AppContainer lub Medium IL.

Pakowane Nieopakowany
AppContainer Aplikacje na komputery stacjonarne
Aplikacje platformy UWP		 Aplikacje na komputery stacjonarne
Średni IL Aplikacje na komputery stacjonarne Aplikacje na komputery stacjonarne

W przypadku spakowanych aplikacji, aby skonfigurować odpowiedni rodzaj aplikacji, należy użyć atrybutu uap10:RuntimeBehavior w manifeście pakietu aplikacji (zobacz Application (Windows 10)).

  • Aplikacje klasyczne to systemy Windows .exe, zazwyczaj z główną lub funkcją punktu wejścia WinMain . Aby skonfigurować aplikację jako aplikację na komputer stacjonarny, ustaw parametr uap10:RuntimeBehavior na "packagedClassicApp" lub "win32App".
    • Wartość "packagedClassicApp" wskazuje aplikację WinUI (Zestaw SDK do aplikacji systemu Windows) lub aplikację Desktop Bridge (Centennial). Różnica polega na tym, że aplikacja Centennial działa w aplikacji AppContainer.
    • A "win32App" wskazuje na dowolny inny rodzaj aplikacji Win32 (w tym aplikację spakowaną i przechowywaną w lokalizacji zewnętrznej).
  • Na koniec ustawienie uap10:RuntimeBehavior na "windowsApp" daje aplikację UWP.

Aby zapoznać się ze wszystkimi dostępnymi opcjami rodzajów aplikacji, które można opracowywać, zobacz Rozwój aplikacji Windows: opcje i funkcje.

Zestaw SDK do aplikacji systemu Windows: zależne od platformy lub samodzielne

Jeśli aplikacja korzysta z Zestaw SDK do aplikacji systemu Windows, możesz także wybrać sposób wdrożenia środowiska uruchomieniowego SDK, od którego zależy aplikacja: zależny od frameworka (ustawienie domyślne, w którym środowisko uruchomieniowe Zestaw SDK do aplikacji systemu Windows i/lub pakiet Framework muszą być obecne na komputerze docelowym) lub samowystarczalny (aplikacja zawiera swoje zależności Zestaw SDK do aplikacji systemu Windows). Aby uzyskać więcej informacji, zobacz omówienie wdrażania Zestaw SDK do aplikacji systemu Windows.

Windows Menedżer pakietów i klient WinGet

Package manager może pomóc użytkownikom w instalowaniu/uaktualnianiu/konfigurowaniu oprogramowania, automatyzując przepływ pracy. Menedżerowie pakietów mogą pomóc w zainstalowaniu dowolnego oprogramowania, ale zwykle są używane głównie do instalowania developer tools. Jeśli więc tworzysz narzędzie deweloperskie, możesz być szczególnie zainteresowany tą opcją. Ale oto jak to działa:

  • Jako deweloper oprogramowania definiujesz package manager (w formie instrukcji deklaratywnych) wszystkie elementy niezbędne do pomyślnej instalacji produktu.
  • Następnie, gdy użytkownik zainstaluje oprogramowanie, menedżer pakietów postępuje zgodnie z instrukcjami deklaratywnymi, aby zautomatyzować przepływ pracy dotyczący instalacji i konfiguracji.

Rezultatem jest skrócenie czasu poświęcanego na przygotowanie środowiska użytkownika i lepszą zgodność między zainstalowanymi składnikami. Za pomocą Menedżer pakietów systemu Windows można dystrybuować spakowane lub rozpakowane aplikacje w formatach, takich jak .msix, .msi i .exe.

Aby uzyskać więcej informacji, zobacz Windows Menedżer pakietów.

  • Last updated on