Vorbereiten des Verpackens einer Desktopanwendung

In diesem Artikel sind Punkte aufgeführt, die Sie vor dem Verpacken von Desktopanwendungen wissen sollten. Sie müssen möglicherweise nicht viel tun, um Ihre Anwendung für die Verpackung vorzubereiten. Trifft jedoch einer der folgenden Punkte auf Ihre Anwendung zu, müssen Sie sich vor der Verpackung darum kümmern.

• 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 wird immer mit erhöhten Sicherheitsberechtigungen ausgeführt. Ihre Anwendung muss als interaktiver Benutzer ausgeführt werden können. Benutzer, die Ihre Anwendung installieren, sind möglicherweise keine Systemadministratoren. Wenn für die Ausführung Ihrer Anwendung erhöhte Rechte erforderlich sind, wird die Anwendung für Standardbenutzer nicht ordnungsgemäß ausgeführt. Wenn Sie vorhaben, Ihre Anwendung im Microsoft Store zu veröffentlichen, werden Anwendungen, die für einen Teil ihrer Funktionalität eine Erhöhung der Rechte erfordern, nicht in den Store aufgenommen.

• Die Anwendung erfordert einen Windows-Treiber. MSIX unterstützt keine Windows-Treiber.

• Die Anwendung erfordert einen benutzerspezifischen Windows-Dienst. MSIX unterstützt keine benutzerspezifischen Windows-Dienste. MSIX unterstützt Session-0-Dienste (pro Computer), die unter einem der definierten Systemkonten (LocalSystem, LocalService oder NetworkService) ausgeführt werden. Verwenden Sie anstelle eines benutzerspezifischen Windows-Dienstes eine Hintergrundaufgabe.

• Ihre App-Module werden im Prozess für Prozesse geladen, die nicht im Windows-App-Paket enthalten sind. Das ist nicht zulässig, was bedeutet, dass In-Process-Erweiterungen wie Shellerweiterungen nicht unterstützt werden. Wenn ein und dasselbe Paket jedoch zwei Apps enthält, ist eine prozessübergreifende Kommunikation zwischen ihnen möglich.

• Stellen Sie sicher, dass alle von der Anwendung installierten Erweiterungen dort installiert werden, wo die Anwendung installiert ist. Windows ermöglicht es Benutzern und IT-Managern, den standardmäßigen Installationspfad für Pakete zu ändern. Weitere Informationen finden Sie unter „Einstellungen > System > Speicher > Weitere Speichereinstellungen > Speicherort für neue Inhalte ändern > Speicherort für neue Apps“. Wenn Sie eine Erweiterung mit Ihrer Anwendung installieren, stellen Sie sicher, dass die Erweiterung keine zusätzlichen Einschränkungen für den Installationsordner aufweist. Einige Erweiterungen können z. B. die Installation ihrer Erweiterung auf Nicht-Systemdatenträgern deaktivieren. Dies führt zum Fehler 0x80073d01 (ERROR_DEPLOYMENT_BLOCKED_BY_POLICY), wenn der Standardspeicherort geändert wurde.

• Ihre Anwendung verwendet eine benutzerdefinierte Anwendungsbenutzermodell-ID (Application User Model ID, AUMID). Wenn der Prozess SetCurrentProcessExplicitAppUserModelID zum Festlegen einer eigenen Anwendungsbenutzermodell-ID aufruft, kann er nur die von der Anwendungmodellumgebung/vom Windows-App-Paket generierte Anwendungsbenutzermodell-ID verwenden. Es können keine benutzerdefinierten AUMIDs definiert werden.

