Cette page contient des réponses à certaines questions fréquemment posées sur l’analyse du code basée sur la plateforme du compilateur .NET dans Visual Studio.
Analyse du code et EditorConfig
Dois-je utiliser l’analyse du code ou EditorConfig pour vérifier le style de code ?
L’analyse du code et les fichiers EditorConfig fonctionnent main dans la main. Lorsque vous définissez des styles de code dans un fichier EditorConfig ou dans la page Options de l’éditeur de texte , vous configurez réellement les analyseurs de code intégrés à Visual Studio. Les fichiers EditorConfig peuvent être utilisés pour activer ou désactiver des règles d’analyseur, ainsi que pour configurer des packages d’analyseur NuGet.
EditorConfig et ensembles de règles
Dois-je configurer mes analyseurs à l’aide d’un ensemble de règles ou d’un fichier EditorConfig ?
Les ensembles de règles et les fichiers EditorConfig peuvent coexister et peuvent être utilisés pour configurer des analyseurs. Les fichiers EditorConfig et les ensembles de règles vous permettent d’activer et de désactiver des règles et de définir leur gravité.
Toutefois, dans Visual Studio 2019 version 16.5 et ultérieure, les fichiers de jeu de règles sont déconseillés en faveur des fichiers EditorConfig, et les projets .NET Core et .NET 5+ ne prennent pas en charge toutes les commandes de menu du jeu de règles. Pour plus d’informations, consultez Convertir un fichier de jeu de règles existant en fichier EditorConfig.
Les fichiers EditorConfig offrent des moyens supplémentaires de configurer des règles :
- Pour les analyseurs de qualité du code .NET, les fichiers EditorConfig vous permettent de définir les types de code à analyser.
- Pour les analyseurs de style de code .NET et les analyseurs de qualité du code .NET, les fichiers EditorConfig vous permettent de définir les styles de code préférés pour une base de code.
Outre les ensembles de règles et les fichiers EditorConfig, certains analyseurs sont configurés à l’aide de fichiers texte marqués comme fichiers supplémentaires pour les compilateurs C# et VB.
Note
- Les fichiers EditorConfig ne peuvent être utilisés que pour activer des règles et définir leur gravité dans Visual Studio 2019 version 16.3 et ultérieure.
- Les fichiers EditorConfig ne peuvent pas être utilisés pour configurer l’analyse héritée, tandis que les ensembles de règles peuvent.
Analyse du code dans les builds d’intégration continue (CI)
L’analyse du code basée sur la plateforme du compilateur .NET fonctionne-t-elle dans les builds d’intégration continue (CI) ?
Yes. Pour les analyseurs installés avec le Kit de développement logiciel (SDK) .NET 5.0 ou version ultérieure, ou à partir d’un package NuGet, ces règles sont appliquées au moment de la génération, notamment pendant une build CI. Les analyseurs utilisés dans les builds CI respectent la configuration des règles à partir des jeux de règles et des fichiers EditorConfig. À compter de .NET 5.0, les analyseurs de style de code intégrés à Visual Studio sont également inclus dans le Kit de développement logiciel (SDK) .NET, et la plupart d’entre eux sont applicables dans une build CI. Pour plus d’informations, consultez Activer sur la build.
Analyseurs IDE et StyleCop
Quelle est la différence entre les analyseurs de code DE l’IDE Visual Studio et les analyseurs StyleCop ?
L’IDE Visual Studio inclut des analyseurs intégrés qui recherchent à la fois des problèmes de style de code et de qualité. Ces règles vous aident à utiliser de nouvelles fonctionnalités de langage à mesure qu’elles sont introduites et améliorent la facilité de maintenance de votre code. Les analyseurs IDE sont continuellement mis à jour avec chaque version de Visual Studio.
Les analyseurs StyleCop sont des analyseurs tiers installés en tant que package NuGet qui vérifient la cohérence des styles dans votre code. En général, les règles StyleCop vous permettent de définir des préférences personnelles pour une base de code sans recommander un style sur un autre.
Analyseurs de code et analyse héritée
Quelle est la différence entre l’analyse héritée et l’analyse de code basée sur la plateforme du compilateur .NET ?
L’analyse du code basé sur la plateforme du compilateur .NET analyse le code source en temps réel et pendant la compilation, tandis que l’analyse héritée analyse les fichiers binaires une fois la génération terminée. Pour plus d’informations, consultez l’analyse basée sur la plateforme du compilateur .NET et l’analyse héritée.
Analyseurs FxCop et analyseurs .NET
Quelle est la différence entre les analyseurs FxCop et les analyseurs .NET ?
Les analyseurs FxCop et les analyseurs .NET font référence aux implémentations d’analyseurs de la plateforme de compilateur .NET (« Roslyn ») des règles d’autorité de certification FxCop. Avant Visual Studio 2019 16.8 et .NET 5.0, ces analyseurs sont fournis en tant que Microsoft.CodeAnalysis.FxCopAnalyzerspackage NuGet. À compter de Visual Studio 2019 16.8 et .NET 5.0, ces analyseurs sont inclus dans le Kit de développement logiciel (SDK) .NET. Ils sont également disponibles en tant que Microsoft.CodeAnalysis.NetAnalyzerspackage NuGet. Envisagez de migrer des analyseurs FxCop vers des analyseurs .NET.
Traiter les avertissements comme des erreurs
Mon projet utilise l’option de génération pour traiter les avertissements comme des erreurs. Après la migration de l’analyse héritée vers l’analyse du code source, tous les avertissements d’analyse du code apparaissent désormais sous forme d’erreurs. Comment puis-je empêcher cela ?
Pour empêcher les avertissements d’analyse du code d’être traités comme des erreurs, procédez comme suit :
Créez un fichier .props avec le contenu suivant :
<Project> <PropertyGroup> <CodeAnalysisTreatWarningsAsErrors>false</CodeAnalysisTreatWarningsAsErrors> </PropertyGroup> </Project>Ajoutez une ligne à votre fichier projet .csproj ou .vbproj pour importer le fichier .props que vous avez créé à l’étape précédente. Cette ligne doit être placée avant toutes les lignes qui importent les fichiers .props de l’analyseur. Par exemple, si votre fichier .props est nommé codeanalysis.props :
... <Import Project="..\..\codeanalysis.props" Condition="Exists('..\..\codeanalysis.props')" /> <Import Project="..\packages\Microsoft.CodeAnalysis.NetAnalyzers.5.0.0\build\Microsoft.CodeAnalysis.NetAnalyzers.props" Condition="Exists('..\packages\Microsoft.CodeAnalysis.NetAnalyzers.5.0.0\build\Microsoft.CodeAnalysis.NetAnalyzers.props')" /> ...
Page de propriétés de la solution d’analyse du code
Où se trouve la page de propriétés Analyse du code pour la solution ?
La page de propriétés Analyse du code au niveau de la solution a été supprimée en faveur du groupe de propriétés partagés plus fiable. Pour gérer l’analyse du code au niveau du projet, la page de propriétés Analyse du code est toujours disponible. (Pour les projets gérés, nous vous recommandons également de migrer des ensembles de règles vers EditorConfig pour la configuration des règles.) Pour partager des ensembles de règles entre plusieurs projets d’une solution ou d’un dépôt, nous vous recommandons de définir un groupe de propriétés avec la propriété CodeAnalysisRuleSet dans un fichier de propriétés/cibles partagé ou un fichier Directory.props/Directory.targets . Si vous n’avez pas de propriétés ou de cibles courantes que tous vos projets importent, vous devez envisager d’ajouter un groupe de propriétés de ce type à un fichier Directory.props ou à un fichier Directory.targets dans un répertoire de solution de niveau supérieur, qui est automatiquement importé dans tous les fichiers projet définis dans le répertoire ou ses sous-répertoires.