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.

  • Ihre Anwendung erfordert einen Kernelmodustreiber oder einen Windows-Dienst. MSIX unterstützt keinen Kernelmodustreiber oder einen Windows-Dienst, der unter einem Systemkonto ausgeführt werden muss. Verwenden Sie anstelle eines Windows-Diensts eine Hintergrundaufgabe.

  • Ihre App-Module werden im Prozess für Prozesse geladen, die nicht im Windows-App-Paket enthalten sind. Dies ist nicht zulässig. Prozessinterne Erweiterungen, beispielsweise Shellerweiterungen, werden nicht unterstützt. Wenn zwei Apps in einem Paket enthalten sind, können Sie jedoch die prozessübergreifende Kommunikation zwischen diesen verwenden.

  • 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. Sie können keine benutzerdefinierten Anwendungsbenutzermodell-IDs definieren.

  • 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 Ihre 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 stattdessen eine andere Möglichkeit finden, um das zu erreichen, wozu Sie HKLM verwendet haben, beispielsweise Schreiben in HKEY_CURRENT_USER (HKCU).

  • Ihre Anwendung verwendet einen DDEEXEC-Registrierungsunterschlüssel zum Starten einer anderen App. Verwenden Sie stattdessen einen der DelegateExecute-Verbhandler genau wie von den verschiedenen Activatable*-Erweiterungen in dem App-Paketmanifest konfiguriert.

  • 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 verschiedene Methoden für die prozessübergreifende 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. Dies wird nicht unterstützt. Sie müssen daher einen anderen Speicherort wählen, z. B. den lokalen App-Datenspeicher.

  • 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. Weitere Informationen 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. Dies bedeutet, dass Interoperabilitätsszenarien 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 Microsoft C/C++-Laufzeitbibliothek enthält Routinen für die 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.

    Unterstützung in früheren Versionen von Visual Studio variiert. Weitere Informationen finden Sie in der folgenden Tabelle:

    Version von Visual StudioDynamische VerknüpfungStatische Verknüpfung
    2005 (VC 8)Nicht unterstützt.Unterstützt
    2008 (VC 9)Nicht unterstützt.Unterstützt
    2010 (VC 10)UnterstütztUnterstützt
    2012 (VC 11)UnterstütztNicht unterstützt.
    2013 (VC 12)UnterstütztNicht unterstützt.
    2015 und 2017 (VC 14)UnterstütztUnterstü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. 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.

  • 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 Stammordner des Pakets einen Ordner mit dem Namen VFS. Erstellen Sie innerhalb dieses Ordners die Ordner SystemX64 und SystemX86. Platzieren Sie die 32-Bit-Version Ihrer DLL-Datei im Ordner SystemX86 und die 64-Bit-Version im Ordner SystemX64.

  • 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 „AppID“ nicht programmgesteuert im Code fest. Andernfalls werden die Sprunglisteneinträge nicht angezeigt. Wenn Ihre Anwendung eine benutzerdefinierte ID benötigt, geben Sie sie mithilfe der Manifestdatei an. Anweisungen finden Sie unter Manuelles Verpacken einer Desktopanwendung. Die App-ID für die Anwendung ist 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 in Ihrem 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 müssen, müssen Sie Ressourcen wie etwa das Symbol mithilfe von SetIconLocation und den Anzeigenamen mit „PKEY_Title“ festlegen (wie bei anderen benutzerdefinierten Einträgen).

    • 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. Sie können stattdessen auch die UWP-Windows.UI.StartScreen.JumpList-APIs verwenden. Diese APIs ermöglichen den Verweis auf Zeichenfolgen- und Bildressourcen mithilfe des relativen ms-resource-URI-Paketschemas (das zudem Sprache, DPI und hohen Kontrast berücksichtigt).

  • 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. Ihre 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 finden Sie unter Testen Ihrer Windows-App für Windows 10 S.