Freigeben über

Ihr Installer – wichtige Grundlagen

  • Artikel

In diesem Artikel werden die Dinge aufgeführt, die Sie wissen müssen, bevor Sie Ihr vorhandenes Installationsprogramm in ein MSIX konvertieren. Möglicherweise müssen Sie nicht viel tun, um Ihre Anwendung für den Verpackungsvorgang vorzubereiten, aber wenn eines der folgenden Artikel für Ihre Anwendung gilt, müssen Sie sie vor dem Verpacken adressieren.

  • Ihre Anwendung verfügt über einen Dienst. Wir unterstützen das Konvertieren von Anwendungen mit Diensten, aber es ist wichtig, die Einschränkungen beim Konvertieren eines Diensts zu berücksichtigen. Nach der Konvertierung benötigen Sie Administratorerweiterungen, um die MSIX zu installieren, die einen Dienst enthält. Sie können eine Anwendung mit Diensten ab Version 1.2019.1220.0 des MSIX Packaging Tools konvertieren, und Sie können msIX mit Diensten bereitstellen, die im Frühjahr 2020 von Windows 10 veröffentlicht wurden.

  • Für das Installationsprogramm ist ein Neustart erforderlich. Wenn das Installationsprogramm einen Neustart erfordert, wird dies ab Version 1.2019.701.0 im MSIX Packaging Tool unterstützt. Wenn Ihr Installationsprogramm einen ungewöhnlichen Exit-Code zurückgibt, um anzugeben, dass er einen Neustart benötigt, sollten Sie ihn dem Abschnitt "Neustartendecodes " der MSIX Packaging Tool-Einstellungen hinzufügen.

  • Ihre .NET-Anwendung erfordert eine Version des .NET-Frameworks, die älter als 4.6.2 ist. Wenn Sie eine .NET-Anwendung verpacken, wird empfohlen, dass Ihre Anwendung auf .NET Framework 4.6.2 oder höher ausgerichtet ist. Die Möglichkeit, verpackte Desktopanwendungen zu installieren und auszuführen, wurde erstmals in Windows 10, Version 1607 (auch als Anniversary Update bezeichnet), eingeführt, und diese Betriebssystemversion enthält standardmäßig das .NET Framework 4.6.2. Spätere Betriebssystemversionen enthalten höhere Versionen des .NET Frameworks. Eine vollständige Liste, welche Versionen von .NET in höheren Versionen von Windows 10 enthalten sind, finden Sie in diesem Artikel.

    Es wird erwartet, dass die Verwendung von Versionen des .NET-Frameworks vor 4.6.2 in verpackten Desktopanwendungen in den meisten Fällen funktioniert. Wenn Sie jedoch eine ältere Version als 4.6.2 ins Auge fassen, sollten Sie Ihre verpackte Desktopanwendung vollständig testen, bevor Sie sie an die Benutzer verteilen.

    • 4.0 – 4.6.1: Anwendungen, die auf diese Versionen des .NET-Frameworks ausgerichtet sind, können voraussichtlich ab 4.6.2 oder höher ohne Probleme ausgeführt werden. Daher sollten diese Anwendungen ohne Änderungen unter Windows 10, Version 1607 oder höher mit der Version des .NET-Frameworks, die im Betriebssystem enthalten ist, installiert und ausgeführt werden.

    • 2.0 und 3.5: In unseren Tests funktionieren verpackte Desktopanwendungen, die auf diese Versionen des .NET-Frameworks ausgerichtet sind, im Allgemeinen, können aber in einigen Szenarien Leistungsprobleme aufweisen. Damit diese verpackten Anwendungen installiert und ausgeführt werden können, muss auf dem Zielcomputer das Feature .NET Framework 3.5 installiert werden (dieses Feature umfasst auch .NET Framework 2.0 und 3.0). Sie sollten diese Anwendungen auch nach dem Verpacken gründlich testen.

  • Ihre Anwendung erfordert einen Treiber. MSIX unterstützt keine Treiber.

  • Ihre Anwendung schreibt in den AppData-Ordner oder die Registrierung, um Daten für eine andere App freizugeben. Nach der Konvertierung wird AppData an den lokalen App-Datenspeicher weitergeleitet, der ein privater Speicher für jede App ist.

    Alle Einträge, die Ihre Anwendung in der Registrierungsstruktur HKEY_LOCAL_MACHINE schreibt werden in eine isolierte Binärdatei umgeleitet, und alle Einträge, die Ihre Anwendung in der Registrierungsstruktur HKEY_CURRENT_USER schreibt werden in einem privaten Speicherort pro Benutzer, pro App platziert. Weitere Informationen zur Datei- und Registrierungsumleitung finden Sie unter Hintergrundinformationen zur Desktop-Brücke.

  • Ihre Anwendung schreibt in das Installationsverzeichnis für die App. Ihre Anwendung schreibt z. B. in eine Protokolldatei, die sich in demselben Verzeichnis wie die EXE-Datei befindet. Dies wird nicht unterstützt, da der Ordner geschützt ist. Es wird empfohlen, an einen anderen Speicherort wie den lokalen App-Datenspeicher zu schreiben. Wir haben eine Funktion hinzugefügt, die dies 1809 und höher zulässt.

  • Ihre Anwendung verwendet das aktuelle Arbeitsverzeichnis. Zur Laufzeit nutzt die verpackte Desktopanwendung nicht das gleiche Arbeitsverzeichnis, das Sie zuvor in Ihrer Desktop-LNK-Verknüpfung angegeben haben. Sie müssen das aktuelle Arbeitsverzeichnis zur Laufzeit ändern, wenn das richtige Verzeichnis notwendig ist, damit Ihre Anwendung ordnungsgemäß funktioniert.

  • Ihre Anwendung installiert und lädt Assemblys aus dem Windows-Seite-an-Seite-Ordner. Ihre Anwendung verwendet z. B. C-Laufzeitbibliotheken VC8 oder VC9 und verknüpft sie dynamisch aus dem ordner "Nebeneinander von Windows", was bedeutet, dass Ihr Code die allgemeinen DLL-Dateien aus einem freigegebenen Ordner verwendet, z. B. C:\Windows\WinSxS. Dieser Vorgang wird nicht unterstützt. Sie müssen sie statisch verknüpfen, indem Sie direkt mit den weiterverteilbaren Bibliotheksdateien im Code verknüpfen.

Andere Aspekte

  • Umpacken Des Installers auf die richtige Architektur. Wenn das Installationsprogramm auf einem x86-Computer installiert werden soll. Stellen Sie sicher, dass Sie das Installationsprogramm auf einem x86-Computer neu verpacken. Dies gilt für Installationsprogramme, die für x64-Computer vorgesehen sind.

    Hinweis

    Wenn Ihre Anwendung in das Installationsverzeichnis schreiben oder das aktuelle Arbeitsverzeichnis verwenden muss, können Sie auch in Betracht ziehen, eine Laufzeitkorrektur mit dem Package Support Framework zu Ihrem Paket hinzuzufügen. Ausführlichere Informationen dazu finden Sie in diesem Artikel.