IDs des Anwendungsbenutzermodells (AppUserModelIDs)

Anwendungsbenutzermodell-IDs (AppUserModelIDs) werden umfassend von der Taskleiste in Windows 7- und höher-Systemen 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 oder eine Anwendung besitzt, die in einem Hostprozess ausgeführt wird, muss jedoch möglicherweise explizit selbst identifiziert werden, sodass 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 SHAddToRecentDocs verwendet werden.

Hinweis

Wenn Anwendungen keine explizite AppUserModelID besitzen, müssen sie IApplicationDestinations, IApplicationDocumentLists und ICustomDestinationList-Methoden sowie SHAddToRecentDocs aus der Anwendung aufrufen. Wenn diese Methoden von einem anderen Prozess aufgerufen werden, z. B. ein Installationsprogramm oder eine Deinstallation, kann das System die richtige AppUserModelID nicht generieren, und diese Aufrufe haben keine Auswirkung.

 

In den folgenden Elementen werden allgemeine Szenarien beschrieben, die eine explizite AppUserModelID erfordern. Sie weisen auch auf Fälle hin, in denen mehrere explizite AppUserModelIDs verwendet werden sollen.

  • Eine einzelne ausführbare Datei mit einer Benutzeroberfläche mit mehreren Modi, die dem Benutzer als separate Anwendungen angezeigt werden, sollten 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 anheften und starten können, unabhängig von der Restlichen Anwendung ü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 Verknüpfungen verwenden. Beispielsweise verfügt Windows Internet Explorer über unterschiedliche Tastenkombinationen für unterschiedliche Modi (z. B. starten ohne Add-Ons), aber alle 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 als Hostanwendung registriert werden, nachdem sie jeder wahrgenommenen Erfahrung, die sie hostet, verschiedene AppUserModelIDs zuweisen kann. Alternativ kann der Hostprozess dem gehosteten Programm erlauben, seine AppUserModelIDs festzulegen. 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 Benutzererfahrung des Hostprozesses ohne den Zielinhalt. Beispiele sind Windows remote applications Integrated Lokal (RAIL)-Anwendungen, die Java-Runtime, RunDLL32.exe oder DLLHost.exe.

    Bei vorhandenen gehosteten 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 die gleiche AppUserModelID auf jeden Prozess angewendet haben. Beispiele sind Spiele mit einem Startprogrammprozess (verkettet) und Microsoft Windows Medienwiedergabe, die eine erste Ausführung/Setup-Erfahrung in einem Prozess und die Hauptanwendung, die in einem anderen Prozess ausgeführt wird (kooperativ).

  • 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 seinen 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, um die Umgebung einzurichten und dann den Vorgang an einen anderen Prozess zu leiten, 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 jede dieser Teile der Virtualisierungsumgebung angewendet werden.

    Ein Beispiel für diese Situation ist das ClickOnce Framework, das AppUserModelIDs im Namen 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 mit den von ClickOnce zugewiesenen AppUserModelIDs in Konflikt tritt und zu unerwarteten Ergebnissen führt.

So erstellen Sie eine Application-Defined AppUserModelID

Eine Anwendung muss die AppUserModelID in folgendem Formular bereitstellen. Es kann nicht mehr als 128 Zeichen enthalten und keine Leerzeichen enthalten. Jeder Abschnitt sollte pascal-cased sein.

CompanyName.ProductName.SubProduct.VersionInformation

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

