Freigeben über

Anwendungsbenutzermodell-IDs (AppUserModelIDs)

  • Artikel

Anwendungsbenutzermodell-IDs (AppUserModelIDs) werden von der Taskleiste in Windows 7 und höheren Systemen umfassend verwendet, um Prozesse, Dateien und Fenster einer bestimmten Anwendung zuzuordnen. In einigen Fällen reicht es aus, auf die interne AppUserModelID zu verlassen, die einem Prozess vom System zugewiesen ist. Eine Anwendung, die mehrere Prozesse besitzt oder eine Anwendung, die in einem Hostprozess ausgeführt wird, muss sich jedoch möglicherweise explizit identifizieren, damit sie ihre ansonsten unterschiedlichen Fenster unter einer einzelnen Taskleistenschaltfläche gruppieren und den Inhalt der Sprungliste dieser Anwendung steuern kann.

Application-Defined und System-Defined AppUserModelIDs

Einige Anwendungen deklarieren keine explizite AppUserModelID. Sie sind optional. In diesem Fall verwendet das System eine Reihe von Heuristiken, um eine interne AppUserModelID zuzuweisen. Es gibt jedoch einen Leistungsvorteil, um diese Berechnungen zu vermeiden, und eine explizite AppUserModelID ist die einzige Möglichkeit, eine genaue Benutzererfahrung zu gewährleisten. Daher wird dringend empfohlen, eine explizite ID festzulegen. Anwendungen können keine vom System zugewiesene AppUserModelID abrufen.

Wenn eine Anwendung eine explizite AppUserModelID verwendet, muss sie auch allen ausgeführten Fenstern oder Prozessen, Verknüpfungen und Dateizuordnungen dieselbe AppUserModelID zuweisen. Außerdem muss appUserModelID beim Anpassen der Sprungliste über ICustomDestinationList-und in allen Aufrufen von SHAddToRecentDocsverwendet werden.

Anmerkung

Wenn Anwendungen nicht über eine explizite AppUserModelID verfügen, müssen sie IApplicationDestinations, IApplicationDocumentListsund ICustomDestinationList Methoden sowie SHAddToRecentDocs aus der Anwendung aufrufen. Wenn diese Methoden von einem anderen Prozess aufgerufen werden, z. B. ein Installationsprogramm oder Deinstallationsprogramm, kann das System die richtige AppUserModelID nicht generieren, und diese Aufrufe haben keine Auswirkungen.

 

