Benennungskonventionen für Arbeitsaufgabenverfolgungs-Objekte

In Visual Studio Team Foundation Server (TFS) sind allen Arbeitsaufgabenverfolgungs-Objekten 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 Anzeigenamen stellen Sie die Konsistenz für alle Teamprojekte und Arbeitsaufgabentypen in einer Projektauflistung sicher. Der Verweisname wird von TFS 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.

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 Arbeitsaufgaben-Nachverfolgungsfelder definiert. Diese Felder werden in einer Arbeitsaufgaben-Typdefinition der TFS-Prozessvorlagen definiert. Sie können mit TFS jedoch ein eigenes Microsoft.X-Feld erstellen. Davon wird jedoch dringend abgeraten, da dies die Team Foundation Server TFS-Funktionalität oder die Fähigkeit des Assistenten zum Konfigurieren von Funktionen beeinträchtigt, ein Teamprojekt nach einem TFS-Upgrade erfolgreich zu aktualisieren.

Kunden und Partner können ihre eigenen Feldnamespaces für benutzerdefinierte Arbeitsaufgabentypen erstellen.

Beschreibungen von Systemfeldern und Feldern, die in den TFS-Prozessvorlagen definiert werden, finden Sie unter Arbeitsaufgabenfeld-Verweis für Visual Studio ALM.

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

FIELD (Definition)-Elementverweis

Konzepte

Anpassen der Objekte für die Arbeitsnachverfolgung als Unterstützung der Prozesse des Teams