monodocer - En ligne dans le Cloud

PROGRAMME:

Nom

monodocer - Support de format de documentation ECMA

SYNOPSIS

monodocteur [CHOIX]*

OPTIONS

-assemblage:ASSEMBLAGE
ASSEMBLÉE est un assembly .NET pour générer des talons de documentation.

Spécifiez un chemin de fichier ou le nom d'un assembly GAC.

-effacer
Autoriser monodocer à supprimer des membres des fichiers de documentation. Les seuls membres
supprimés sont pour les membres qui ne sont plus présents au sein de l'assemblée.

Si un type n'est plus présent, le fichier de documentation est pas supprimé, mais est
plutôt ; renommé avoir un .supprimer extension.

- ?, -Aide
Afficher les informations sur les arguments du programme.

-ignorer les souvenirs
Ne pas mettre à jour les membres.

Cela ajoutera des talons de documentation pour les types ajoutés, mais pas ajouter ou retirer
documentation pour tous les membres de tout type (y compris tous les types ajoutés).

-importslashdoc:FICHIER
DOSSIER est un fichier XML généré avec le /doc:FICHIER Indicateur du compilateur C# (par exemple mcs
-doc:toto.xml foo.cs ). Importez la documentation du membre contenue dans DOSSIER développement
le format de documentation utilisé par monodoc.

-nom nom
Nom est le nom du projet auquel cette documentation est destinée.

Cela définit le /Aperçu/Titre élément au sein de la index.xml fichier créé au
répertoire spécifié par -chemin . Ceci est utilisé par certains programmes pour les informations sur le titre
(par exemple monodocs2html ).

-espace de noms : espace de noms
Mettre à jour uniquement les types dans l'espace de noms ESPACE DE NOMS .

-remplacements
Inclure les méthodes remplacées dans la documentation.

Ce n'est normalement pas nécessaire, car le navigateur de documentation Mono fournira un
lien vers les membres du type de base de toute façon, tout comme monodocs2html si le type de base est
au sein d'une même assemblée.

-chemin:SORTIE_DIR
SORTIE_DIR est le répertoire qui contiendra les talons de documentation nouveaux/mis à jour.

-joli
Indentez bien les fichiers XML.

-depuis : DEPUIS
Créer un élément pour les types et membres ajoutés avec la valeur DEPUIS .

Par exemple, lorsqu'on lui donne -depuis:"Gtk# 2.4 un élément sera inséré dans le Docs
élément pour tous les types et membres de type ajoutés :

Le navigateur de documentation Mono et monodocs2html utilisera cet élément pour spécifier
dans quelle version un membre a été ajouté.

-type:TYPE
Ne créer/mettre à jour la documentation que pour le type TYPE .

-updateto:CHEMIN
Lors de la mise à jour de la documentation, écrivez les fichiers de documentation mis à jour dans le
annuaire PATH .

-V, -version
Afficher les informations de version et de licence.

DESCRIPTION

monodocteur a été obsolète par mdoc(1). Voir le mdoc-mise à jour(1) page de manuel.

monodocteur est un programme qui crée des talons de documentation XML dans la documentation ECMA
Format. Il ne repose pas sur la documentation trouvée dans le code source.

Les avantages sont:

* Code lisibilité. Une bonne documentation est souvent (a) verbeuse et (b) remplie
avec des exemples. (Pour comparaison, comparez la documentation Microsoft .NET Framework,
qui est souvent une page ou plus de docs pour chaque membre, à la documentation JavaDoc,
qui peut souvent être une phrase pour chaque membre.)

L'insertion d'une bonne documentation dans le code source peut fréquemment gonfler la source
fichier, car la documentation peut être plus longue que la méthode réelle qui est
documenté.

* Localisation Formats de documentation dans la source (tels que /doc ) n'ont aucun support pour
plusieurs langues humaines. Si vous devez prendre en charge plus d'une langue humaine pour
à des fins de documentation, monodocteur est utile car il permet à chaque langue d'obtenir son
propre répertoire, et monodocteur peut ajouter des types/membres pour chaque documentation distincte
répertoire.