Die folgenden Elemente beschreiben allgemeine Szenarien, für die eine explizite AppUserModelID erforderlich ist. Sie verweisen auch auf Fälle, in denen mehrere explizite AppUserModelIDs verwendet werden sollten.

  • Eine einzelne ausführbare Datei mit einer Benutzeroberfläche mit mehreren Modi, die dem Benutzer als separate Anwendungen angezeigt werden, sollte jedem Modus unterschiedliche AppUserModelIDs zuweisen. Beispielsweise sollte ein Teil einer Anwendung, die Benutzern als unabhängige Erfahrung angezeigt wird, die sie separat von der Taskleiste an die Taskleiste anheften und starten können, über eine eigene AppUserModelID verfügen, getrennt von der Hauptoberfläche.

  • Mehrere Tastenkombinationen mit unterschiedlichen Argumenten, die alle dazu führen, was der Benutzer als dieselbe Anwendung sieht, sollte eine AppUserModelID für alle Tastenkombinationen verwenden. Beispielsweise verfügt Windows Internet Explorer über unterschiedliche Tastenkombinationen für verschiedene Modi (z. B. starten ohne Add-Ons), aber sie sollten dem Benutzer als einzelne Internet Explorer-Instanz angezeigt werden.

  • Eine ausführbare Datei, die als Hostprozess fungiert und Zielinhalte als Anwendung ausführt, muss sich als Hostanwendungregistrieren. Danach kann sie jeder wahrgenommenen Erfahrung, die sie hostet, verschiedene AppUserModelIDs zuweisen. Alternativ kann der Hostprozess zulassen, dass das gehostete Programm seine AppUserModelIDs festlegen kann. In beiden Fällen muss der Hostprozess einen Datensatz der Quelle der AppUserModelIDs speichern, entweder selbst oder die gehostete Anwendung. In diesem Fall gibt es keine primäre Benutzeroberfläche des Hostprozesses ohne den Zielinhalt. Beispiele sind Lokal integrierte Windows Remote Applications (RAIL)-Anwendungen, die Java-Runtime, RunDLL32.exeoder DLLHost.exe.

    Im Falle vorhandener gehosteter Anwendungen versucht das System, individuelle Erfahrungen zu identifizieren, aber neue Anwendungen sollten explizite AppUserModelIDs verwenden, um die beabsichtigte Benutzererfahrung zu gewährleisten.

  • Kooperative oder verkettete Prozesse, die für den Benutzer Teil derselben Anwendung sind, sollten dieselbe AppUserModelID auf jeden Prozess angewendet haben. Beispiele hierfür sind Spiele mit einem Startprogrammprozess (verkettet) und Microsoft Windows Media Player, das eine Erste Ausführungs-/Setup-Erfahrung aufweist, die in einem Prozess ausgeführt wird, und die Hauptanwendung, die in einem anderen Prozess (kooperativ) ausgeführt wird.

  • Eine Shell-Namespaceerweiterung, die als separate Anwendung fungiert, um mehr als das Durchsuchen und Verwalten von Inhalten in Windows Explorer zu ermöglichen, sollte eine AppUserModelID in ihren Ordnereigenschaften zuweisen. Ein Beispiel ist die Systemsteuerung.

  • In einer Virtualisierungsumgebung wie einem Bereitstellungsframework sollte die Virtualisierungsumgebung jeder anwendung, die sie verwaltet, unterschiedlichen AppUserModelIDs zuweisen. In diesen Fällen verwendet ein Anwendungsstartprogramm einen zwischengeschalteten Prozess zum Einrichten der Umgebung und übergibt den Vorgang dann an einen anderen Prozess, um die Anwendung auszuführen. Beachten Sie, dass das System den ausgeführten Zielprozess nicht mit der Verknüpfung verknüpfen kann, da die Verknüpfung auf den zwischengeschalteten Prozess verweist.

    Wenn eine Anwendung über mehrere Fenster, Verknüpfungen oder Prozesse verfügt, sollte die appUserModelID dieser Anwendung auch auf die einzelnen Teile der Virtualisierungsumgebung angewendet werden.

    Ein Beispiel für diese Situation ist das ClickOnce-Framework, das AppUserModelIDs im Auftrag der von ihm verwalteten Anwendungen ordnungsgemäß zuweist. Wie in allen solchen Umgebungen sollten anwendungen, die von ClickOnce bereitgestellt und verwaltet werden, keine expliziten AppUserModelIDs selbst zuweisen, da dies konfliktet mit den von ClickOnce zugewiesenen AppUserModelIDs und zu unerwarteten Ergebnissen führt.

So erstellen Sie eine Application-Defined AppUserModelID

Eine Anwendung muss ihre AppUserModelID in der folgenden Form bereitstellen. Sie darf maximal 128 Zeichen enthalten und darf keine Leerzeichen enthalten. Jeder Abschnitt sollte pascal-cased sein.

CompanyName.ProductName.SubProduct.VersionInformation

CompanyName und ProductName sollten immer verwendet werden, während die SubProduct und VersionInformation Teile optional sind und von den Anforderungen der Anwendung abhängen. SubProduct ermöglicht eine Hauptanwendung, die aus mehreren Unteranwendungen besteht, eine separate Taskleistenschaltfläche für jede Unteranwendung und die zugehörigen Fenster bereitzustellen. VersionInformation ermöglicht die Koexistenz von zwei Versionen einer Anwendung, während sie als diskrete Entitäten betrachtet wird. Wenn eine Anwendung nicht auf diese Weise verwendet werden soll, sollte die VersionInformation weggelassen werden, damit eine aktualisierte Version dieselbe AppUserModelID wie die ersetzte Version verwenden kann.

Speicherort für das Zuweisen einer AppUserModelID

