Page History

@author

<author>[value]</author>

No

No

The author tag tends to help who is responsible for a class or method.

@version

<version>[value]</version>

No

No

The version tag defines the version of the method.

@param

<param name="">[desc]</para>

Yes

Yes

Describes a parameter in a method signature. This is often
auto-generated by Visual Studio for methods.

<typeparam name="">
[desc]
</typeparam>

Yes

Yes

Describes a generic type parameter.

@return

<returns>[desc]</returns>

Yes

Yes

Only for methods that have a return value.  This is a good place to
note if the method can return null or not. 

@throws

<exception cref="[Type]">
[desc]
</exception>

No

Yes

This denotes when a class method or property can throw an exception
and the exception type that it throws. The description will tell the case
of why an exception is thrown if its not obvious.

@exception

<exception cref="">
[desc]
</exception>

No

Yes

Same as above

<value>[desc]</value>

Yes

Yes

Describes what the property [value] represents.

<permission cref="[Member]" />

No

Yes

Notes the access level of a type or member. 

@see

<seealso cref="[Member]" />

No

Yes

This links documentation that would beneficial in viewing in the relation
to the current documentation. This is placed in the "See Also" section
at the bottom of the page.

{@link ref}

<see cref="[Member]" />

Yes

Yes

This will create a link for the specified member. The cref part of this
can become tricky, especially with overloaded methods and generics.

In JavaDoc the sharp (#) prefix denotes a member, i.e.
{@link #methodName(Class,TokenStream)}      In .Net, this would
be <see cref="ClassName.MethodName(Type, TokenStream)" />

{@link ref}

<paramref name="[Member]" />

Yes

Yes

Inline element that references a parameter of the method, typically
used inside of the remarks or summary section.

{@link ref}

<typeparamref
       name="[Member]" />

Yes

Yes

Inline element that references a generic type parameter of the method,
typically used inside of the remarks or summary section.

@since

<since>[value]</since>

No

No

This describes that this functionality was supported starting in version x.

@serial

No

Unsure

[Serializable] - Sandcastle could use the [Serializable] attribute to
denote this in the generated documentation, but this needs to
be confirmed.

@deprecated

No

Yes

[Obsolete] - Sandcastle / SHFB does make use of the [Obsolete]
attribute to note that method is deprecated in the generated
docs.

<summary>[desc]<summary>

Yes

Yes

Give a brief overview about a class, namespace or member does
in the code. Intellisense will pick up summary and use it inside of
Visual Studio.  Be concise.

<remarks>[xml]</remarks>

Yes

Yes

Give the full explanation of what class, namespace or member does
in the code. This typically should include code examples.

<example>[xml]</example>

No

Yes

Denotes a full section targeted towards providing an example in the
generated docs. 

[<p />]

<para>[text]</para>

Yes

Yes

This should always be used for paragraphs inside of the <remarks />
section.  In Javadocs <p> is often used as line break and it does not
wrap the paragraph.  In the xml, it needs to wrap the paragraph text.

<code />

<c>[Type|value]</c>

Yes

Yes

Instructs Sandcastle to format the text as code.  examples: <c>null</c>,
<c>true</c>, <c>TokenStream</c>, <c>string</c>

JavaDocs will often wrap this inside of <code /> tags. This will cause
formatting issues if its carried over to the .NET comments.
Sandcastle will attempt to render as a code example.   

<code />

<code lang="[lang]">
[example]
</code>

No

Yes

This element specifies a code example. 

SHFP supports the lang attribute, so it would be wise to denote which
language the code example is in. 

<ul>,<ol>

<list>

Yes

Yes

When creating a list, you should use the <list> element. However SHFB
will let <ul> and <ol> elements be used in the generated docs.

<li>

<item>

Yes

Yes

When creating a list item, you should use the <item> element.
SHFP will let <li> be used in the generated docs.

<include file="[filepath]"
   path="tagpath[@name=id]" />

No

Yes

This element will let you include documentation from another file and
tag. The "path" attribute is the xpath query to the member you wish to
link.  This an alternative to putting the documentation inside the code.

It can also be more complicated.

<note>[xml|text]</note>

No

Yes

Nonstandard. This tag is supported by SHFB and possibly even
Sandcastle. This was an NDoc tag that was requested heavily.

This creates a note block inside the generated docs.

<inheritdoc />

No

Yes

Nonstandard. This tag is supported by SHFB. This will specify SHFB
to use documentation from the inherited member documentation.