Anwendungsbenutzermodell-IDs (AppUserModelIDs)

  • Artikel

Anwendungsbenutzermodell-IDs (AppUserModelIDs) werden von der Taskleiste in Windows 7 und höheren Systemen häufig verwendet, um Prozesse, Dateien und Fenster einer bestimmten Anwendung zuzuordnen. In einigen Fällen reicht es aus, sich auf die interne AppUserModelID zu verlassen, die einem Prozess vom System zugewiesen wurde. 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 einzigen Taskleistenschaltfläche gruppieren und den Inhalt der Sprungliste dieser Anwendung steuern kann.

appUserModelIDs Application-Defined und System-Defined

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, 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 systemseitig 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 diese AppUserModelID beim Anpassen der Sprungliste über ICustomDestinationList und bei allen Aufrufen von SHAddToRecentDocs verwendet werden.

Hinweis

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

 

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 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. Für instance sollte ein Teil einer Anwendung, den Benutzer als unabhängige Benutzeroberfläche sehen, an die sie die Taskleiste anheften und separat vom Rest der Anwendung starten können, über eine eigene AppUserModelID verfügen, die von der Standard-Benutzeroberfläche getrennt ist.

  • Mehrere Tastenkombinationen mit unterschiedlichen Argumenten, die alle zu dem führen, was der Benutzer als die gleiche Anwendung betrachtet, sollten eine AppUserModelID für alle Tastenkombinationen verwenden. Windows Internet Explorer verfügt beispielsweise über verschiedene Tastenkombinationen für verschiedene Modi (z. B. das Starten ohne Add-Ons), aber sie sollten dem Benutzer alle als ein einzelnes Internet-Explorer instance erscheinen.

  • Eine ausführbare Datei, die als Hostprozess fungiert und Zielinhalte als Anwendung ausführt, muss sich als Hostanwendung registrieren. Danach kann sie jeder wahrgenommenen Erfahrung, die sie hostet, unterschiedliche AppUserModelIDs zuweisen. 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 sich selbst oder die gehostete Anwendung. In diesem Fall gibt es keine primäre Benutzeroberfläche des Hostprozesses ohne den Zielinhalt. Beispiele hierfür sind RAIL-Anwendungen (Windows Remote Applications Integrated Lokal), java Runtime, RunDLL32.exe oder DLLHost.exe.

    Bei vorhandenen gehosteten Anwendungen versucht das System, einzelne Erfahrungen zu identifizieren, aber neue Anwendungen sollten explizite AppUserModelIDs verwenden, um die beabsichtigte Benutzererfahrung zu gewährleisten.

  • Für kooperative oder verkettete Prozesse, die für den Benutzer Teil derselben Anwendung sind, sollte die gleiche AppUserModelID auf jeden Prozess angewendet werden. Beispiele hierfür sind Spiele mit einem Startprogrammprozess (verkettet) und Microsoft Windows Medienwiedergabe, die über eine Erstausführungs-/Einrichtungserfahrung in einem Prozess und die Standard Anwendung in einem anderen Prozess (kooperativ) verfügen.

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

  • In einer Virtualisierungsumgebung, z. B. einem Bereitstellungsframework, sollte die Virtualisierungsumgebung jeder von ihr verwalteten Anwendung unterschiedliche 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 dadurch nicht in der Lage ist, den ausgeführten Zielprozess wieder mit der Verknüpfung zu verknüpfen, da die Verknüpfung auf den zwischengeschalteten Prozess verweist.

    Wenn eine Anwendung über mehrere Fenster, Tastenkombinationen oder Prozesse verfügt, sollte die appUserModelID dieser Anwendung auch von der Virtualisierungsumgebung auf jeden dieser Teile 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, selbst keine expliziten AppUserModelIDs zuweisen, da dies zu einem Konflikt mit den von ClickOnce zugewiesenen AppUserModelIDs führt und zu unerwarteten Ergebnissen führt.

Erstellen einer Application-Defined AppUserModelID

