Ihr Installer – wichtige Grundlagen

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 Paketvorgang vorzubereiten. Wenn jedoch eines der unten angegebenen Elemente für Ihre Anwendung gilt, müssen Sie sie vor dem Packen adressieren.

  • Ihre Anwendung verfügt über einen Dienst. Wir unterstützen die Konvertierung von Anwendungen mit Diensten,aber es ist wichtig, die Einschränkungen bei der Konvertierung eines Diensts zu beachten. Nach der Konvertierung benötigen Sie erhöhte Administratorrechte, um die MSIX zu installieren, die einen Dienst enthält. Sie können eine Anwendung mit Diensten konvertieren, die ab Version 1.2019.1220.0 des MSIX Packaging Tools beginnen, und Sie können msix mit Diensten ab der Version vom Spring 2020 von Windows 10 bereitstellen.

  • Ihr Installationsprogramm erfordert einen Neustart von . Wenn Ihr Installationsprogramm einen Neustarterfordert, wird dies im MSIX Packaging Tool ab Version 1.2019.701.0 unterstützt. Wenn Ihr Installationsprogramm einen ungewöhnlichen Exitcode zurückgibt, um anzugeben, dass ein Neustart erforderlich ist, sollten Sie ihn dem Abschnitt Neustart-Exitcodes 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.

  • Für Ihre Anwendung ist ein Treiber erforderlich. 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 in 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 beispielsweise die C-Laufzeitbibliotheken VC8 oder VC9 und verknüpft sie dynamisch aus Windows ordnerseitigen Ordner. Dies bedeutet, dass Ihr Code die allgemeinen DLL-Dateien aus einem freigegebenen Ordner wie C:\Windows\WinSxS verwendet. Dies wird nicht unterstützt. Sie müssen diese statisch verknüpfen, indem sie eine Verknüpfung mit den verteilbaren Bibliotheksdateien direkt in den Code erstellen.

Weitere Überlegungen

  • Packen Sie Ihren Installer auf der richtigen Architektur neu. Wenn Ihr Installationsprogramm auf einem x86-Computer installiert werden soll. Stellen Sie sicher, dass Sie Ihr Installationsprogramm auf einem x86-Computer neu packen. 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. Weitere Informationen finden Sie in diesem Artikel.