Benennungskonventionen für Arbeitsaufgabenverfolgungs-Objekte
Allen Arbeitsaufgabenverfolgungs-Objekten sind ein oder mehrere Namen zugeordnet. Die meisten verfügen über benutzerfreundliche Anzeigenamen, und allen Objekten außer Arbeitsaufgabentypen und globalen Listen sind Verweisnamen zugeordnet. Ein Anzeigename ist ein eindeutiger, für Benutzer sichtbarer Bezeichner für ein Feld, mit dem die Konsistenz für alle Teamprojekte und Arbeitsaufgabentypen in einer Projektauflistung sichergestellt wird. Der Verweisname wird von Team Foundation Server intern verwendet und kann nicht geändert werden, nachdem er definiert wurde.
In der folgenden Tabelle werden die Benennungsanforderungen zusammengefasst, die für jedes Arbeitsaufgabenverfolgungs-Objekt erfüllt werden müssen.
Arbeitsaufgabenverfolgungs-Objekt |
Verweisname |
Angezeigter Name |
|---|---|---|
Arbeitsaufgabentyp |
Nicht zutreffend |
Der Name jedes Arbeitsaufgabentyps kann bis zu 255 Unicode-Zeichen enthalten, und er muss innerhalb eines Teamprojekts eindeutig sein. |
Arbeitsaufgabenfeld |
Erforderlich. Siehe Anforderungen an Verweisnamen. |
Feldnamen können eine maximale Länge von 128 Unicode-Zeichen aufweisen, und sie müssen innerhalb einer Teamprojektsammlung eindeutig sein. |
Linktyp |
Erforderlich. Siehe Anforderungen an Verweisnamen. |
Für jeden Linktyp werden zwei Anzeigenamen definiert: Forwardname und Reversename. Diese Namen können eine maximale Länge von 128 Unicode-Zeichen aufweisen, und sie müssen für alle in einer Teamprojektsammlung definierten Linktypen eindeutig sein. |
Kategorie |
Erforderlich. Siehe Anforderungen an Verweisnamen. |
Anzeigenamen für Kategorien können eine maximale Länge von 128 Unicode-Zeichen aufweisen, und sie müssen innerhalb eines Teamprojekt eindeutig sein. |
Globale Liste |
Nicht zutreffend |
Der Name jeder globalen Liste kann bis zu 254 Unicode-Zeichen enthalten, und er muss innerhalb einer Teamprojektsammlung eindeutig sein. |
Themeninhalt
Anforderungen an Anzeigenamen
Anforderungen an Verweisnamen
Anforderungen an Feldverweisnamen und Portabilität
Beispiele für Feldverweisnamen
Anforderungen an Anzeigenamen
Zusätzlich zu den in der obigen Tabelle aufgeführten Anforderungen müssen die definierten Anzeigenamen folgende Anforderungen erfüllen:
Namen dürfen nicht leer sein.
Namen dürfen keine vorangestellten oder nachgestellten Leerzeichen enthalten.
Namen dürfen keine umgekehrten Schrägstriche (\) enthalten.
Die folgenden Zeichen dürfen in Feldnamen nicht enthalten sein: umgekehrter Schrägstrich (\), Punkt (.) sowie öffnende und schließende eckige Klammern ([]).
Namen dürfen keine zwei aufeinander folgenden Leerzeichen enthalten.
Anforderungen an Verweisnamen
Beim Hinzufügen oder Erstellen eines Arbeitsaufgabenfelds, eines Linktyps oder einer Kategorie muss immer ein Verweisnamen definiert werden. Verweisnamen können eine maximale Länge von 70 Unicode-Zeichen aufweisen.
Sie können Feldverweisnamen definieren, in denen alphanumerische Zeichen, Unterstriche und Bindestriche vorkommen. Jeder Feldverweisname muss mindestens einen Punkt (.) enthalten, am Anfang oder Ende eines Namens darf jedoch kein Punkt stehen. Ein Verweisname darf nicht mit einer Zahl oder einem Unterstrich beginnen, und er darf keine aufeinander folgenden Bindestriche (--) enthalten.
Feldverweisnamen und Portabilität
Die Definitionssprache für Arbeitsaufgabentypen basiert u. a. auf dem Konzept der Feldverweisnamen. Feldverweisnamen unterstützen Sie beim Portieren von Definitionen zwischen Team Foundation-Projektauflistungen und ermöglichen zudem das Suchen von und Verweisen auf bestimmte Felder durch Drittanbieterintegrationen. Diese Namen sind global eindeutig, ebenso wie ein Namespace in der .NET Framework-Anwendung global eindeutig ist.
Feldverweisnamen können nicht geändert werden. Wenn Sie den Feldnamen beispielsweise von "Titel" in "Header" ändern, bleibt der Feldverweisname dieses Felds unverändert. Bei Integrationen und internen Darstellungen von Feldern muss der Feldverweisname verwendet werden, sodass sie nicht vom Feldnamen selbst abhängig sind.
Mit dem System-Namespace werden lediglich alle Kernsystemfelder definiert, die für die Team Foundation-Systemfunktionen erforderlich sind. Von Team Foundation Server wird verhindert, dass Sie ein eigenes System.X-Feld erstellen, da dies die Funktionalität von Team Foundation Server beeinträchtigen könnte.
Mit dem Microsoft-Namespace werden Felder definiert, die in einer Arbeitsaufgabentyp-Definition einer Microsoft Solutions Framework (MSF)-Prozessvorlage definiert werden. Sie können mit Team Foundation Server jedoch ein eigenes Microsoft.X-Feld erstellen. Davon wird jedoch dringend abgeraten, da dies die Funktionalität von Team Foundation Server beeinträchtigen könnte.
Kunden und Partner können ihre eigenen Feldnamespaces für benutzerdefinierte Arbeitsaufgabentypen erstellen.
Beschreibungen von Systemfeldern und Feldern, die von MSF for Agile Software Development - v5.0 definiert wurden, finden Sie unter Verwenden von Systemfeldern und von den MSF-Prozessvorlagen definierten Feldern.
Beispiele für Feldverweisnamen
In den folgenden Beispielen werden gültige Feldverweisnamen in verschiedenen Namespaces veranschaulicht.
Systemnamespace-Beispiele
System.Id
System.Title
System.CreatedBy
System.CreationDate
System.ChangedBy
System.ChangedDate
System.State
System.Reason
Microsoft-Namespace-Beispiele
Microsoft.Common.Status
Microsoft.Common.Priority
Microsoft.Scheduling.Duration
Microsoft.Scheduling.PercentComplete
Microsoft.Testing.TestCaseName
Beispiele in anderen Namespaces
Kunden und Partner können auch ihre eigenen Namespaces für benutzerdefinierte Arbeitsaufgabentypen definieren. Beispielsweise könnte die fiktive Gesellschaft Trey Research die folgenden benutzerdefinierten Arbeitsaufgabentypen definieren:
TreyResearch.Common.Severity
TreyResearch.Common.Phase
TreyResearch.RiskManagement.RiskType
TreyResearch.RiskManagement.Resolution
Das fiktive Softwarehaus A. Datum Corporation kann die folgenden Arbeitsaufgabentypen definieren:
A_Datum.Common.BusinessPriority
A_Datum.Bug.FoundInPhase
A_Datum.Bug.FixInPhase
Siehe auch
Referenz
Konzepte
Anpassen von Projektnachverfolgungsdaten, Formularen, Workflow und anderen Objekten