Naming Restrictions for Team Foundation Server
Many components in Team Foundation Server follow certain naming restrictions. This guarantees a consistent user experience and it provides compatibility with other programs. These restrictions might include length, special characters, uniqueness, or other attributes.
This topic contains the following subsections:
Common Considerations
Restrictions for Team Foundation Server Group Account Names
Restrictions for Computer Names
Restrictions for Team Foundation Server Project Names
Restrictions for Work Items
Restrictions for Work Item Customizations
Restrictions for Process Templates
Restrictions for Team Foundation Build
Restrictions for Source Control
See Also
Common Considerations
The length restrictions in this topic are measured by the number of Unicode characters permitted. For more information about Unicode, see "About Unicode and Character Sets" (https://go.microsoft.com/fwlink/?LinkId=76837). Surrogate characters are composed of two Unicode characters and these will count as two characters against the length restriction.
For general information about the operating system restrictions applied to file names, see "Naming a File" (https://go.microsoft.com/fwlink/?LinkId=76838).
Restrictions for Team Foundation Server Group Account Names
Team Foundation group accounts enable you to apply certain rights or permissions to a group of users. This Team Foundation group can consist of Windows user accounts, Windows group accounts, Active Directory group accounts, Team Foundation group accounts, or any mixture of these types.
If you want to create a group that has permissions across multiple projects, see How to: Create a Server-Level Group. If you want to create a security group for your team project, see How to: Create a Team Project Group. If you want to add a new member to one of the groups predefined by Team Foundation Server, see How to: Add Users to a Default Group.
When a Team Foundation group account is created or changed, it must meet certain Team Foundation Server restrictions. The following table describes these restrictions.
Restriction Type |
Restriction |
---|---|
Group account name length |
|
Uniqueness (server-level group accounts) |
|
Uniqueness (project group accounts) |
|
Reserved group names |
|
Special character restrictions |
|
Note
You do not create user accounts in Team Foundation Server. In certain instances, you may want to add a specific Windows user to a Team Foundation group or to the Team Foundation Server itself. For more information, see How to: Add a User.
Restrictions for Computer Names
During the Team Foundation Server installation process, the computer name is associated with the name of the Team Foundation server. In order to rename a Team Foundation server, you must follow the procedures outlined in How to: Rename an Application-Tier Server or How to: Rename a Data-Tier Server.
Both the operating system and Windows Server 2003 Active Directory impose certain restrictions on computer names. For more information about renaming a computer, see "Rename a Computer" (https://go.microsoft.com/fwlink/?LinkId=76839). For more information about Active Directory, see "Windows Server 2003 Active Directory" (https://go.microsoft.com/fwlink/?LinkId=47541).
Restrictions for Team Foundation Server Project Names
The Team Foundation Server project name identifies a collection of work items, documents, reports, team builds, and a source control tree that make up a particular Team Foundation project. Team members will use this project name to connect to the project in Team Foundation Server.
The following table describes the restrictions for project names.
Restriction Type |
Restriction |
---|---|
Length |
|
Uniqueness |
Must not be identical to any other name in Team Foundation Server, Windows SharePoint Services, or SQL Server Reporting Services |
Special characters |
|
Reserved names |
|
1For more information about surrogate characters, see "Ask Dr. International, Column #18" (https://go.microsoft.com/fwlink/?LinkId=76840).
Restrictions for Work Items
Microsoft Visual Studio Team System tracks the progress on a project by using items such as bugs, requirements, tasks, and risks. These items are referred to generically as work items. This section describes restrictions on the data stored in the work items.
Restrictions for Work Item Attachments
Files can be attached to work items. The following table describes the restrictions on work item attachments.
Restriction Type |
Restriction |
---|---|
File size |
|
Restrictions for Work Item Areas and Iterations
Work items contain a field for Project Area and a field for Project Iteration. They are used to organize and display work items into logical groupings.
The Project Area and Project Iteration are paths made up of multiple node items separated by backslash (\) characters. Nodes are defined by the Team Foundation Server administrator to reflect the project areas and project cycle. For more information, see Setting Initial Project Areas or Iterations. The following table describes the restrictions on nodes and paths.
Restriction Type |
Restriction |
---|---|
Node length |
|
Special characters for nodes |
|
Reserved names |
|
Path length |
|
Path hierarchy depth |
|
Restrictions for Work Item Customizations
Team Foundation Server tracks the progress on a project by using items such as bugs, requirements, tasks, and risks. These items are referred to generically as work items.
Administrators of team projects can decide to change work item type definitions either at the project level or in a process template. For more information about how to customize work item types, see Customizing Work Item Types. This section describes restrictions you will encounter when you customize work items and their associated elements.
Restrictions for Work Item Field Names
Each work item type contains one or more work item fields. These fields define the information stored in a work item type. A work item field name uniquely identifies each work item field. For more information about work item field names, see Field Names.
The following table describes the restrictions for work item field names.
Restriction Type |
Restriction |
---|---|
Length |
Must not contain more than 128 Unicode characters |
Special characters |
|
Scope |
|
Restrictions for Work Item Field Reference Names
Each work item field has an associated field reference name. The field reference name uniquely identifies each field and cannot be changed after it is assigned. For more information about field reference names, see Field Reference Names. The following table describes the restrictions applied to field reference names.
Restriction Type |
Restriction |
---|---|
Length |
|
Special characters |
|
Uniqueness |
|
Restrictions for Work Item Field Help Text
As an option, you can associate help text with work item fields by using the <HELPTEXT> tag. The system displays this text at run time to help users know what to enter into the field. For more information about work item field help text, see Defining Field Help Text.
The following table describes the restrictions for work item field help text.
Restriction Type |
Restriction |
---|---|
Length |
|
Scope |
Unlike the field name and field type, field Help text is scoped to a specific work item type in a specific team project. |
Restrictions for Global Lists
A global list is a set of list item values that is stored and used globally by all Team Foundation servers in a Team Foundation Server implementation. As you define work item types, you may find that some work item fields share the same set of possible values. Global lists enable you to define these values one time and share them among multiple work item types. For more information, see Global Lists.
A global list (GLOBALLIST) contains one or more list items (LISTITEM elements).
The following table describes the restrictions on list items.
Restriction Type |
Restriction |
---|---|
Length |
|
Special characters |
|
Scope |
|
The following table describes restrictions that apply to a global list.
Restriction Type |
Restriction |
---|---|
Number of items |
The global list must not be empty. It must contain at least one LISTITEM element. |
Uniqueness |
|
Restrictions for Process Templates
A process template is a set of default work items, work item queries, product templates, reports, security groups, and guidance that influences the structure of a project in Team Foundation. Team Foundation Server includes two default process templates that encompass two different styles for managing the software cycle. These templates can be customized to reflect the unique needs of your organization. For more information, see Customizing Process Templates.
The following table describes restrictions on the process templates.
Restriction Type |
Restriction |
---|---|
Process template name length |
Must not contain more than 256 Unicode characters. |
Process template name uniqueness |
|
Process template file size |
The process template file size must not exceed 2 GB (gigabytes). |
Restrictions for Team Foundation Build
Team Foundation Build lets you manage all the aspects of the build process on a single computer. By using Team Foundation Build, you can synchronize the sources, compile the application, run associated unit tests, perform code analysis, release builds on a file server, and publish build reports. For more information, see Team Foundation Build Overview.
Build Computer Restrictions
Team Foundation Build is a separate installation from the Team Foundation Server application tier, data tier, or Visual Studio client. You may designate a separate computer. Otherwise, you can install the build side-by-side on the client computer or on the servers. For more information about how to set up a build computer, see How to: Set up and Install Team Foundation Build.
The following table describes restrictions for the build computer.
Restriction Type |
Restriction |
---|---|
Disk space |
Must contain sufficient space for the build (insufficient space will lead to failed builds). |
Build directory |
Must be a local path (for example, C:\builddirectory). |
Drop location directory |
Must be a UNC path (for example, \\server\share). |
Drop location permissions |
Each generated build is put in a new directory in the drop folder.
|
Team Build Service account |
If you change the Team Foundation Server Service account after the initial installation, you must make sure that the following conditions are true.
|
Firewall issues |
If the build computer is firewall enabled, make sure that the program tfsbuildservice is in the exceptions list. |
Build Type Names
Team Foundation Build uses build types to configure the conditions under which a single solution or a set of solutions in a team project will be built. To conduct a build, you must either create a new build type or use an existing build type. For more information about build types, see Working with Build Definitions in Team Foundation Build.
The following table describes the restrictions on build type names.
Restriction Type |
Restriction |
---|---|
Uniqueness |
Must not be the same as any other build type name in the project |
Special characters |
|
Build Quality Names
The build quality lets you attach a quality level or completion state to a completed build. Team Foundation Build also lets you create new values for the build quality type. For more information, see How to: Create a Build Definition. For a list of the default build quality values, see How to: Set Build Quality.
The following table describes the restrictions on build quality names.
Restriction Type |
Restriction |
---|---|
Length |
Must not contain more than 256 Unicode characters |
Uniqueness |
Must not be the same as any other Build Quality name in the Team Foundation Build computer |
Restrictions for Source Control
Team Foundation source control provides a central repository for files and the commands that are required to manage those files across a team. It also provides customizable check-in policies, branching, merging, shelving, and many other features.
For more information about source control in Team Foundation, see Team Foundation Version Control.
Source Control Server Paths
The source control server path is the fully qualified path location of a file stored in source control.
The following table describes restrictions on the length of the source control server path.
Restriction Type |
Restriction |
---|---|
Length |
|
Adding Files into Source Control
The source control system stores many different types of files. For more information about how to add existing Visual Studio projects or solutions into source control, see Adding Projects and Solutions to Source Control. You can also add files or folders that are not associated with a Visual Studio project or solution. For more information, see How to: Add Non-Project or Non-Solution Files and Folders to Version Control.
The following table describes the restrictions applied to files and folders to be added to source control.
Restriction Type |
Restriction |
---|---|
File extensions |
|
Folders |
|
Label Names
In Team Foundation source control, a label is a name applied to a specific set of revisions. You can attach labels to a set of unrelated files in source control. This lets you retrieve the files or act upon them as a group. For more information, see Working with Labels. The following table describes the restrictions put on label names.
Restriction Type |
Restriction |
---|---|
Length |
Must not contain more than 64 Unicode characters |
Special characters |
|
Shelvesets
Shelvesets enable you to set aside temporarily a batch of pending changes and then, as an option, remove the pending changes from your workspace. Later, you can restore the changes in a shelveset to your workspace or put them into another user's workspace. For more information, see Working with Version Control Shelvesets.
The following table describes restrictions on shelveset names.
Restriction Type |
Restriction |
---|---|
Length |
Must not contain more than 64 Unicode characters |
Special characters |
|
Workspace Names
A workspace is a client-side copy of the files and folders on a source control server. When you create multiple workspaces, you can have different versions of the same source control folder on a client computer. For more information about workspaces, see Working with Version Control Workspaces. The following table describes restrictions on workspace names.
Restriction Type |
Restriction |
---|---|
Length |
Must not contain more than 64 Unicode characters |
Special characters |
|
See Also
Tasks
How to: Create a Server-Level Group
How to: Create a Team Project Group
How to: Add Users to a Default Group
How to: Rename an Application-Tier Server
How to: Rename a Data-Tier Server
How to: Set up and Install Team Foundation Build
How to: Create a Build Definition
How to: Add Non-Project or Non-Solution Files and Folders to Version Control
How to: Modify the Team Project Areas
How to: Modify the Team Project Iterations
Concepts
Team Foundation Server Administration
Team Foundation Build Overview
Team Foundation Version Control
Working with Version Control Shelvesets
Working with Version Control Workspaces
Setting Initial Project Areas or Iterations
Other Resources
Troubleshooting Team Foundation Server