Wenn eine Anwendung eine oder mehrere explizite AppUserModelIDs verwendet, sollte sie diese AppUserModelIDs an den folgenden Speicherorten und Situationen anwenden:

  • In der System.AppUserModel.ID Eigenschaft der Anwendungsverknüpfungsdatei. Eine Verknüpfung (als IShellLink-, CLSID_ShellLink oder eine .lnk-Datei) unterstützt Eigenschaften über IPropertyStore- und andere Mechanismen für eigenschafteneinstellung, die in der gesamten Shell verwendet werden. Auf diese Weise kann die Taskleiste die richtige Verknüpfung zum Anheften identifizieren und sicherstellen, dass Fenster, die zum Prozess gehören, entsprechend dieser Taskleistenschaltfläche zugeordnet sind.

    Anmerkung

    Die System.AppUserModel.ID-Eigenschaft sollte auf eine Verknüpfung angewendet werden, wenn diese Verknüpfung erstellt wird. Wenn Sie microsoft Windows Installer (MSI) zum Installieren der Anwendung verwenden, kann die MsiShortcutProperty- Tabelle die AppUserModelID auf die Verknüpfung anwenden, wenn sie während der Installation erstellt wird.

     

  • Als Eigenschaft eines der ausgeführten Fenster der Anwendung. Dies kann auf eine von zwei Arten festgelegt werden:

    1. Wenn für unterschiedliche Fenster im Besitz eines Prozesses unterschiedliche AppUserModelIDs zum Steuern der Taskleistengruppierung erforderlich sind, verwenden Sie SHGetPropertyStoreForWindow), um den Eigenschaftenspeicher des Fensters abzurufen und die AppUserModelID als Fenstereigenschaft festzulegen.
    2. Wenn alle Fenster im Prozess dieselbe AppUserModelID verwenden, legen Sie die AppUserModelID für den Prozess fest, obwohl SetCurrentProcessExplicitAppUserModelID. Eine Anwendung muss SetCurrentProcessExplicitAppUserModelID aufrufen, um die AppUserModelID während der anfänglichen Startroutine einer Anwendung festzulegen, bevor die Anwendung eine Benutzeroberfläche darstellt, eine Manipulation der Sprunglisten vorgibt, oder führt einen Aufruf des Systems an SHAddToRecentDocs.

    Eine AppUserModelID auf Fensterebene überschreibt eine AppUserModelID auf Prozessebene.

    Wenn eine Anwendung eine explizite AppUserModelID auf Fensterebene festlegt, kann die Anwendung die Besonderheiten des Neustartbefehls für die Taskleistenschaltfläche bereitstellen. Um diese Informationen zu liefern, werden die folgenden Eigenschaften verwendet:

    Anmerkung

    Wenn eine Verknüpfung zum Starten der Anwendung vorhanden ist, sollte eine Anwendung die AppUserModelID als Eigenschaft der Verknüpfung anwenden, anstatt die Neustarteigenschaften zu verwenden. In diesem Fall werden die Befehlszeile, das Symbol und der Text der Verknüpfung verwendet, um dieselben Informationen wie die Relaunch-Eigenschaften zu liefern.

     

    Eine explizite AppUserModelID auf Fensterebene kann auch die System.AppUserModel.PreventPinning-Eigenschaft verwenden, um anzugeben, dass sie nicht zum Anheften oder Starten verfügbar sein soll.

  • Rufen Sie in einem Aufruf zum Anpassen oder Aktualisieren (ICustomDestinationList), abrufen (IApplicationDocumentLists) oder löschen (IApplicationDestinations) die Sprungliste der Anwendung.

  • Bei der Dateizuordnungsregistrierung (über die ProgID-), wenn die Anwendung die automatisch generierte Zuletzt verwendete oder Häufig Ziellisten verwendet. Auf diese Zuordnungsinformationen wird von SHAddToRecentDocsverwiesen. Diese Informationen werden auch beim Hinzufügen von IShellItem- Zielen zu benutzerdefinierten Sprunglisten über ICustomDestinationList::AppendCategoryverwendet.

  • In jedem Aufruf führt die Anwendung direkt an SHAddToRecentDocs. Wenn die Anwendung vom allgemeinen Dateidialogfeld abhängig ist, um Aufrufe an SHAddToRecentDocs- im Namen durchzuführen, können diese Aufrufe die explizite AppUserModelID nur ableiten, wenn die AppUserModelID für den gesamten Prozess festgelegt ist. Wenn die Anwendung AppUserModelIDs in seinen Fenstern anstelle des Prozesses festlegt, muss die Anwendung alle Aufrufe an SHAddToRecentDocs selbst mit seiner expliziten AppUserModelID durchführen und verhindern, dass das allgemeine Dateidialogfeld eigene Aufrufe macht. Dies muss bei jedem Öffnen eines Elements erfolgen, um sicherzustellen, dass die Zuletzt verwendete oder Häufig verwendete Abschnitte der Sprungliste der Anwendung korrekt sind.