Eine Anwendung muss ihre AppUserModelID im folgenden Format angeben. Sie darf nicht mehr als 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 Teile und VersionInformation optional sind und von den Anforderungen der Anwendung abhängen. SubProductermöglicht eine Standard Anwendung, die aus mehreren Unteranwendungen besteht, eine separate Taskleistenschaltfläche für jede Unteranwendung und die zugehörigen Fenster bereitzustellen. VersionInformation ermöglicht die Koexistenz zweier Versionen einer Anwendung, während sie als diskrete Entitäten betrachtet werden. Wenn eine Anwendung nicht auf diese Weise verwendet werden soll, sollte weggelassen VersionInformation werden, damit eine aktualisierte Version dieselbe AppUserModelID wie die ersetzte Version verwenden kann.

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 Verknüpfungsdatei der Anwendung. Eine Verknüpfung (als IShellLink, CLSID_ShellLink oder eine LNK-Datei) unterstützt Eigenschaften über IPropertyStore und andere Eigenschafteneinstellungsmechanismen, die in der shell verwendet werden. Dadurch kann die Taskleiste die richtige Verknüpfung zum Anheften identifizieren und sicherstellen, dass fenster, die zum Prozess gehören, dieser Taskleistenschaltfläche entsprechend zugeordnet sind.

    Hinweis

    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, ermöglicht die MsiShortcutProperty-Tabelle , dass die AppUserModelID auf die Verknüpfung angewendet wird, wenn sie während der Installation erstellt wird.

     

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

    1. Wenn verschiedene Fenster im Besitz eines Prozesses 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 mithilfe von SetCurrentProcessExplicitAppUserModelID fest. Eine Anwendung muss SetCurrentProcessExplicitAppUserModelID aufrufen, um ihre AppUserModelID während der anfänglichen Startroutine einer Anwendung festzulegen, bevor die Anwendung eine Benutzeroberfläche vorstellt, änderungen an ihren Sprunglisten vornimmt oder einen Aufruf von SHAddToRecentDocs vornimmt (oder bewirkt, dass das System diese aufruft).

    Eine AppUserModelID auf Fensterebene überschreibt eine AppUserModelID auf Prozessebene.

    Wenn eine Anwendung eine explizite AppUserModelID auf Fensterebene festlegt, kann die Anwendung die Besonderheiten ihres Neustartbefehls für die Taskleistenschaltfläche angeben. Um diese Informationen anzugeben, 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 Eigenschaften des Neustarts zu verwenden. In diesem Fall werden die Befehlszeile, das Symbol und der Text der Verknüpfung verwendet, um die gleichen Informationen wie die Eigenschaften des Neustarts anzugeben.

     

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

  • In einem Aufruf zum Anpassen oder Aktualisieren (ICustomDestinationList), Abrufen (IApplicationDocumentLists) oder Löschen (IApplicationDestinations) der Sprungliste der Anwendung.

  • In der Dateizuordnungsregistrierung (über die ProgID), wenn die Anwendung die automatisch vom System generierten Ziellisten Zuletzt oderHäufig verwendet. Auf diese Zuordnungsinformationen wird von SHAddToRecentDocs verwiesen. Diese Informationen werden auch beim Hinzufügen von IShellItem-Zielen zu benutzerdefinierten Sprunglisten über ICustomDestinationList::AppendCategory verwendet.

  • Bei jedem Aufruf führt die Anwendung direkt an SHAddToRecentDocs aus. Wenn die Anwendung auf das allgemeine Dateidialogfeld angewiesen ist, um im Namen von SHAddToRecentDocs aufruft , können diese Aufrufe die explizite AppUserModelID nur dann ableiten, wenn die AppUserModelID für den gesamten Prozess festgelegt ist. Wenn die Anwendung AppUserModelIDs in ihren Fenstern und nicht im Prozess festlegt, muss die Anwendung alle Aufrufe von SHAddToRecentDocs selbst mit der expliziten AppUserModelID durchführen und verhindern, dass das allgemeine Dateidialogfeld eigene Aufrufe durchführt. Dies muss jedes Mal erfolgen, wenn ein Element geöffnet wird, um sicherzustellen, dass die Abschnitte Zuletzt verwendet oder Häufig der Sprungliste der Anwendung korrekt sind.