* Administration. Il n'est pas rare d'avoir une documentation et un développement séparés
équipes. Il est également possible que l'équipe de documentation ait une expérience minimale
avec le langage de programmation utilisé. Dans de telles circonstances, en ligne
la documentation n'est pas souhaitable car l'équipe de documentation pourrait insérer par inadvertance
une erreur dans le code source lors de la mise à jour de la documentation. Alternativement, vous
peut ne pas vouloir que l'équipe de documentation ait accès au code source pour la sécurité
les raisons. monodocteur permet de conserver la documentation complètement séparé et
distinct du code source utilisé pour créer l'assembly.

Pour tourner le monodocteur documentation en quelque chose qui peut être consommé par le Mono
Navigateur de documentation (le navigateur d'aide du bureau, ou l'interface Web pour celui-ci), il est
nécessaire de compiler la documentation dans un format compressé. Cela se fait avec le
l'outil mdassembler, par exemple, vous pouvez utiliser cette chaîne d'outils comme ceci :

$ monodocer -assembly:MyWidgets -path:generated_docs
$ mdassembler --ecma generate_docs -out:MyWidgets

Ce qui précède générerait un MyWidgets.zip et un MyWidgets.tree qui peuvent ensuite être installés
dans le système. En plus des deux fichiers (.zip et .tree) vous devez fournir un .sources
qui décrit où dans le système d'aide la documentation doit être connectée, il est
un fichier XML très simple, comme celui-ci :

<? Xml version = "1.0"?>




Le fichier de configuration ci-dessus décrit que la documentation est au format ECMA (le
version compilée) que le nom du fichier de base est MyWidgets et qu'il doit être connecté à
la partie "classlib-gnome" de l'arborescence. Si vous voulez regarder les différents nœuds définis
dans la documentation, vous pouvez consulter le fichier monodoc.xml qui est généralement installé dans
/usr/lib/monodoc/monodoc.xml.

Une fois que vous avez tous vos fichiers (.zip, .tree et .sources), vous pouvez les installer dans le
système avec la commande suivante :

$ cp MesWidgets.tree MesWidgets.zip MesWidgets.source `pkg-config monodoc --variable sourcesdir`