In den folgenden Elementen werden allgemeine Szenarien beschrieben und wo explizite AppUserModelIDs in diesen Szenarien angewendet werden.

  • Wenn ein einzelner Prozess mehrere Anwendungen enthält, verwenden Sie SHGetPropertyStoreForWindow, um den Eigenschaftenspeicher des Fensters abzurufen und die AppUserModelID als Fenstereigenschaft festzulegen.
  • Wenn eine Anwendung mehrere Prozesse verwendet, wenden Sie die AppUserModelID auf jeden Prozess an. Ob Sie dieselbe AppUserModelID für jeden Prozess verwenden, hängt davon ab, ob jeder Prozess als Teil der Hauptanwendung oder als einzelne Entitäten angezeigt werden soll.
  • Um bestimmte Fenster von einem Satz im selben Prozess zu trennen, verwenden Sie den Eigenschaftenspeicher des Fensters, um eine einzelne AppUserModelID auf diese Fenster anzuwenden, die Sie trennen möchten, und wenden Sie dann eine andere AppUserModelID auf den Prozess an. Jedes Fenster in diesem Prozess, das nicht explizit mit der AppUserModelID auf Fensterebene bezeichnet wurde, erbt die AppUserModelID des Prozesses.
  • Wenn ein Dateityp einer Anwendung zugeordnet ist, weisen Sie die AppUserModelID in der ProgID Registrierung des Dateityps zu. Wenn eine einzelne ausführbare Datei in verschiedenen Modi gestartet wird, die dem Benutzer als unterschiedliche Anwendungen angezeigt werden, ist für jeden Modus eine separate AppUserModelID erforderlich. In diesem Fall müssen mehrere ProgID-Registrierungen für den Dateityp vorhanden sein, jeweils mit einer anderen AppUserModelID.
  • Wenn mehrere Verknüpfungsspeicherorte vorhanden sind, von denen ein Benutzer eine Anwendung starten kann (im Menü Start, auf dem Desktop oder an anderer Stelle), rufen Sie den Eigenschaftenspeicher der Verknüpfung ab, um eine einzelne AppUserModelID auf alle Tastenkombinationen als Verknüpfungseigenschaften anzuwenden.
  • Wenn ein expliziter Aufruf an SHAddToRecentDocs durch eine Anwendung erfolgt, verwenden Sie die AppUserModelID im Aufruf. Wenn das allgemeine Dateidialogfeld zum Öffnen oder Speichern von Dateien verwendet wird, wird SHAddToRecentDocs- vom Dialogfeld im Namen der Anwendung aufgerufen. Dieser Aufruf kann die explizite AppUserModelID aus dem Prozess ableiten. Wenn jedoch eine explizite AppUserModelID als Fenstereigenschaft angewendet wird, kann das allgemeine Dateidialogfeld die richtige AppUserModelID nicht ermitteln. In diesem Fall muss die Anwendung selbst explizit SHAddToRecentDocs aufrufen und sie mit der richtigen AppUserModelID bereitstellen. Darüber hinaus muss die Anwendung verhindern, dass das allgemeine Dateidialogfeld SHAddToRecentDocs- in seinem Auftrag aufruft, indem das FOS_DONTADDTORECENT Flag in der GetOptions- -Methode von IFileOpenDialog oder IFileSaveDialogfestgelegt wird.

Registrieren einer Anwendung als Hostprozess

Eine Anwendung kann den IsHostApp-Registrierungseintrag festlegen, damit der Prozess der ausführbaren Datei von der Taskleiste als Hostprozess betrachtet wird. Dies wirkt sich auf die Gruppierung und die standardmäßigen Sprunglisteneinträge aus.

Das folgende Beispiel zeigt den erforderlichen Registrierungseintrag. Beachten Sie, dass dem Eintrag kein Wert zugewiesen ist; Ihre Anwesenheit ist alles, was erforderlich ist. Es handelt sich um einen REG_NULL Wert.

HKEY_CLASSES_ROOT
   Applications
      example.exe
         IsHostApp

Wenn der Prozess selbst oder die Verknüpfungsdatei, die zum Starten des Prozesses verwendet wird, über eine explizite AppUserModelID verfügt, wird die Hostprozessliste ignoriert, und die Anwendung wird von der Taskleiste als normale Anwendung behandelt. Die ausgeführten Fenster der Anwendung werden unter einer einzelnen Taskleistenschaltfläche gruppiert, und die Anwendung kann an die Taskleiste angeheftet werden.

Wenn nur der ausführbare Name des ausgeführten Prozesses ohne eine explizite AppUserModelID bekannt ist und sich diese ausführbare Datei in der Hostprozessliste befindet, wird jede Instanz des Prozesses als separate Entität für die Taskleistengruppierung behandelt. Die Taskleistenschaltfläche, die einer bestimmten Instanz des Prozesses zugeordnet ist, zeigt keine Option zum Anheften/Lösen oder ein Startsymbol für eine neue Instanz des Prozesses an. Der Prozess ist auch nicht berechtigt, in die Liste der am häufigsten verwendeten Menüs (MFU) Start menüs aufzunehmen. Wenn der Prozess jedoch über eine Verknüpfung gestartet wurde, die Startargumente enthält (in der Regel der Zielinhalt, der als "Anwendung" gehostet werden soll), kann das System die Identität bestimmen und die Anwendung kann angeheftet und neu gestartet werden.