In den folgenden Elementen werden häufige Szenarien beschrieben und beschrieben, wo in diesen Szenarien explizite AppUserModelIDs 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 Standard-Anwendung oder als einzelne Entitäten angezeigt werden soll.
  • Um bestimmte Fenster von einer Gruppe im selben Prozess zu trennen, verwenden Sie den Eigenschaftenspeicher des Fensters, um eine einzelne AppUserModelID auf die 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 einer Anwendung ein Dateityp 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 erscheinen, ist für jeden Modus eine separate AppUserModelID erforderlich. In diesem Fall muss es mehrere ProgID-Registrierungen für den Dateityp geben, die jeweils eine andere AppUserModelID aufweisen.
  • Wenn mehrere Verknüpfungsspeicherorte vorhanden sind, von denen aus ein Benutzer eine Anwendung starten kann (im Startmenü , 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 shAddToRecentDocs von einer Anwendung explizit aufgerufen 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 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 SHAddToRecentDocs explizit aufrufen und mit der richtigen AppUserModelID bereitstellen. Darüber hinaus muss die Anwendung verhindern, dass das Allgemeine Dateidialogfeld SHAddToRecentDocs in seinem Namen aufruft, indem das FOS_DONTADDTORECENT-Flag in der GetOptions-Methode von IFileOpenDialog oder IFileSaveDialog festgelegt wird.

Registrieren einer Anwendung als Hostprozess

Eine Anwendung kann den Registrierungseintrag IsHostApp so festlegen, dass der Prozess dieser 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 wird. sein Vorhandensein ist nur erforderlich. Es handelt sich um einen REG_NULL Wert.

HKEY_CLASSES_ROOT
   Applications
      example.exe
         IsHostApp

Wenn entweder der Prozess selbst oder die Zum Starten des Prozesses verwendete Verknüpfungsdatei 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 instance des Prozesses als separate Entität für die Taskleistengruppierung behandelt. Die Taskleistenschaltfläche, die einem bestimmten instance des Prozesses zugeordnet ist, zeigt keine An-/Ausheftungsoption oder ein Startsymbol für eine neue instance des Prozesses an. Der Prozess kann auch nicht in die MFU-Liste (Most Frequently Used) des Startmenüs aufgenommen werden. 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 Taskleistenhefte und Zuletzt verwendete/häufige Listen

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

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

    HKEY_CLASSES_ROOT
   Applications
      Example.exe
         NoStartPage

    Die dem NoStartPage-Eintrag zugeordneten 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 außer Kraft setzt. Wenn eine explizite AppUserModelID auf eine Verknüpfung, einen Prozess oder ein Fenster angewendet wird, kann sie angeheftet werden und ist für die MFU-Liste startmenüs geeignet.

  2. Legen Sie die System.AppUserModel.PreventPinning-Eigenschaft für Fenster und Verknüpfungen fest. Diese Eigenschaft muss in einem 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 AppUserModelID in dieser Liste kann nicht angeheftet werden 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 von der Groß-/Kleinschreibung, 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
  • Neues

Die folgende Liste von Programmen 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 Benutzeroberfläche.

 

HKEY_LOCAL_MACHINE
   Software
      Microsoft
         Windows
            CurrentVersion
               Explorer
                  FileAssociation
                     AddRemoveApps
                     HostApps

SetCurrentProcessExplicitAppUserModelID

GetCurrentProcessExplicitAppUserModelID

Taskleistenerweiterungen

ICustomDestinationList::SetAppID

IApplicationDocumentLists::SetAppID

IApplicationDestinations::SetAppID

SHGetPropertyStoreForWindow