Bieżący stan funkcji dystrybucji aplikacji Windows

Ta strona dokumentuje bieżący stan funkcji dystrybucji aplikacji Windows, które uległy zmianie, są znane z ograniczeń lub zachowują się inaczej niż ich dokumentacja. Jest aktualizowana w miarę rozwoju platformy.

Ostatnia recenzja: Kwiecień 2026 r.

ms-appinstaller URI protocol (Protokół identyfikatora URI programu ms-appinstaller)

Stan: Domyślnie wyłączone (od grudnia 2023 r.)

Procedura ms-appinstaller:?source= obsługi protokołu URI umożliwia stronie internetowej wyzwolenie instalacji Instalatora aplikacji jednym kliknięciem bez uprzedniego pobrania pliku przez użytkownika. Ta funkcja została domyślnie wyłączona w instalatorze aplikacji w wersji 1.21.3421.0, wydana 12 grudnia 2023 r., w odpowiedzi na jej nadużycie przez kampanię złośliwego oprogramowania Emotet (CVE-2021-43890 wzorzec wykorzystania).

Context Status
Urządzenia konsumenckie (ustawienie domyślne) ❌ Wyłączone
Urządzenia przedsiębiorstwa (zarządzane przez IT) ✅ Można ponownie włączyć za pomocą zasad polityki grupy

Impact: Strony samouczka Microsoft Learn, które demonstrują linki internetowe <a href="ms-appinstaller:?source=...">Install</a> nie działają już dla większości użytkowników.

Rozwiązania tymczasowe:

  • Połącz bezpośrednio z plikiem .appinstaller — użytkownicy pobierają go i dwukrotnie w niego klikają. Nadal działa to i jest to zalecane podejście dla scenariuszy innych niż przedsiębiorstwa.
  • Publikuj w Microsoft Store — zapewnia doskonałe doświadczenie instalacji jednym kliknięciem bez zależności od protokołu.
  • Ponowne włączanie przedsiębiorstwa: Ustaw zasady EnableMSAppInstallerProtocol grupy na włączone za pośrednictwem dostawcy usługi konfiguracji DesktopAppInstaller. Uwaga: wartość Disabled zasad oznacza, że "ustawienie nie jest skonfigurowane" (podwójnie ujemne); ustaw na Enabled, aby ponownie włączyć protokół.

Dokumentacja:Funkcje zabezpieczeń Instalatora aplikacji

Wersje schematu pliku appinstaller

Status: Visual Studio domyślnie generuje nieaktualny schemat

Plik .appinstaller XML obsługuje wiele wersji schematu, z których każda ma różne możliwości. Visual Studio generuje pliki przy użyciu schematu 2017/2 który domyślnie nie obsługuje kilku ważnych atrybutów konfiguracji aktualizacji.

[No changes needed]) Schemat 2017/2 Schemat 2021
ShowPrompt ❌ Nieobsługiwane ✅ Obsługiwane
UpdateBlocksActivation ❌ Nieobsługiwane ✅ Obsługiwane
HoursBetweenUpdateChecks ❌ Nieobsługiwane ✅ Obsługiwane
Podstawowa aktualizacja podczas uruchamiania ✅ Obsługiwane ✅ Obsługiwane

Impact: Deweloperzy, którzy korzystają z Visual Studio do generowania plików .appinstaller, a następnie konfigurują ShowPrompt lub UpdateBlocksActivation, odkryją, że te ustawienia będą cicho ignorowane podczas wykonywania.

Naprawić: Ręcznie zaktualizuj xmlns atrybut w .appinstaller pliku:

<!-- Change this: -->
<AppInstaller xmlns="http://schemas.microsoft.com/appx/appinstaller/2017/2" ...>

<!-- To this: -->
<AppInstaller xmlns="http://schemas.microsoft.com/appx/appinstaller/2021" ...>

Odwołania:Automatyczne aktualizowanie i naprawianie aplikacji · WindowsAppSDK — dyskusja #5125

Reputacja filtru SmartScreen: certyfikaty EV nie udzielają już natychmiastowego obejścia

Stan: Zachowanie zostało zmienione w 2024 r.

Przed 2024 r. certyfikaty podpisywania kodu rozszerzonej weryfikacji (EV) przyznały natychmiastową reputację filtru SmartScreen — nowo podpisany plik binarny nie wyświetli ostrzeżenia o pobieraniu. Microsoft zaktualizował wymagania Zaufanego Programu Podstawowego w 2024 roku, usuwając specyficzne dla EV identyfikatory OID. Reputacja filtru SmartScreen jest teraz wyłącznie oparta na skrótach i gromadzi się w czasie, niezależnie od typu certyfikatu (OV lub EV).

Wpływ: Deweloperzy, którzy kupili certyfikaty EV specjalnie w celu obejścia ostrzeżeń filtru SmartScreen dla nowych wersji, zobaczą, że certyfikaty EV nie zapewniają już tej korzyści.

Bieżące zachowanie: Wszystkie pliki binarne inne niż ze Store i niepodpisane przez Microsoft wyświetlają monit filtru SmartScreen podczas pierwszego pobierania do momentu zgromadzenia wystarczającej liczby pobrań dla tego skrótu pliku.

Zobacz reputację SmartScreen dla deweloperów aplikacji Windows, aby uzyskać szczegółowe informacje na temat oczekiwanego zachowania i zaleceń.

MsiX w Windows 10 a Windows 11

Status: Kilka funkcji MSIX jest dostępnych wyłącznie w Windows 11

MSIX działa zarówno na Windows 10, jak i Windows 11, ale kilka funkcji — w tym współdzielone kontenery pakietów, modyfikowalne katalogi pakietów i trwała tożsamość MSIX — są dostępne tylko w Windows 11 i nie zostały przeniesione do wcześniejszej wersji. Zależności dynamiczne są również obsługiwane w systemie Windows 10 za pośrednictwem Zestaw SDK do aplikacji systemu Windows (Mdd* API / bootstrapper), a Windows 11 dodatkowo zapewnia natywną implementację systemu operacyjnego. Ponadto wsparcie podstawowe Windows 10 zakończyło się 14 października 2025 r.

Aby zapoznać się z pełną tabelą porównawczą, znanymi ograniczeniami nieuwspieranej obiegowości i obejściami dla poszczególnych funkcji, zobacz MSIX w systemie Windows 10 i Windows 11.

MsixPackaging@1 Azure DevOps zadanie

Stan: Używa nieaktualnych zależności

Zadanie MsixPackaging@1 w potokach Azure DevOps używa programu MSBuild 4.8.4161.0 (zamiast programu MSBuild 16+) i zostało skompilowane względem Node.js 16 (który zakończył swój cykl życia we wrześniu 2023 r.). Może to spowodować błędy kompilacji w nowoczesnych konfiguracjach pipeline'ów.

Workaround: Użyj programu MSBuild bezpośrednio w pipeline zamiast zadania MsixPackaging@1, lub użyj GitHub Actions z akcją microsoft/setup-msbuild.

References:GitHub Problem nr 518 · GitHub Problem nr 679

Treści powiązane

  • Last updated on