Where to Assign an AppUserModelID

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

  • 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 Eigenschafteneinstellungsmechanismen, die während der Shell verwendet werden. Auf diese Weise kann die Taskleiste die richtige Verknüpfung anheften und sicherstellen, dass Fenster, die zum Prozess gehören, entsprechend dieser Taskleistenschaltfläche zugeordnet sind.

    Hinweis

    Die System.AppUserModel.ID-Eigenschaft sollte auf eine Verknüpfung angewendet werden, wenn diese Verknüpfung erstellt wird. Wenn Sie das Microsoft Windows Installer (MSI) zum Installieren der Anwendung verwenden, kann die MsiShortcutProperty-Tabelle die AppUserModelID auf die Verknüpfung angewendet werden, 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 verschiedene Fenster, die einem Prozess gehören, unterschiedliche AppUserModelIDs zum Steuern der Taskleistengruppierung erfordern, 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 seine AppUserModelID während der anfänglichen Startroutine einer Anwendung festzulegen, bevor die Anwendung eine Benutzeroberfläche vorgibt, eine Manipulation der Sprunglisten vornimmt oder einen Aufruf von SHAddToRecentDocs auslöst (oder bewirkt, dass das System aufgerufen wird).

    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:

    Hinweis

    Wenn eine Verknüpfung zum Starten der Anwendung vorhanden ist, sollte eine Anwendung die AppUserModelID als Eigenschaft der Verknüpfung anwenden, anstatt die Relaunch-Eigenschaften 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 Eigenschaft "System.AppUserModel.PreventPinning" verwenden, um anzugeben, dass sie nicht zum Anheften oder Neustarten verfügbar sein sollte.

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

  • Bei der Dateizuordnungsregistrierung (über seine ProgID) verwendet die Anwendung die automatisch generierten Zuletzt generierten oder häufig generierten Ziellisten des Systems. Auf diese Zuordnungsinformationen wird von SHAddToRecentDocs verwiesen. Diese Informationen werden auch beim Hinzufügen von IShellItem-Zielen zu benutzerdefinierten Sprunglisten über ICustomDestinationList::AppendCategory verwendet.

  • In jedem Aufruf führt die Anwendung direkt zu SHAddToRecentDocs. Wenn die Anwendung vom allgemeinen Dateidialogfeld abhängt, um Aufrufe an SHAddToRecentDocs im Auftrag vorzunehmen, können diese Aufrufe die explizite AppUserModelID nur ableiten, wenn die AppUserModelID für den gesamten Prozess festgelegt ist. Wenn die Anwendung AppUserModelIDs auf seinen Fenstern anstelle des Prozesses festlegt, muss die Anwendung alle Aufrufe an SHAddToRecentDocs selbst vornehmen, mit seiner expliziten AppUserModelID sowie verhindern, dass das allgemeine Dateidialogfeld eigene Aufrufe tätigen kann. Dies muss erfolgen, wenn ein Element geöffnet wird, um sicherzustellen, dass die zuletzt verwendeten oder häufigen Abschnitte der Sprungliste der Anwendung korrekt sind.

In den folgenden Elementen werden allgemeine Szenarien beschrieben, in denen explizite AppUserModelIDs in diesen Szenarien angewendet werden sollen.

  • 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 die gleiche 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 gleichen 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 (im Startmenü , auf dem Desktop oder an anderer Stelle) starten kann, 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 von einer Anwendung ausgeführt wird, 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 abgeleitet werden. 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 SHAddToRecentDocs explizit aufrufen und die richtige AppUserModelID bereitstellen. Darüber hinaus muss die Anwendung verhindern, dass das allgemeine Dateidialogfeld SHAddToRecentDocs im Namen aufruft, indem sie das FOS_DONTADDTORECENT Flag in der GetOptions-Methode von IFileOpenDialog oder IFileSaveDialog festlegen.

Registrieren einer Anwendung als Hostprozess

Eine Anwendung kann den IsHostApp-Registrierungseintrag so festlegen, dass 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 der Eintrag keinen Wert zugewiesen wird; Sein Vorhandensein ist alles, was erforderlich ist. Es handelt sich um einen REG_NULL Wert.

HKEY_CLASSES_ROOT
   Applications
      example.exe
         IsHostApp

Wenn entweder der Prozess selbst oder die Verknüpfungsdatei, die zum Starten des Prozesses verwendet wird, eine explizite AppUserModelID aufweist, 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 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 Pin/Unpin-Option oder ein Startsymbol für eine neue Instanz des Prozesses an. Der Prozess ist auch nicht für die Aufnahme in die Liste der am häufigsten verwendeten Startmenüs (MFU) berechtigt. 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 Pinning und zuletzt verwendete/häufige Listen der Taskleiste

Anwendungen, Prozesse und Fenster können sich entscheiden, sich für das Anheften an die Taskleiste oder die Aufnahme in die MFU-Liste des Startmenüs nicht verfügbar zu machen. Dazu 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 die Anwesenheit 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 berechtigt für die MFU-Liste des Startmenüs .

  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 MFU-Liste des Startmenüs 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.

Hinweis

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

 

Wenn eine der folgenden Zeichenfolgen unabhängig vom Fall im Tastenkombinationsnamen 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
  • Remove (Entfernen)
  • Einrichten
  • Support
  • Neuerungen

Die folgende Liste der Programme ist nicht anheftbar und wird von 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.

Hinweis

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

 

HKEY_LOCAL_MACHINE
   Software
      Microsoft
         Windows
            CurrentVersion
               Explorer
                  FileAssociation
                     AddRemoveApps
                     HostApps

SetCurrentProcessExplicitAppUserModelID

GetCurrentProcessExplicitAppUserModelID

Taskleistenerweiterungen

ICustomDestinationList::SetAppID

IApplicationDocumentLists::SetAppID

IApplicationDestinations::SetAppID

SHGetPropertyStoreForWindow