J'ai un projet avec plus de 500 Missing XML Comment des avertissements. Je sais que je peux supprimer la fonction Commentaire XML ou coller des extraits de commentaires vides partout, mais je préférerais une solution générique qui me permettrait d'effectuer une seule modification pour désactiver tous les avertissements de ce type.
Ce que je fais en ce moment, c'est mettre
///<Summary>
///
///</Summary>ou
#pragma warning disable 1591J'étais juste curieux de savoir si c'était possible.
Comme suggéré ci-dessus, en général, je ne pense pas que ces avertissements doivent être ignorés (supprimés). Pour résumer, les moyens de contourner l'avertissement seraient les suivants :
Properties > Build > Errors and warnings > Suppress warnings en entrant 1591Properties > Build > Output
#pragma warning disable 1591 en haut du fichier correspondant et #pragma warning restore 1591 au fond
S'il vous plaît, n'utilisez pas GhostDoc. Si un commentaire peut être déduit du nom de la méthode, il peut être mieux déduit par un humain. Cela n'ajoute aucune valeur. Ce temps serait mieux utilisé à vous féliciter d'avoir une méthode bien nommée.
Je ne suis pas d'accord, GhostDoc m'aide à ajouter rapidement la liste des paramètres requis et une balise de retour (si la méthode n'est pas nulle). Je l'utilise et l'apprécie, et je connais pas mal d'autres personnes qui l'utilisent aussi. Il est vrai, cependant, que la description dans le résumé peut nécessiter quelques modifications, mais cela compte pour la plupart des automatismes dans de tels cas.
S'il ne faisait qu'ajouter des espaces réservés, ce serait un gain de temps appréciable, mais le nombre de bases de code que j'ai vu où les développeurs laissent le texte généré nous fait penser que nous ne sommes pas collectivement assez matures pour l'utiliser. Les commentaires sont une béquille (souvent nécessaire) pour le code qui n'est pas auto-documenté et en offrant des raccourcis, cet outil a un bénéfice net négatif sur le code mondial.
Vous pouvez également modifier les paramètres de votre projet .csproj pour inclure un <noWarn>1591</noWarn> à l'intérieur de la première balise <PropertyGroup> . Originellement de L'article d'Alexandru Bucur ici
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
...
<NoWarn>1591</NoWarn>
</PropertyGroup>
...
</Project>
C'est une bonne approche tant que vous n'avez pas besoin de générer les documents XML et que les commentaires XML ne sont pas validés.
Cela ne fonctionne pas si vous voulez conserver les avertissements des fichiers qui ne sont pas générés automatiquement. Supprimer tous les avertissements juste pour se débarrasser d'un sous-ensemble d'avertissements me semble un peu exagéré. En outre, dans la plupart des entreprises, il est courant de créer des commentaires XML dans tous les fichiers qui ne contiennent pas de code généré automatiquement. Par ailleurs, l'utilisateur a demandé une solution qui ne supprime pas simplement la fonction de commentaire XML, ce qui ne répond donc pas à sa question.
Cela aurait dû être un commentaire, mais je n'ai pas réussi à l'adapter à la limite :
J'aimerais les désactiver uniquement pour les importations de Reference.cs et WebService. En fait, j'utilise une macro pour le faire pour un fichier. Il suffit d'ouvrir le fichier et d'exécuter cette macro (testé dans VS2010) :
Sub PragmaWarningDisableForOpenFile()
DTE.ActiveDocument.Selection.StartOfDocument()
DTE.ActiveDocument.Selection.NewLine()
DTE.ActiveDocument.Selection.LineUp()
DTE.ActiveDocument.Selection.Insert("#pragma warning disable 1591")
DTE.ActiveDocument.Selection.EndOfDocument()
DTE.ActiveDocument.Selection.NewLine()
DTE.ActiveDocument.Selection.Insert("#pragma warning restore 1591")
DTE.ActiveDocument.Save()
End SubIl n'y a vraiment aucun moyen de faire cela automatiquement ? Il faudrait le refaire à chaque fois que le code généré automatiquement remplace le fichier.
Je pense que cet avertissement ne devrait pas s'afficher pour le contenu généré automatiquement, peut-être devrez-vous vérifier le paramètre correspondant dans les propriétés du projet.
Non, il suffit d'activer les avertissements XML-Comment pour que tout cela apparaisse. Et il n'existe pas d'option permettant de les désactiver uniquement pour le code autogénéré. C'est pourquoi il faut le couper lorsque vous avez besoin de régénérer le code.
Propriétés en cours de projet Code Analysis il existe une option Supress results from generated code . Devoir réexécuter une macro après chaque régénération de code n'est pas vraiment une solution, selon moi. Si l'option ci-dessus ne fonctionne pas pour vous, peut-être le générateur de code peut-il être ajusté pour ajouter automatiquement la directive pragma à la place ?
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
3 votes
Quelle est la question réelle ? Voulez-vous connaître un autre moyen de désactiver les avertissements qui sont générés lorsque les commentaires XML sont manquants ? Dans les propriétés du projet, allez dans l'onglet "Build" et décochez "Fichier de documentation XML". Cependant, je vous suggère de ne pas supprimer les avertissements mais d'ajouter la documentation manquante.
0 votes
C'est tout à fait correct, mais j'étais juste curieux de savoir si nous pouvions résoudre ce problème à partir d'un seul endroit, car je suis novice en la matière.
0 votes
Ces questions connexes peuvent vous aider : stackoverflow.com/questions/11444631/ stackoverflow.com/questions/3630282/
1 votes
L'avertissement n'apparaît que pour les membres qui sont visibles par d'autres assemblées. Souvent, les gens font des classes (et des interfaces, des enums, etc.)
publicsans raison valable. Dans ce cas, une solution facile (et à mon avis bonne) consiste à supprimer le motpublic(ou le remplacer par une redondanteinternalselon le style préféré) à partir du type le plus extérieur. Tous les avertissements CS1591 concernant ce type et ses membres disparaissent alors. Bien sûr, vous devrez peut-être encore conserver un peu de typespublic. Mais dans ce cas, il est juste que vous exigiez de documenter correctement leurs parties publiques.