Member ID Strings
All cref attributes on documentation elements such as see or exception generate an ID string in the XML comments file. Normally, the ID string can be properly generated by the compiler based on a partial or fully qualified type or member name. However, there are occasions where this will not work properly. A common example is in C++ code where the compiler is not always able to generate IDs for forward referenced members. In such cases, an ID string can be used as a reference explicitly instead of letting the compiler figure it out.
Author Credit: Most of the information in this topic was originally written by Microsoft as part of the .NET Documentation Guidelines document.
The format of the ID string is shown below.
type is one of the following. The final two are specific to the Sandcastle Help File Builder and Tools and are never generated by the compiler.
Used by the compiler to indicate an error such as being unable to resolve the member ID
Type (class, interface, structure, enumeration, etc.)
Sandcastle generated. Represents the root namespace page. There will always be a single entry named R:Project_[HtmlHelpName] where "[HtmlHelpName]" is the value of your project's HTML Help Name property with spaces replaced by underscores. This suffix is required to keep the root namespace container page ID unique across all help files so that there are no duplicate IDs when generating MS Help Viewer output.
Sandcastle specific. Used to generate a link to the Overloads List page for an overloaded member.
fullname is the full name of the member from the root. Thus referencing StringBuilder would be System.Text.StringBuilder. The full name will include any member references as well so referencing the Append method of StringBuilder would be System.Text.StringBuilder.Append.
For properties that accept parameters and methods with parameters, the argument list is next. The argument list contains the parentheses as well. Each argument is specified as the full name of the associated type. For reference types, the type name is followed by an at (@) sign. For array types, the type name is followed by brackets (). Other symbols are possible but they are not supported by Visual Basic or C#.
For generic classes, the type is followed by a back tick (`) and the number of generic type parameters. For generic methods, there is one back tick (`) and a number for each generic parameter. Additional generic parameters are separated by a comma. Each number is the zero-based index within the parameter list of the parameter.
There are no spaces allowed in the ID string. If a name contains a dot (except to separate namespaces from types, types from other types, and types from members) then the pound (#) sign is used instead. In general, such a member is not possible. However, for referencing special methods like a constructor or explicitly implemented members, it is needed. An example of an explicitly implemented member ID is:
The constructor for a type is always of the following form.
The destructor for a class is always of the following form.
Operators are encoded as the formal name of the operator followed by their arguments. For conversion operators, the formal name is used (op_Explicit or op_Implicit) followed by the arguments, a tilde (~), and the return type. For example:
M:fullname.op_[binaryOpname](arg1, arg1) M:fullname.op_[unaryOpname](arg) M:fullname.op_Explicit(arg1, arg2)~returnType M:fullname.op_Implicit(arg1, arg2)~returnType
Below are example IDs for each overloadable operator:
Member ID Example
x = y + z
x = y & z
x = y | z
x = y / z
if(x == y)
x = y ^ z
string x = (string)test1Object
if(test1Object == false)
if(x > y)
if(x >= y)
string x = test1Object
if(x != y)
x = y << 2
if(x < y)
if(x <= y)
x = y % z
x = y * z
x = ~x
x = y >> 2
x = y - z
if(test1Object == true)
x = -test1Object
int x = +test1Object