Ce qui précède copiera les fichiers dans le répertoire que Monodoc a enregistré (vous pouvez
besoin d'autorisations root pour ce faire). Le répertoire réel est renvoyé par le pkg-config
invocation.

STRING ID Format

Les ID de chaîne sont utilisés pour faire référence à un type ou à un membre d'un type. Les identifiants de chaîne sont documentés dans
ECMA-334 3e édition, annexe E.3.1. Ils se composent d'un membre type préfixe , le type complet
name (espace de noms + nom, séparé par '.'), éventuellement suivi du nom du membre et d'autres
</br>L’Information.

Préfixes de type de membre :

E: L'ID de chaîne fait référence à un événement. Le nom de l'événement suit le nom du type :
E:System.AppDomain.AssemblyLoad

F: L'ID de chaîne fait référence à un champ. Le nom du champ suit le nom du type :
F:System.Runtime.InteropServices.DllImportAttribute.SetLastError

M: Fait référence à un constructeur ou à une méthode. Les constructeurs s'ajoutent .cteur au nom du type,
tandis que les méthodes ajoutent le nom de la méthode (avec un décompte facultatif du nombre de
paramètres génériques).

Si le constructeur ou la méthode prend des arguments, ceux-ci sont listés entre parenthèses
après le nom du constructeur/de la méthode :

M:Système.Objet..cteur , M:System.String..ctor(System.Char[]) ,
M:System.String.Concat(System.Object) , M:System.Array.Sort``1(``0[]) ,
M:System.Collections.Generic.List`1..cteur ,
M:System.Collections.Generic.List`1.Add(`0) .

N: Fait référence à un espace de noms, par exemple N : Système

P: Fait référence à une propriété. Si la propriété est un indexeur ou prend des paramètres, le
les types de paramètres sont ajoutés au nom de la propriété et entourés de parenthèses :
P:System.String.Length , P:System.String.Chars(System.Int32) .

T: L'ID de chaîne fait référence à un type, avec le nombre de types génériques ajouté :
T:Système.String , T:System.Collections.Generic.List`1

Pour rendre les choses plus intéressantes, les types génériques et les membres ont deux représentations : le
représentation « non liée » (montrée dans les exemples ci-dessus), dans laquelle les noms de classe ont le nombre de
paramètres génériques ajoutés à leur nom. Il y a aussi une représentation « liée », en
dont la liaison de paramètres génériques est répertoriée dans '{' et '}'.

Non lié: T:System.Collections.Generic.List`1 , T:System.Collections.Generic.Dictionary`2 .

Bondir: T :System.Collections.Generic.List{System.Int32}
T :System.Collections.Generic.Dictionary{System.String,System.Collections.Generic.List{System.Predicate{System.String}}}
.

Comme vous pouvez le voir, les variantes liées peuvent être arbitrairement complexes (tout comme les génériques).

De plus, si un paramètre générique est lié au paramètre générique d'un type ou d'une méthode,
l'"index" du paramètre générique du type/de la méthode est utilisé comme liaison, ainsi donné
classe FooType {
vide statique public Foo (System.Prédicat prédicat) {}
}
L'ID de chaîne pour cette méthode est M:FooType.Foo``1(System.Predicate{``0}) , comme ``0 est le
0ème indice de paramètre générique qui est lié à Système.Prédicat .

DOCUMENTATION Format

monodocteur génère une documentation similaire au format de documentation Ecma, comme décrit
dans ECMA-335 3e édition, partition IV, chapitre 7.

La principale différence avec le format ECMA est que chaque type obtient son propre fichier, dans
un répertoire identique à l'espace de noms du type.

La plupart des informations contenues dans la documentation doivent pas être édité. Cela inclut le
tapez le nom ( /Type/@NomComplet ), interfaces implémentées ( /Type/Interfaces ), membre
informations ( /Type/Membres/Membre/@NomMembre , /Type/Membres/Membre/MembreSignature ,
/Type/Membres/Membre/TypeMembre , /Type/Membres/Membre/Paramètres , Etc).

Ce que devrait être modifié sont tous les éléments avec le texte À be ajouté. , qui sont présents
sous le //Documents éléments (par ex. /Type/Documents , /Type/Membres/Membre/Docs ). Les contenus
des Docs l'élément est identique en sémantique et structure à la documentation C# en ligne
format, composé de ces éléments (énumérés dans ECMA-334 3e édition, annexe E, section 2).
Les éléments suivants sont utilisés dans les descriptions des éléments :

CREF Fait référence à une référence de classe (ou de membre) et est une chaîne au format décrit
ci-dessus dans le STRING ID Format .

TEXTE Le texte non XML et XML ne doivent pas être imbriqués.

XML Seuls les éléments XML doivent être imbriqués (qui peuvent indirectement contenir du texte), mais non
le texte d'espacement ne doit pas être un nœud enfant immédiat.

XML_TEXTE
Texte de forme libre et XML, afin que d'autres éléments XML puissent être imbriqués.

Les éléments suivants sont utilisés dans la documentation :

<bloquer subset="SOUS-ENSEMBLE" type="TYPE">XML_TEXT
Créez un bloc de texte, de concept similaire à un paragraphe, mais est utilisé pour créer
divisions dans le texte. Dans une certaine mesure, un est équivalent au HTML
étiqueter.

SOUS-ENSEMBLE devrait toujours être la valeur aucun .

TYPE spécifie l'en-tête et la mise en forme à utiliser. Les types reconnus sont :

comportements Crée une section avec le titre Opération .

noter Crée une section avec le titre Attention: .

remplacements Crée une section avec le titre Notes à Héritiers .

usage Crée une section avec le titre Utilisation .

XML_TEXTE
Définissez le texte dans une police de type code (similaire à l' élément HTML ).

<code lang="LANGUE">TEXTE
Affichez plusieurs lignes de texte dans une police de type code (similaire au code HTML
élément). LANGUAGE est la langue pour laquelle ce bloc de code est destiné. Par exemple, si
LANGUAGE is C# , puis TEXTE obtiendra la coloration syntaxique pour le langage C# dans
le navigateur de documentation Mono.

XML_TEXTE
Indique un exemple qui doit être affiché spécialement. Par exemple:

Un paragraphe d'introduction.

classe Exemple {
vide statique public principal ()
{
System.Console.WriteLine ("Bonjour, tout le monde!");
}
}



<exception cref="CREF">XML_TEXT
Identifie une exception qui peut être levée par le membre documenté.

est un élément de niveau supérieur et doit être imbriqué directement sous le
.

CREF est le type d'exception qui est levée, tandis que XML_TEXTE contient l'
circonstances qui causeraient CREF être jeté.

était .


XML
Créez une liste ou un tableau d'éléments. utilise imbriquées XML ,
XML , XML_TEXTE et
XML_TEXTE éléments.

Liste avoir la syntaxe :

Puce 1
Puce 2
Puce 3


Tables avoir la syntaxe :


Colonne 1
Colonne 2
Colonne 3


Article 1-A
Article 1-B
Article 1-C


Article 2-A
Article 2-B
Article 2-C



XML_TEXTE
Insérer un paragraphe de XML_TEXTE
. Ceci est destiné à être utilisé dans d'autres balises, telles que , ,
, ainsi que (voir , ci-dessus) et la plupart des autres éléments.

Par exemple,
Ceci est un paragraphe de texte.

<paramètre nom="NOM">XML_TEXT
est un élément de niveau supérieur et doit être imbriqué directement sous le
.

Décrit le paramètre Nom du constructeur, de la méthode ou de la propriété en cours :

UNE contenant le numéro
de widgets à traiter.


<paramref nom="NOM" />
Indique que Nom est un paramètre.

Cela rend généralement Nom comme texte en italique, il est donc fréquemment (ab)utilisé comme un
équivalent à l' élément HTML . Voir le documentation (ci-dessus)
à titre d'exemple.

<permission cref="CREF">XML_TEXT
Documente les exigences d'accessibilité en matière de sécurité du membre actuel.

est un élément de niveau supérieur et doit être imbriqué directement sous le
.

CREF est une référence de type à l'autorisation de sécurité requise, tandis que XML_TEXTE est une
description de la raison pour laquelle l'autorisation est requise.

Nécessite une autorisation pour lire et écrire des fichiers. Voir
,
.


XML_TEXTE
Contient des informations détaillées sur un membre.

est un élément de niveau supérieur et doit être imbriqué directement sous le
.
Insérez des informations détaillées ici.

XML_TEXTE

est un élément de niveau supérieur et doit être imbriqué directement sous le
.

Décrit la valeur de retour d'une méthode :

UNE en précisant si
ou non le processus peut accéder
.


<see cref="CREF" />
Crée un lien vers le membre spécifié dans le texte actuel :


<seealso cref="CREF" />

est un élément de niveau supérieur et doit être imbriqué directement sous le
.

Permet de générer une entrée pour le See Aussi paragraphe. Utilisation spécifier
un lien dans le texte.


<depuis version="VERSION" />

est un élément de niveau supérieur et doit être imbriqué directement sous le
.

Permet de spécifier quelle version a introduit le type ou le membre spécifié.


LA DESCRIPTION

est un élément de niveau supérieur et doit être imbriqué directement sous le
.

Fournit un (bref !) aperçu d'un type ou d'un membre de type.

Ceci est généralement affiché dans le cadre d'une déclaration de classe, et devrait être un
description assez courte du type/membre. Utilisation pour plus de détails
</br>L’Information.

<typeparam nom="NOM">DESCRPITION
est un élément de niveau supérieur et doit être imbriqué directement sous le
.

Ceci est utilisé pour décrire le paramètre de type pour un type générique ou une méthode générique.

Nom est le nom du paramètre de type, tandis que DESCRIPTION contient une description de
le paramètre (à quoi il sert, à quelles restrictions il doit répondre, etc.).
Le type de la collection sous-jacente


Utilisé pour indiquer qu'un mot est un paramètre de type, à utiliser dans d'autres blocs de texte
(par exemple dans ).
Si est une structure, alors...

LA DESCRIPTION
est un élément de niveau supérieur et doit être imbriqué directement sous le
.

Permet de décrire une propriété.

UNE contenant un nom de widget.

Utiliser monodocer en ligne en utilisant les services onworks.net