xml комментарии в коде
Практическое руководство. Вставка XML-комментариев для создания документации
Visual Studio может помочь вам документировать элементы кода, такие как классы и методы, автоматически формируя стандартную структуру комментариев для XML-документации. Во время компиляции можно создать XML-файл, содержащий комментарии для документации.
Сведения о настройке имени и расположения созданного XML-файла см. в статье Документирование кода с помощью XML-комментариев.
Команда Вставить комментарий, которая автоматически вставляет комментарии XML-документации, доступна в C# и Visual Basic. Однако можно вручную вставить комментарии XML-документации в файлы C++ и по-прежнему создавать файлы XML-документации во время компиляции.
Вставка XML-комментариев для элемента кода
Поместите текстовый курсор над элементом, например методом, который нужно задокументировать.
Выполните одно из следующих действий.
Введите /// в C# или »’ в Visual Basic
В меню Правка выберите IntelliSense > Вставить комментарий.
Щелкните правой кнопкой мыши или вызовите контекстное меню в редакторе кода или над ним и выберите Фрагмент кода > Вставить комментарий.
для каждого параметра и элемент для документирования возвращаемого значения.
Введите описание для каждого XML-элемента, чтобы полностью задокументировать элемент кода.
Стили можно использовать в комментариях XML, которые будут отображаться в виде кратких сведений при наведении указателя мыши на элемент. К этим стилям относятся курсив, полужирный шрифт, маркеры и ссылка, доступная для щелчка.
Существует параметр для переключения комментариев XML-документации после ввода /// в C# или »’ Visual Basic. В строке меню выберите Сервис > Параметры, чтобы открыть диалоговое окно Параметры. Перейдите в раздел Текстовый редактор > C# или Basic > Дополнительно. В разделе Справка редактора найдите параметр Создавать комментарии XML-документации.
Примеры комментариев к XML-документации
В этой статье содержится три примера для добавления комментариев к XML-документации к большинству элементов языка C#. В первом примере показано, как задокументировать класс с разными членами. Во втором показано, как можно повторно использовать объяснения для иерархии классов или интерфейсов. В третьем примере показаны теги, используемые для универсальных классов и членов. Во втором и третьем примерах используются концепции, рассмотренные в первом примере.
Документирование класса, структуры или интерфейса
В следующем примере показаны общие элементы языка и теги, которые, скорее всего, будут использоваться для описания этих элементов. Комментарии к документации служат для описания использования тегов, а не самого класса.
Добавление документации может перегрузить исходный код большими наборами комментариев, предназначенными для пользователей библиотеки. Тег используется для отделения XML-комментариев от исходного кода. Исходный код ссылается на XML-файл с помощью тега :
Второй файл, xml_include_tag.xml, содержит комментарии к документации.
Документирование иерархии классов и интерфейсов
Элемент означает, что тип или член наследует комментарии к документации от базового класса или интерфейса. Элемент с атрибутом cref также можно использовать для наследования комментариев от члена того же типа. В следующем примере показано, как использовать этот класс. Обратите внимание, что при добавлении атрибута inheritdoc к типу наследуются комментарии члена. Можно запретить использование наследуемых комментариев, записав комментарии к членам в производном типе. Они будут выбраны для наследуемых комментариев.
Универсальные типы
Используйте тег для описания параметров типа в универсальных типах и методах. Значение атрибута cref требует нового синтаксиса для ссылки на универсальный метод или класс:
Пример класса Math
В следующем коде показан реалистичный пример добавления комментариев к документу в библиотеку Math.
В приведенном выше XML комментарии к документации по каждому члену отображаются непосредственно внутри тега с именем, соответствующим его назначению. Можно выбрать собственную стратегию. Код использует тег для ссылки на соответствующий элемент в XML-файле:
IT-блог о веб-технологиях, серверах, протоколах, базах данных, СУБД, SQL, компьютерных сетях, языках программирования и создание сайтов.
Разметка XML документа. XML атрибуты. Корень XML документа. Декларации в XML. Комментарии в XML. Синтаксис XML документа
Здравствуйте, уважаемые посетители моего скромного блога для начинающих вебразработчиков и web мастеров ZametkiNaPolyah.ru. Сегодня продолжаем говорить о расширяемом языке разметки XML, продолжим разговор о XML тегах, рассмотрим, как писать сокращенные XML теги, поговорим о кодировки в XML документах, так же рассмотрим, что такое корневой элемент или иначе корень XML документа, в этой публикации мы рассмотрим вопрос о комментариях в XML документах, а так же посмотрим какие символы запрещены в XML. 
Рассмотрим, что такое декларация, а так же для чего нужна декларация в XML документе и как правильно декларировать. Так же мы поговорим, о разметки XML документа. И так, продолжаем разговор о синтаксисе XML документа, начатый в статье Расширяемый язык разметки XML. Синтаксис XML. Структура XML документа. Применение XML.
Синтаксис XML документа, как декларировать XML документ, из чего состоит XML документ. Инструкции XML документа.
В первой статье, я как смог, так и объяснил, что такое синтаксис вообще и в XML документе в частности. Теперь предлагаю более подробно остановиться на данном вопросе, а так же рассмотреть, что такое декларация в XML и как декларировать XML документ. Синтаксис в XML на самом деле очень сложный, шаг влево, шаг в право и XML парсер вас уже не поймет.
Для начала, давайте рассмотри из чего состоит XML документ и соответственно рассмотрим синтаксис XML документа.
Пример XML документа:
Любой XML документ начинается с пролога или декларации. Что такое пролог в XML документе или иначе декларация XML документа — это начало XML документа, в примере это первая строка, как правило показывается, что это XML документ и указывается версия XML, а так же кодировка XML документа( ), на данный момент уже есть XML версии 1.1.
Обратите внимание на конструкцию пролога, так как в XML все очень жестко и структурировано, а именно на начало декларации( Пример процессинговых инструкций в XML документе:
В этом примере я указал пролог XML документа, затем указал, что необходимо сделать с XML документом, то есть отформатировать диск D, а затем уже пошли данные самого XML документа. Этих инструкций может быть бесконечно много, так как придумываете вы их самостоятельно для решения тех или иных задач. Как и в случае с XML тегами, никаких инструкции в XML не заложено, их ноль, но когда вы решаете определенные задачи вы придумываете эти инструкции самостоятельно.
Если скопировать данный пример в текстовый редактор(например, в редактор с подсветкой синтаксиса Notepad++), а затем открыть XML документ в браузере, то ничего не произойдет, так как браузер не поймет данную инструкцию, но если вы напишите программу, которая будет знать эту инструкцию, то после работы с данными находящимися в XML документе она отформатирует диск D. И так, можно сделать вывод, что в XML прологом документа называют все, что предшествует самим данным, то есть декларация XML документа и инструкции по обработке XML документа.
XML комментарии, как правильно писать комментарии в XML документе.
Комментарии, ну наверное вы знаете для чего они нужны, если говорить научным языком, комментарии — это не анализируемая часть текста. На самом деле, в XML комментарии имеют большее значение, они могут иметь смысл, как и XML теги и реально анализироваться программой. Комментарии в XML документе — это еще одна разновидность XML конструкций.
Естественно, чаще всего используются для того, что бы оставлять для себя и кого-то другого какие-то пометки и указания по самому XML документу. Синтаксис комментариев в XML, такой же как и в HTML комментариях, начинается комментарий с конструкции
style = «text-align: justify;» >
XML теги и XML элементы, правила написания XML тегов.
Из прошлой статьи, мы выяснили, что теги в XML только парные, то есть существует открывающий тег и обязательный ему закрывающий тег, XML теги регистрочувствительны, не важно в каком регистре вы пишите свой тег, важно, что если вы создали элемент people с открывающим тегом
, то закрывающий тег нужно будет писать в том же регистре
По определению в XML не может быть одиночных тегов, любой тег должен быть закрыт. Одиночных тегов в XML нет в принципе, но бывает необходимость, когда по грамматике тег не будет иметь содержимое, то есть пустой элемент. То есть, иногда существует необходимость в XML элементах, в которых по смыслу никогда не будет содержимого, в таких случаях писать такие конструкции нет смысла( ).
XML атрибуты, как правильно писать XML атрибуты
Обратите внимание на самый первый пример, у тегов и имеются атрибуты, id и cm, в первом случае параметром является число-идентификатор, во втором случае единицы измерения роста — сантиметры. Все XML атрибуты вы придумываете самостоятельно(в отличие от HTML атрибутов), семантику и грамматику для XML атрибутов вы придумываете то же самостоятельно, то есть задаете для этих XML атрибутов смысл и правила.
Параметром или значением XML атрибута, может быть все, что угодно, все на что хватит вашей фантазии. А вот синтаксис у XML атрибутов строгий, значение атрибутов всегда должны быть в двойных кавычках, но некоторые парсеры XML допускают вольности и ставить одинарные кавычки, но лучше к данному подходу не привыкать. Как и в случае с XML тегами, XML атрибутов может быть бесконечно много.
Единицы измерения XML. Корневой XML элемент или корень XML документа.
В XML существует очень важное правило, минимальной единицей измерения является документ, один XML элемент это документ, и этот XML элемент является минимальной единицей измерения — всегда! Как это можно понять? XML документ всегда состоит из одного тега или элемента, по буржуйски этот тег называется root или корень XML документа, это означает, что у любого документа должен быть всегда один элемент(один тег), внутри него может быть все, что угодно, но один XML элемент в XML документе должен быть всегда.
В первом нашем примере корневым элементом является, элемент
, внутри него можно размещать все, что угодно, делать какие угодно ветвления и вложения, но создавать элемент уровня
Пример того как можно составлять XML документ:
В данном примере, элементы woman и man лежат внутри корневого XML элемента people, поэтому здесь ничего не нарушено и XML документ составлен правильно.
Пример того как нельзя составлять XML документ:
Данный пример по своей сути не правильный и XML обработчик выдаст ошибку, так как у XML документа может быть только один корневой элемент, а в данном примере их два, это people и animal, что противоречит стандарту XML. Еще раз повторюсь, у XML документа может быть только один корневой элемент, внутри которого должны располагаться все остальные элементы. Если же вы все-таки напишите два корневых элемента, анализатор вам так и скажет, «В XML документах, допускается один элемент верхнего уровня».
Так же не может быть XML документов состоящих только из пролога, в XML документе должен быть хотя бы один XML элемент.
Так писать XML документы нельзя:
Нельзя, потому что внутри XML документа должен быть один тег, а в данном случае нет ни одного тега. XML документа без корня существовать не может. Если вам интересно как создать пустой XML документ, то тут все очень просто.
Пример пустого XML документа:
Данный документ пустой и содержит один элемент(tag), то есть корень XML документа, поэтому он удовлетворяет XML стандарту. XML документ это всегда один главный тег, то есть все прологи, процесинговые инструкции, это все не так важно, XML документ — это один тег.
Типы данных в XML. CDATA и PCDATA.
Как я уже говорил, XML работает только с данными, в чистом XML данные одни — текст. XML документ состоит из элементов, внутри которых расположены текстовые данные. Любые данные находящиеся внутри XML документа рассматриваются как PCDATA (Parsed Character Data), это означает, что XML анализатор будет рассматривать данные, как парсируемые, анализируемые текстовые данные, то есть XML парсер анализирует не только теги и атрибуты, но и то что находится внутри них.
В связи с этим, в XML ввели еще один тип данных CDATA, которые анализатор XML вообще не трогает никак, грубо говоря мы ему указываем, что от этого места до этого просто текст, с которым ничего делать не надо.Что бы указать XML анализатору, что данные являются CDATA, надо сделать декларацию( )
Все, что размещено в этой конструкции( ), анализатор будет считать обычным текстом и не будет обращать на него внимание. Правильно эта конструкция называется секция CDATA, то есть раздел непарсируемых данных.
Пролог в XML документе. Кодировка XML документа. Русские XML теги. Кодировка Unicode.
Как я уже говорил, в XML документе есть пролог, в котором указывается язык XML, его версия и кодировка XML документа, но писать пролог не обязательно и все будет прекрасно работать, до тех пор пока вы не напишите хотя бы одну букву не входящую в латинский алфавит.
Все дело в том, что проблема с кодировкой в XML решена очень грамотно, в XML нет понятия битой кодировки, то есть каракозябры в XML вы никогда не увидите. Если вы не указываете в прологе кодировку, то в XML документе можно использовать только латинские буквы. Если вы в своем документе использовали хотя бы одну букву не латинского алфавита, то вы обязаны декларировать, какую кодировку вы используете, в XML документе кодировки могут быть любые.
Причем, после того, как вы укажете кодировку, символы из этой кодировки вы можете использовать любые и в любом месте XML документа, в название тегов, атрибутов, значений атрибутов, сами данные и так далее. Кодировку для XML документа, я бы посоветовал использовать UTF-8. Сейчас объясню почему.
Unicode — это универсальное средство, которое позволяет использовать помимо стандартных символов и графики использовать какие-либо частные символы, дополнительные графические элементы, национальные языки и многое другое, универсальность его намного больше, чем однобайтовых кодировках.
Unicode, на самом деле один, но у него есть множество способов кодирования. UTF — это способ кодирования файлов. И вот этих UTF много, порядка 10 штук, можете поискать(UTF-7, UTF-8, UTF-16, UTF-32), цифра показывает минимальное число бит на один символ.
И так, нам необходимо указывать кодировку своих документов, причем указывать и для редактора и для анализатора, хорошо, если вы используете какой-нибудь Notepad++, где вы явно указываете кодировку и нет никаких проблем, а если вы используете обычный блокнот windows.
Предлагаю попробовать создать пустой документ, с расширением txt в обычном блокноте. И затем его сохранить. Размер этого документа будет ноль байт.
А теперь попробуйте пересохранить этот же пустой документ, но уже в кодировки Unicode, я выберу способ кодирования UTF-8, а теперь посмотрите, какой размер будет у пустого файла в кодировки UTF-8. Документ в кодировки UTF-8 будет весить 3 байта, но откуда взялись эти 3 байта, в документе по прежнему ничего нет, он пустой.
Так вот, блокноту нужно как-то подсказывать, какая кодировка используется, для этих целей в Unicode придумали Byte Order Mark, или сокращенно BOM, это метка порядка чередования байтов. Идея разработчиков Unicode очень проста. Поскольку в Unicode миллиарды различных символов, включая полную типографику, в которой только с десяток символов пробелов(узкий пробел, широкий пробел, неразрывный пробел, широкий пробел с переносом, неразрывный пробел и так далее). Среди множества этих пробелов есть один хитрый пробел, который называется неразрывный непечатный пробел, он применяется для разделение частей многосложных слов, его невидно, но он есть, как суслик, ты его не видишь, а он есть.
И не менее хитрые разработчики Unicode придумали такую штуку, если файл начинается с неразрывного непечатного пробела, программа поймет, во-первых, что вы используете Unicode, а во-вторых, способ кодирования. Неразрывный непечатный пробел и есть BOM, метка, которая показывает какую кодировку вы используете, а при способе кодирования UTF-8 неразрывный непечатный пробел кодируется тремя байтами, поэтому наш пустой документ имеет размер три байта.
Так вот, если этот BOM есть, любая виндовая программа определит, что документ закодирован в Unicode. Некоторые Unix интерпретаторы косячат, когда видят BOM, поэтому старайтесь кодировать все свои документы(не только XML) без BOM.
Для нас же(людей использующих русский язык) наличие BOM в начале XML документа означает, что мы можем использовать любые символы в документе явно не указывая кодировку. То есть парсер поймет какая кодировка у XML документу по наличию BOM, это единственное исключения, когда можно не писать для русского языка кодировку, но лучше не надейтесь на BOM и всегда указывайте кодировку.
XML подведение итогов. Well-formed document или хорошо сформированный XML документ.
И так, расширяемый язык разметки XML, применяется для хранения, обработки и передачи каких-либо данных. Во многих случаях вы даже не догадываетесь, что используется XML. Чистый XML имеет только синтаксис, синтаксис XML очень и очень жесткий, грамматику и семантику XML придумывает разработчик.
Так же мы поговорили про анализатор XML, который прежде чем, что-то делать с документом проверяет его и в случае малейшей ошибки должен отказаться от работы с XML документом. Well-formed document — это первый уровень правильности написания XML документа, грубо говоря — это соблюдение всех синтаксических правил.
Любой XML документ считается синтаксически правильно сформированным, если выполняются следующие синтаксические правила в XML документе:
Если все эти правила соблюдены в XML документе, то первый уровень проверки XML документа пройден — анализатор может его легко обработать, документ считается правильным или валидным. Собственно это и есть весь XML, кроме одной весчи, о которой мы поговорим в следующих статьях
На этом всё, спасибо за внимание, надеюсь, что был хоть чем-то полезен и до скорых встреч на страницах блога для начинающих вебразработчиков и вебмастеров ZametkiNaPolyah.ru
- Возможно, вам будет интересно:
Комментарии XML-документации
В исходных файлах C# могут находиться структурированные комментарии, используемые для создания документации по API для типов, определенных в этих файлах. Компилятор C# создает файл XML, содержащий структурированные данные, представляющие комментарии и сигнатуры API. Другие средства могут обрабатывать эти выходные данные в формате XML и создавать удобочитаемую документацию, например, в виде веб-страниц или PDF-файлов.
Благодаря этому процессу добавление документации по API в код предоставляет множество преимуществ:
Такие средства как Visual Studio предоставляют IntelliSense для многих распространенных XML-элементов, используемых в комментариях к документации.
В этой статье рассматриваются следующие темы:
Создание выходных данных XML-документации
Вы создаете документацию для кода, указывая ее в специальных полях комментариев, обозначаемых тройными косыми чертами. Поля комментария включают XML-элементы, которые описывают блок кода, следующий за комментариями. Пример:
Вы устанавливаете параметр DocumentationFile, и компилятор найдет все поля комментариев с XML-тегами в исходном коде и создаст XML-файл документации из этих комментариев. Если этот параметр включен, компилятор создаст предупреждение CS1591 для любого открытого видимого члена, объявленного в проекте без комментариев XML-документации.
Формат комментариев XML
Для создания комментариев XML-документации необходимо использовать разделители, указывающие начало и конец комментария. С тегами в XML-документации можно использовать следующие разделители:
Visual Studio автоматически вставляет теги и и устанавливает курсор между ними после ввода разделителя /// в редакторе кода. Вы можете включить или отключить эту функцию в диалоговом окне «Параметры».
Компилятор обнаруживает в начале второй и третьей строки общий шаблон » * «. Шаблон не включается в выходные данные.
Компилятор не обнаруживает общий шаблон в следующем комментарии, так как второй знак в третьей строке не является звездочкой. Весь текст во второй и третьей строках обрабатывается как часть комментария.
Компилятор не обнаруживает шаблон в следующем комментарии по двум причинам. Во-первых, количество пробелов перед звездочкой не является одинаковым в разных строках. Во-вторых, пятая строка начинается с символа табуляции, который не является пробелом. Весь текст из строк со второй по пятую обрабатывается как часть комментария.
Для ссылки на XML-элементы (например, если функция обрабатывает определенные XML-элементы, которые требуется включить в комментарии XML-документации) можно использовать стандартный механизм заключения в скобки ( и > ). Для ссылки на универсальные идентификаторы в элементах ссылок кода ( cref ) можно использовать escape-символы (например, cref=»List » ) или фигурные скобки ( cref=»List
Комментарии XML-документации не являются метаданными. Они не включаются в скомпилированную сборку, и поэтому не доступны посредством отражения.
Средства, принимающие входные данные XML-документации
Следующие средства создают выходные данные на основе XML-комментариев:
Строки идентификаторов
Компилятор соблюдает следующие правила при формировании строк идентификаторов.
В строке нет пробелов.
Первая часть строки определяет тип элемента, использующего один символ, за которым следует двоеточие. Используются следующие типы элементов.
| Знак | Тип члена | Примечания |
|---|---|---|
| Нет | namespace | Вы не можете присвоить комментарий документации пространству имен, но можете создать для него cref-ссылку, если такие ссылки поддерживаются. |
| T | type | В качестве типа может использоваться класс, интерфейс, структура, перечисление или делегат. |
| C | поле | |
| С | свойство; | Включает индексаторы или другие индексированные свойства. |
| M | method | Включает специальные методы, такие как конструкторы и операторы. |
| E | event | |
| ! | текст ошибки | Остальная часть строки предоставляет сведения об ошибке. Компилятор C# создает сведения об ошибках для ссылок, которые не могут быть разрешены. |
Вторая часть строки содержит полное имя элемента, начиная от корня пространства имен. Имя элемента, включающие типы и пространства имен разделяются точками. Если в имени самого элемента есть точки, они заменяются символами решетки («#»). Предполагается, что в именах элементов не может содержаться символ решетки. Например, полное имя конструктора для объекта String имеет вид System.String.#ctor.
Только для операторов преобразования ( op_Implicit и op_Explicit ) возвращаемое значение метода кодируется как символ
Примеры ниже демонстрируют, как создаются строки идентификаторов для класса и его элементов.
Спецификация языка C#
Дополнительные сведения см. в приложении Спецификация языка C# в комментариях документации.
Рекомендуемые XML-теги для комментариев к документации по C#
В комментариях к документации по C# используются XML-элементы, что позволяет определить структуру выходной документации. Одним из последствий использования этой функции является то, что в комментарии к документации можно добавить любой допустимый XML-код. Компилятор C# копирует эти элементы в выходной XML-файл. Несмотря на то что в комментариях (включая любой допустимый HTML-элемент) можно использовать любой допустимый XML-код, документирование кода рекомендуется по многим причинам.
Далее приводится ряд рекомендаций, распространенные сценарии использования и вопросы, которые нужно иметь в виду при работе с тегами XML-документации в коде C#. Несмотря на то что теги можно поместить в комментарии к документации, в этой статье описываются рекомендуемые теги для наиболее распространенных конструкций языка. Во всех случаях следует соблюдать следующие рекомендации:
XML-файл не предоставляет полную информацию о типе и членах (например, он не содержит никаких сведений о типе). Чтобы получить полную информацию о типе или элементе, используйте файл документации вместе с отражением для текущего типа или элемента.
Некоторые из рекомендуемых тегов можно использовать для любого элемента языка. Другие имеют более специализированное использование. Наконец, некоторые теги используются для форматирования текста в документации. В этой статье описываются рекомендуемые теги, упорядоченные по их использованию.
Комментарии документации не применяются к пространству имен.
Чтобы ввести в текст комментария документации угловые скобки, используйте для символов и > коды HTML и > соответственно. Это показано в следующем примере.
Общие теги
Члены документа
Тег следует использовать в комментариях к объявлению метода для описания возвращаемого значения.
следует использовать в комментариях к объявлению метода для описания одного из параметров такого метода. Чтобы задокументировать несколько параметров, используйте несколько тегов
отображается в IntelliSense, обозревателе объектов и веб-отчете по комментариям к коду.
Тег служит для указания возможных исключений. Этот тег может применяться к определениям методов, свойств, событий и индексаторов.
Форматирование выходных данных документации
создает абзац с двойным отступом. Используйте тег
, если хотите добавить в него один абзац.
Тег используется для указания нескольких строк кода. С помощью тега можно указать, что однострочный текст в описании необходимо пометить как код.
Повторное использование текста документации
Наследование XML-комментариев от базовых классов, интерфейсов и аналогичных методов. Использование inheritdoc позволяет обойтись без копирования и вставки одинаковых XML-комментариев и автоматически поддерживать их синхронизацию. Обратите внимание, что при добавлении тега к типу все члены также будут наследовать эти комментарии.
Тег позволяет задать ссылку на комментарии в другом файле, которые описывают типы и элементы вашего исходного кода. Включение внешнего файла является альтернативой размещению комментариев документации непосредственно в файле исходного кода. Помещая комментарии документации в отдельный файл, вы можете реализовать управление их версиями отдельно от версий исходного кода. В этом случае файл исходного кода может быть извлечен для изменения одним пользователем, а файл документации — другим. Тег использует XML-синтаксис XPath. Сведения об использовании тега см. в документации по XPath.
Создание ссылок и гиперссылок
Атрибут cref
Атрибут cref в теге XML-документации означает «кодовая ссылка». Он указывает, что текст внутри тега представляет собой элемент кода, например тип, метод или свойство. Средства создания документации, такие как DocFX и Sandcastle, используют атрибуты cref для автоматического создания гиперссылок на страницу, где документирован тип или член.
Атрибут href
Атрибут href означает ссылку на веб-страницу. Его можно использовать для прямой ссылки на интерактивную документацию по API или библиотеке.
Универсальные типы и методы
Тег следует использовать в комментариях к объявлению универсального типа или метода для описания параметра типа. Добавьте такой тег для каждого параметра типа универсального типа или метода. Текст для тега будет отображаться в IntelliSense.
Используйте этот тег, чтобы разрешить получателям файла документации форматировать слово определенным образом, например курсивным шрифтом.
Пользовательские теги
Все описанные выше теги распознаются компилятором C#. Тем не менее пользователь может определять собственные теги. Инструменты, такие как Sandcastle, обеспечивают поддержку дополнительных тегов (например, и ) и даже поддержку пространств имен документирования. Средства создания пользовательской или внутренней документации также можно использовать со стандартными тегами. Кроме того, поддерживается несколько выходных форматов — от HTML до PDF.