Ausschlusslisten für anheftende Taskleisten und zuletzt verwendete/häufige Listen

Anwendungen, Prozesse und Fenster können sich für das Anheften an die Taskleiste oder die Aufnahme in die MFU-Liste Startmenüs entscheiden. Hierfür gibt es drei Mechanismen:

  1. Fügen Sie den NoStartPage-Eintrag zur Registrierung der Anwendung hinzu, wie hier gezeigt:

    HKEY_CLASSES_ROOT
   Applications
      Example.exe
         NoStartPage

    Die mit dem NoStartPage-Eintrag verknüpften Daten werden ignoriert. Es ist nur das Vorhandensein des Eintrags erforderlich. Daher ist der ideale Typ für NoStartPage REG_NONE.

    Beachten Sie, dass jede Verwendung einer expliziten AppUserModelID den NoStartPage-Eintrag überschreibt. Wenn eine explizite AppUserModelID auf eine Verknüpfung, einen Prozess oder ein Fenster angewendet wird, wird sie anheftbar und für die Startmenü-MFU-Liste berechtigt.

  2. Legen Sie die System.AppUserModel.PreventPinning-Eigenschaft für Fenster und Tastenkombinationen fest. Diese Eigenschaft muss für ein Fenster vor der PKEY_AppUserModel_ID-Eigenschaft festgelegt werden.

  3. Fügen Sie eine explizite AppUserModelID als Wert unter dem folgenden Registrierungsunterschlüssel hinzu, wie hier gezeigt:

    HKEY_LOCAL_MACHINE
   Software
      Microsoft
         Windows
            CurrentVersion
               Explorer
                  FileAssociation
                     NoStartPageAppUserModelIDs
                        AppUserModelID1
                        AppUserModelID2
                        AppUserModelID3

    Jeder Eintrag ist ein REG_NULL Wert mit dem Namen der AppUserModelID. Jede in dieser Liste gefundene AppUserModelID ist nicht anheftbar und kann nicht in die Liste der Start menüs MFU aufgenommen werden.

Beachten Sie, dass bestimmte ausführbare Dateien sowie Verknüpfungen, die bestimmte Zeichenfolgen in ihrem Namen enthalten, automatisch von der Anheftung und Aufnahme in die MFU-Liste ausgeschlossen werden.

Anmerkung

Dieser automatische Ausschluss kann überschrieben werden, indem eine explizite AppUserModelID angewendet wird.

 

Wenn eine der folgenden Zeichenfolgen unabhängig vom Fall im Verknüpfungsnamen enthalten ist, ist das Programm nicht anheftbar und wird nicht in der am häufigsten verwendeten Liste angezeigt (gilt nicht für Windows 10):

  • Dokumentation
  • Hilfe
  • Installieren
  • Weitere Informationen
  • Lesen Sie mich
  • Zuerst lesen
  • Infodatei
  • Entfernen
  • Einrichtung
  • Unterstützen
  • Neuigkeiten

Die folgende Liste der Programme ist nicht anheftbar und wird aus der am häufigsten verwendeten Liste ausgeschlossen.

  • Applaunch.exe
  • Control.exe
  • Dfsvc.exe
  • Dllhost.exe
  • Guestmodemsg.exe
  • Hh.exe
  • Install.exe
  • Isuninst.exe
  • Lnkstub.exe
  • Mmc.exe
  • Mshta.exe
  • Msiexec.exe
  • Msoobe.exe
  • Rundll32.exe
  • Setup.exe
  • St5unst.exe
  • Unwise.exe
  • Unwise32.exe
  • Werfault.exe
  • Winhlp32.exe
  • Wlrmdr.exe
  • Wuapp.exe

Die vorherigen Listen werden in den folgenden Registrierungswerten gespeichert.

Anmerkung

Diese Listen sollten nicht von Anwendungen geändert werden. Verwenden Sie eine der zuvor aufgeführten Ausschlusslistenmethoden für dieselbe Erfahrung.

 

HKEY_LOCAL_MACHINE
   Software
      Microsoft
         Windows
            CurrentVersion
               Explorer
                  FileAssociation
                     AddRemoveApps
                     HostApps

SetCurrentProcessExplicitAppUserModelID

GetCurrentProcessExplicitAppUserModelID-

Taskleistenerweiterungen

ICustomDestinationList::SetAppID

IApplicationDocumentLists::SetAppID

IApplicationDestinations::SetAppID

SHGetPropertyStoreForWindow