Format MSBuild et Visual Studio pour les messages de diagnostic

Quand un outil qui génère du texte est exécuté, MSBuild examine le texte à la recherche d’erreurs et d’avertissements. De nombreux outils utilisent un format connu pour signaler ces messages. Par défaut, MSBuild examine le texte et signale les erreurs et/ou les avertissements en fonction de la sortie. Ce comportement peut être augmenté ou désactivé à l’aide des paramètres suivants sur la tâche Exec : IgnoreStandardErrorWarningFormat, CustomErrorRegularExpression et CustomWarningRegularExpression.

Examinez les quatre messages suivants, qui sont tous correctement mis en forme et seront reconnus par MSBuild et Microsoft Visual Studio :

Main.cs(17,20): warning CS0168: The variable 'x' is declared but never used
C:\dir1\strings.resx(2) : error BC30188: Declaration expected.
cl : Command line warning D4024 : unrecognized source file type 'file1.cs', object . . .
error CS0006: Metadata file 'System.dll' could not be found.

Ces messages sont conformes au format spécial en cinq parties présenté ici. L’ordre de ces parties est important et ne doit pas changer.

Origin : Subcategory Category Code : Text

Par exemple,

c1 : Command line warning D4024 : unrecognized source file type 'test.xyz'

Origin: c1
Subcategory: Command line
Category: warning
Code: D4024
Text: unrecognized source file type 'test.zyz'

Chacun des composants de ce format est décrit comme suit :

• Origine (obligatoire) L’origine peut être vide. Si elle est fournie, l’origine est généralement un nom d’outil, comme cl dans l’un des exemples. Mais elle peut également correspondre à un nom de fichier, tel que « Main.cs », illustré dans un autre exemple. S’il s’agit d’un nom de fichier, il doit s’agir d’un nom de fichier absolu ou relatif, suivi d’informations de ligne/colonne facultatives entre parenthèses sous l’une des formes suivantes :

  (line) or (line-line) or (line-col) or (line,col-col) or (line,col,line,col)
  

  Les lignes et les colonnes commencent à 1 dans un fichier. Ainsi, le début d’un fichier est 1 et la colonne la plus à gauche est 1. Si l’origine est un nom d’outil, il ne doit pas changer en fonction des paramètres régionaux. Autrement dit, il doit être neutre par rapport aux paramètres régionaux.

• Sous-catégorie (facultatif) La sous-catégorie est utilisée pour classer davantage la catégorie elle-même. Elle ne doit pas être localisée.

• Catégorie (obligatoire) La catégorie doit être « erreur » ou « avertissement ». La casse n’a pas d’importance. Comme avec l’origine, la catégorie ne doit pas être localisée.

• Code (facultatif) Le code identifie un code d’erreur/un code d’avertissement spécifique à l’application. Le code ne doit pas être localisé et ne doit pas contenir d’espaces.

• Texte Texte convivial qui explique l’erreur et qui doit être localisé si vous prenez en charge plusieurs paramètres régionaux.

Quand MSBuild appelle des outils en ligne de commande (par exemple, csc.exe ou vbc.exe), il examine la sortie émise par l’outil vers les flux d’erreur standard et de sortie standard. Toutes les lignes qui correspondent au format d’erreur décrit ci-dessus seront traitées spécialement. Ainsi, les lignes reconnues en tant qu’erreurs ou avertissements seront transformées en erreurs de build ou en avertissements, respectivement. Pour voir les avantages réels de cela, vous devez créer au sein d’un outil de développement comme Visual Studio ou VS Code. Comme MSBuild traite ces messages spécialement, ils sont consignés en tant qu’avertissements et erreurs de première classe dans la liste des tâches Visual Studio. Si l’origine spécifie des informations de ligne/colonne, un double-clic sur le message vous dirige vers la source de l’erreur dans le fichier incriminé.

Contenu connexe

• Diagnostic des échecs de tâches
• Exec (tâche)