• Ihre Anwendung ändert die HKLM-Registrierungsstruktur (HKEY_LOCAL_MACHINE). Bei jedem Versuch Ihrer Anwendung, einen HKLM-Schlüssel zu erstellen oder einen zum Ändern zu öffnen, wird der Zugriff verweigert. Denken Sie daran, dass die Anwendung über eine eigene private virtualisierte Ansicht der Registrierung verfügt. Damit kann das Konzept einer benutzer- und computerweiten Registrierungsstruktur (Zweck von HKLM) nicht angewendet werden. Sie müssen eine andere Möglichkeit finden, das zu erreichen, wofür Sie HKLM verwendet haben. Schreiben Sie z. B. stattdessen in HKEY_CURRENT_USER (HKCU).

• Ihre Anwendung verwendet einen DDEEXEC-Registrierungsunterschlüssel zum Starten einer anderen App. Verwenden Sie stattdessen einen der DelegateExecute-Verbhandler, die von den verschiedenen aktivierbaren* Erweiterungen im App-Paketmanifest konfiguriert werden.

• 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.

  Verwenden Sie eine andere Möglichkeit der prozessübergreifenden Datenfreigabe. Weitere Informationen finden Sie unter Speichern und Abrufen von Einstellungen und anderen App-Daten.

• 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. Das wird nicht unterstützt, daher müssen Sie einen anderen Speicherort wie den lokalen App-Datenspeicher nutzen.

• 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.

  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.

• Ihre Anwendungsinstallation erfordert eine Benutzerinteraktion. Das Installationsprogramm der Anwendung muss automatisch ausgeführt werden können und muss alle erforderlichen Komponenten installieren, die nicht standardmäßig auf einem sauberen Betriebssystemimage aktiviert sind.

• Ihre Anwendung macht COM-Objekte verfügbar. Prozesse und Erweiterungen innerhalb des Pakets können OLE & COM-Server sowohl im Prozess und Out-of-Process (OOP) registrieren und verwenden. Das Creators Update stellt verpackte COM-Unterstützung bereit, die die Möglichkeit bietet, OLE & OOP-COM-Server zu registrieren, die außerhalb des Pakets sichtbar sind. Weitere Informationen finden Sie unter COM-Server und OLE-Dokument-Support für Desktop-Brücke.

  Die verpackte COM-Unterstützung funktioniert mit den vorhandenen COM-APIs. Sie funktioniert aber nicht bei Anwendungserweiterungen, die vom direkten Lesen der Registrierung abhängig sind, da der Speicherort für die verpackte COM privat ist.

• Ihre Anwendung macht GAC-Assemblys zur Verwendung durch andere Prozesse verfügbar. Ihre Anwendung kann GAC-Assemblys nicht zur Verwendung durch Prozesse verfügbar machen, die von ausführbaren Dateien stammen, die sich außerhalb Ihres Windows-App-Pakets befinden. Prozesse aus dem Paket können GAC-Assemblys wie gewohnt registrieren und verwenden, aber sie sind nicht extern sichtbar. Das bedeutet, dass Interop-Szenarien wie OLE nicht funktionieren, wenn sie von externen Prozessen aufgerufen werden.

• Ihre Anwendung verknüpft C-Laufzeitbibliotheken (CRT) auf eine nicht unterstützte Weise. Die C/C++-Laufzeitbibliothek von Microsoft enthält Routinen zur Programmierung für das Microsoft Windows-Betriebssystem. Diese Routinen automatisieren viele allgemeine Programmieraufgaben, die von den Programmiersprachen C# und C++ nicht bereitgestellt werden. Wenn Ihre Anwendung eine C/C++-Laufzeitbibliothek verwendet, müssen Sie sicherstellen, dass sie auf eine unterstützte Weise verknüpft ist.

  Visual Studio 2017 unterstützt die statische und dynamische Verknüpfung, damit Ihr Code gängige DLL-Dateien verwenden kann, und statische Verknüpfung, um die Bibliothek direkt in Ihren Code, mit der aktuellen Version der CRT, zu verknüpfen. Wir empfehlen, dass Ihre Anwendung möglichst die dynamische Verknüpfung mit VS 2017 verwendet.

  Der Support in früheren Versionen von Visual Studio ist unterschiedlich. Details finden Sie in der folgenden Tabelle:

  Visual Studio-Version	Dynamische Verknüpfung	Statische Verknüpfung
  2005 (VC 8)	Nicht unterstützt	Unterstützt
  2008 (VC 9)	Nicht unterstützt	Unterstützt
  2010 (VC 10)	Unterstützt	Unterstützt
  2012 (VC 11)	Unterstützt	Nicht unterstützt
  2013 (VC 12)	Unterstützt	Nicht unterstützt
  2015 und 2017 (VC 14)	Unterstützt	Unterstützt

  Hinweis: In allen Fällen müssen Sie eine Verknüpfung zur neuesten öffentlich verfügbaren CRT herstellen.

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

