Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
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 Administratorrechte, 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 von .NET Framework vor 4.6.2. Wenn Sie eine .NET-Anwendung verpacken, empfehlen wir, dass Ihre Anwendung auf .NET Framework 4.6.2 oder höher ausgerichtet ist. Die Möglichkeit zum Installieren und Ausführen verpackter Desktopanwendungen wurde zuerst in Windows 10, Version 1607 (auch als Anniversary Update bezeichnet), eingeführt, und diese Betriebssystemversion enthält standardmäßig .NET Framework 4.6.2. Spätere Betriebssystemversionen umfassen höhere Versionen von .NET Framework. Eine vollständige Liste der Versionen von .NET, die in späteren Versionen von Windows 10 enthalten sind, finden Sie in diesem Artikel.
Das Anvisieren von Versionen des .NET Frameworks vor 4.6.2 in gepackten Desktopanwendungen funktioniert in den meisten Fällen. Wenn Sie jedoch auf eine frühere Version als 4.6.2 abzielen, sollten Sie Ihre verpackte Desktopanwendung vollständig testen, bevor Sie sie an Benutzer verteilen.
4.0 - 4.6.1: Anwendungen, die auf diese Versionen von .NET Framework abzielen, werden voraussichtlich ohne Probleme auf 4.6.2 oder höher ausgeführt. Daher sollten diese Anwendungen ohne Änderungen unter Windows 10, Version 1607 oder höher, mit der Version von .NET Framework installiert und ausgeführt werden, die im Betriebssystem enthalten ist.
2.0 und 3.5: In unseren Tests funktionieren verpackte Desktopanwendungen, die auf diese Versionen von .NET Framework abzielen, im Allgemeinen, können jedoch in einigen Szenarien möglicherweise Leistungsprobleme aufweisen. Damit diese verpackten Anwendungen installiert und ausgeführt werden können, muss das .NET Framework 3.5-Feature auf dem Zielcomputer installiert sein (dieses Feature enthält auch .NET Framework 2.0 und 3.0). Sie sollten diese Anwendungen auch gründlich testen, nachdem Sie sie verpackt haben.
Ihre Anwendung erfordert einen Treiber. MSIX unterstützt keine Treiber.
Ihre Anwendung schreibt in den AppData-Ordner oder in die Registrierung mit dem Ziel, Daten mit einer anderen App zu teilen. Nach der Konvertierung wird AppData an den lokalen App-Datenspeicher umgeleitet, bei dem es sich um einen privaten Store für jede App handelt.
Alle Einträge, die Ihre Anwendung in die HKEY_LOCAL_MACHINE Registrierungsstruktur schreibt, werden an eine isolierte Binärdatei umgeleitet, und alle Einträge, die Ihre Anwendung in die HKEY_CURRENT_USER Registrierungsstruktur schreibt, werden in einen privaten benutzerspezifischen App-Speicherort eingefügt. Weitere Informationen zur Datei- und Registrierungsumleitung finden Sie unter Hinter den Kulissen der Desktop-Brücke.
Ihre Anwendung schreibt in das Installationsverzeichnis für die App. Zum Beispiel schreibt Ihre Anwendung in eine Protokolldatei, die Sie im selben Verzeichnis wie Ihre EXE ablegen. 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 Möglichkeit hinzugefügt, die dies ab Version 1809 zulässt.
Ihre Anwendung verwendet das aktuelle Arbeitsverzeichnis. Zur Laufzeit erhält Ihre verpackte Desktop-Anwendung 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 Seiten-an-Seite-Ordner von Windows, was bedeutet, dass Ihr Code die allgemeinen DLL-Dateien aus einem geteilten 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 in Ihrem Code verknüpfen.
Weitere Überlegungen
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 finden Sie in diesem Artikel.