• Ihre Anwendung verwendet eine Abhängigkeit im Ordner „System32/SysWOW64“. Damit diese DLL-Dateien funktionieren, müssen Sie sie im virtuellen Dateisystem Ihres Windows-App-Pakets einschließen. Dadurch wird sichergestellt, dass sich die Anwendung verhält, als ob die DLL-Dateien im Ordner System32/SysWOW64 installiert wären. Erstellen Sie im Stammverzeichnis des Pakets einen Ordner namens VFS. Erstellen Sie in diesem Ordner einen SystemX64- und einen SystemX86-Ordner. Legen Sie dann die 32-Bit-Version der DLL im Ordner SystemX86 und die 64-Bit-Version im Ordner SystemX64 ab.

• Ihre App verwendet ein VCLibs-Frameworkpaket. Wenn Sie eine C++ Win32-Anwendung konvertieren, müssen Sie die Bereitstellung der Visual C++ Runtime übernehmen. Visual Studio 2019 und das Windows SDK enthalten die neuesten Frameworkpakete für Version 11.0, 12.0 und 14.0 der Visual C++ Runtime in den folgenden Ordnern:

  • VC 14.0-Frameworkpakete: C:\Programme (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs.Desktop\14.0

  • VC 12.0-Frameworkpakete: C:\Programme (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs.Desktop.120\14.0

  • VC 11.0-Frameworkpakete: C:\Programme (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs.Desktop.110\14.0

  Um eines dieser Pakete zu verwenden, müssen Sie auf das Paket als Abhängigkeit in Ihrem Paketmanifest verweisen. Wenn Kunden die Einzelhandelsversion Ihrer Anwendung aus dem Microsoft Store installieren, wird das Paket zusammen mit Ihrer Anwendung aus dem Store installiert. Die Abhängigkeiten werden nicht installiert, wenn Sie Ihre Anwendung querladen. Um die Abhängigkeiten manuell zu installieren, müssen Sie das entsprechende Frameworkpaket mit dem entsprechenden APPX-Paket für x86, x64 oder ARM installieren, das sich in den oben aufgeführten Installationsordnern befindet.

  So verweisen Sie auf ein Visual C++ Runtime-Frameworkpaket in Ihrer Anwendung

  1. Wechseln Sie zum oben aufgeführten Installationsordner des Frameworkpakets für die von Ihrer Anwendung verwendete Version der Visual C++ Runtime.

  2. Öffnen Sie die Datei „SDKManifest.xml“ in diesem Ordner, suchen Sie das Attribut FrameworkIdentity-Debug oder FrameworkIdentity-Retail (je nachdem, ob Sie die Debug- oder die Einzelhandelsversion der Runtime verwenden), und kopieren Sie die Werte Name und MinVersion aus diesem Attribut. Hier ist z. B. das Attribut FrameworkIdentity-Retail für das aktuelle VC 14.0-Frameworkpaket.

     FrameworkIdentity-Retail = "Name = Microsoft.VCLibs.140.00.UWPDesktop, MinVersion = 14.0.27323.0, Publisher = 'CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US'"
     

  3. Fügen Sie im Paketmanifest für Ihre Anwendung das folgende <PackageDependency>-Element unter dem <Dependencies>-Knoten hinzu. Stellen Sie sicher, dass Sie die Werte Name und MinVersion durch die Werte ersetzen, die Sie im vorherigen Schritt kopiert haben. Das folgende Beispiel gibt eine Abhängigkeit für die aktuelle Version des VC 14.0-Frameworkpakets an.

     <PackageDependency Name="Microsoft.VCLibs.140.00.UWPDesktop" MinVersion="14.0.27323.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
     

• Ihre Anwendung enthält eine angepasste Sprungliste. Bei der Verwendung von Sprunglisten müssen mehrere Probleme und Vorsichtsmaßnahme berücksichtigt werden.

  • Die Architektur der App passt nicht zum Betriebssystem. Wenn die Anwendungs- und die Betriebssystemarchitektur nicht übereinstimmen (z. B. eine x86-Anwendung unter einem x64-Windows) funktionieren Sprunglisten derzeit nicht ordnungsgemäß. Zurzeit gibt es keine Umgehung. Sie können die Anwendung nur mit einer übereinstimmenden Architektur neu kompilieren.

  • Ihre Anwendung erstellt Sprunglisteneinträge und ruft ICustomDestinationList::SetAppID oder SetCurrentProcessExplicitAppUserModelID auf. Legen Sie die AppID nicht programmgesteuert im Code fest. Das führt dazu, dass die Sprunglisteneinträge nicht angezeigt werden. Wenn Ihre Anwendung eine benutzerdefinierte ID benötigt, geben Sie sie mithilfe der Manifestdatei an. Anweisungen finden Sie unter Manuelles Verpacken einer Desktopanwendung. Die AppID für die Anwendung wird im Abschnitt YOUR_PRAID_HERE angegeben.

  • Ihre Anwendung fügt einen Sprunglistenshell-Link hinzu, der auf eine ausführbare Datei im Paket verweist. Sie können ausführbare Dateien im Paket nicht direkt aus einer Sprungliste starten (mit Ausnahme des absoluten Pfads einer eigenen EXE-Datei einer App). Registrieren Sie stattdessen einen App-Ausführungsalias (mit dem die verpackte Desktopanwendung über ein Schlüsselwort gestartet werden kann, als befände sie sich im PFAD), und legen Sie den Linkzielpfad stattdessen auf den Alias fest. Weitere Informationen zur Verwendung der appExecutionAlias-Erweiterung finden Sie unter Integrieren Ihrer Desktopanwendung in Windows 10. Hinweis: Wenn Ressourcen des Links in der Sprungliste der ursprünglichen EXE-Datei entsprechen sollen, müssen Sie Ressourcen wie das Symbol mit SetIconLocation und den Anzeigenamen mit PKEY_Title festlegen – genau wie für andere benutzerdefinierte Einträge.

  • Ihre Anwendung fügt Sprunglisteneinträge hinzu, die auf Ressourcen im Paket Ihrer App nach absoluten Pfaden verweisen. Der Installationspfad der Anwendung ändert sich möglicherweise, wenn Pakete aktualisiert werden. Dadurch ändert sich auch der Ort der Ressourcen (z. B. Symbole, Dokumente, ausführbare Dateien usw.). Falls Sprunglisteneinträge auf derartige Ressourcen nach absoluten Pfaden verweisen, muss die Anwendung ihre Sprungliste in regelmäßigen Abständen (z. B. beim Anwendungsstart) aktualisieren, um eine ordnungsgemäße Auflösung der Pfade sicherzustellen. Alternativ können Sie stattdessen die Windows.UI.StartScreen.JumpList-APIs von UWP verwenden. Damit können Sie mithilfe des paketbezogenen ms-Resource-URI-Schemas (das auch Sprache, DPI und hohen Kontrast berücksichtigt) auf Zeichenfolgen- und Bildressourcen verweisen.

• Ihre Anwendung startet ein Hilfsprogramm zum Ausführen von Aufgaben. Vermeiden Sie das Starten von Befehlshilfsprogrammen wie PowerShell und Cmd.exe. Wenn Benutzer Ihre Anwendung auf einem System mit Windows 10 S installieren, wird Ihre Anwendung nicht in der Lage sein, sie alle zu starten. Die kann die Übermittlung Ihre Anwendung an den Microsoft Store blockieren, da alle Übermittlung an den Microsoft Store mit Windows 10 S kompatibel sein müssen.

  Das Starten eines Hilfsprogramms kann oft eine bequeme Methode für das Abrufen von Informationen aus dem Betriebssystem, Zugreifen auf die Registrierung oder das Zugreifen auf Systemfunktionen bereitstellen. Sie können jedoch stattdessen UWP-APIs verwenden, um diese Aufgaben auszuführen. Diese APIs sind leistungsstärker, da sie für die Ausführung keine separate ausführliche Datei benötigen. Darüber hinaus hindern sie eine Ausführung der Anwendung außerhalb des Pakets. Das Design der App bleibt im Einklang mit der Netzwerkisolation, Vertrauensstellung und Sicherheit, die zu einer von Ihnen verpackten Anwendung gehören, und Ihre Anwendung verhält sich erwartungsgemäß auf Systemen mit Windows 10 S.

• Ihre Anwendung hostet Add-Ins, -Plug-Ins oder Erweiterungen. In vielen Fällen werden Erweiterungen im COM-Stil wahrscheinlich weiterhin funktionieren, sofern die Erweiterung nicht verpackt wurde und sie als vertrauenswürdig installiert wurde. Grund dafür ist, dass die Installationsprogramme ihre vertrauenswürdigen Funktionen verwenden können, um die Registrierung zu bearbeiten und Erweiterungsdateien an beliebigen Stellen zu platzieren, damit die Hostanwendung sie findet.

  Wenn diese Erweiterungen jedoch verpackt und als Windows-App-Paket installiert werden, werden sie nicht funktionieren, da jedes Paket (die Hostanwendung und die Erweiterung) voneinander isoliert sein wird. Weitere Informationen zur Isolierung von Anwendungen vom System finden Sie unter Hinter den Kulissen der Desktop-Brücke.

  Alle Anwendungen und Erweiterungen, die Benutzer auf einem System mit Windows 10 S installieren, müssen als Windows-App-Pakete installiert werden. Wenn Sie also beabsichtigen, Ihre Erweiterungen zu verpacken oder Sie Ihren Mitwirkenden eine Verpackung empfehlen möchten, sollten Sie sich überlegen, wie Sie die Kommunikation zwischen dem Hostanwendungspaket und der Erweiterungspakete vereinfachen können. Eine Möglichkeit wäre die Verwendung eines App-Diensts.

• Ihre Anwendung generiert Code. Die Anwendung kann Code generieren, den sie im Arbeitsspeicher verwendet. Vermeiden Sie es jedoch, Code auf einen Datenträger zu schreiben, da der Windows-App-Zertifizierungsprozess diesen Code vor der App-Übermittlung nicht überprüfen kann. Darüber hinaus werden Apps, die Code auf den Datenträger Schreiben, nicht ordnungsgemäß auf Systemen mit Windows 10 S ausgeführt. Dadurch kann die Übermittlung Ihrer Anwendung an den Microsoft Store blockiert werden, da alle Übermittlungen an den Microsoft Store mit Windows 10 S kompatibel sein müssen.

Wichtig

Nachdem Sie das Windows-App-Paket erstellt haben, testen Sie Ihre Anwendung, um sicherzustellen, dass sie auf Systemen funktioniert, auf denen Windows 10 S ausgeführt wird. Alle an den Microsoft Store übermittelten Apps müssen mit Windows 10 S-Apps kompatibel sein. Apps, die nicht kompatibel sind, werden nicht im Store akzeptiert. Weitere Informationen findest du unter Testen deiner Windows-App für Windows 10 S.