簡単なRoslynコードアナライザーの作成

こんにちは、Habr！



少し前、 sidristijの CLRiumカンファレンスに行きました。そこでは、MSVS 2015でC＃ソースコードを分析するための非常にシンプルで便利な方法を見ました。



タスクは、私が参加しているプロジェクトから取得されます。参照型の各引数には、NotNull属性またはCanBeNull属性が必要です（ ReSharperではを使用します ）。 もちろん、実際には、プロジェクト自体では、属性はチェックの一部にすぎませんが、これは属性が必須であることを妨げるものではありません。 メソッドまたはコンストラクターに必要な属性が含まれていない場合、アセンブリをチェックしてクラッシュするテストが既にありますが、開発者はそれらを置くのを忘れることがよくあり、ビルドのクラッシュ、コードの更新などにつながります。 ここで、Visual StudioとReSharperがコードがあまり良くないという警告を出すと、時間と神経を節約できます...



実際、新しいスタジオでは、これが可能になります！ さらに、独自のチェックを行うことは非現実的です。



ソースコードはこちらにあります 。



そのため、まずはMicrosoft Visual Studio 2015をダウンロードしておく必要があります。 非常に非標準の翻訳で、ロシア語版を探してダウンロードしなかったため、言語を慎重に選択することをお勧めします。

次に、MSVS「.NET Compiler Platform SDK Templates」の拡張機能をダウンロードする必要があります（ 詳細はこちら 、 Ordosに感謝します ）。

次に、コードアナライザーのプロジェクトを作成します。







その結果、スタジオは3つのプロジェクトを作成します。作業ドラフト、テスト、およびvsix拡張機能の特別なプロジェクトです。 最初のプロジェクトは、アナライザーを実装してコード修正を作成するために必要です。つまり、スタジオで修正を提案するプロンプトが表示されます。 パッケージを配布するには、vsix拡張機能とnugetの2つの方法があります。 1つ目では、プロジェクトに影響を与えることなく、現在のコンピューターにVisual Studioのチェックをインストールできます。 2番目の方法では、開発中（および任意のコンピューターでnugetパッケージがダウンロードされる）、ビルド中（Visual Studioがインストールされていない場合でも）にコードを確認できます。これはVisual Studioの以前のリリースでも機能します。 nugetパッケージを作成するには、nuspecファイルといくつかのスクリプトで十分ですが、vsix拡張機能用の追加プロジェクトが作成されます（ここでは例としてのみ示します）。



テストプロジェクトも興味深いものです。VisualStudioを個別に起動せずにアナライザーをテストおよびデバッグできます。 C＃ファイルを作成し、コンパイラにロードするだけで、警告/エラーリストが返されます！



最初に、Visual Studioはテンプレートアナライザーを作成します。テンプレートアナライザーでは、すべてのタイプで大文字の命名規則が必要です。 そして、テストは彼に基づいています。



動作を変更するには、DiagnosticAnalyzerの下位クラスに次の変更を加えます。



1. DiagnosticIdを独自のものに変更します。 これが警告のキーです（String型を使用）。 彼はプログラマーによってエラーのリストに表示され、CodeFixは彼に反応し、属性SuppressMessageを使用します。 誤って誰かと交差しないように、より本物の名前を選択するのが最善です。 <package nuget name> _ <internal id>：NullCheckAnalyzer_MethodContainsNullsとして選択しました

2.次に、すべての説明を独自のものに変更するのが最適です。メソッドTitle、MessageFormat、Description、Categoryを参照してください。

3.次に、Initializeメソッドで、RegisterSymbolAction関数の引数を変更します。型ではなくメソッドに応答します。 ちなみに、私の研究とRoslynのソースから判断すると、SymbolKindの値の一部はまったくサポートされていません（つまり、パラメーターに応答できないなど）。

3. AnalyzeSymbolメソッドを少し変更します。

-入り口で確認するトークンを取得します

-エラーごとに、コンテキストに関する情報を追加する必要があります。 つまり、1つのメソッドに対して、異なるIDで好きなだけエラーを見つけることができます。



次のコードが判明します。

[DiagnosticAnalyzer(LanguageNames.CSharp)] public class NullCheckAnalyzer : DiagnosticAnalyzer { public const string ParameterIsNullId = "NullCheckAnalyzer_MethodContainsNulls"; // You can change these strings in the Resources.resx file. If you do not want your analyzer to be localize-able, you can use regular strings for Title and MessageFormat. internal static readonly LocalizableString Title = new LocalizableResourceString(nameof(Resources.AnalyzerTitle), Resources.ResourceManager, typeof(Resources)); internal static readonly LocalizableString MessageFormat = new LocalizableResourceString(nameof(Resources.AnalyzerMessageFormat), Resources.ResourceManager, typeof(Resources)); internal static readonly LocalizableString Description = new LocalizableResourceString(nameof(Resources.AnalyzerDescription), Resources.ResourceManager, typeof(Resources)); internal const string Category = "Naming"; internal static DiagnosticDescriptor Rule = new DiagnosticDescriptor(ParameterIsNullId, Title, MessageFormat, Category, DiagnosticSeverity.Warning, isEnabledByDefault: true, description: Description); private static readonly ImmutableArray<DiagnosticDescriptor> supportedDiagnostics = ImmutableArray.Create(Rule); public override ImmutableArray<DiagnosticDescriptor> SupportedDiagnostics => supportedDiagnostics; public override void Initialize(AnalysisContext context) { context.RegisterSymbolAction(AnalyzeSymbol, SymbolKind.Method); } private static void AnalyzeSymbol(SymbolAnalysisContext context) { var methodSymbol = context.Symbol as IMethodSymbol; if (ReferenceEquals(null, methodSymbol) || methodSymbol.DeclaredAccessibility == Accessibility.Private) { return; } foreach (var parameter in ParametersGetter.GetParametersToFix(methodSymbol)) { var type = methodSymbol.ContainingType; // For all such symbols, produce a diagnostic. var diagnostic = Diagnostic.Create(Rule, parameter.Locations[0], methodSymbol.Name, type.Name, parameter.Name); context.ReportDiagnostic(diagnostic); } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、小さなアナライザーは既にVisual Studioでエラーをスローします。 テストするには、テストを実行します。 マイクロソフトは、空のファイルが正しいことを確認することと、診断と修正が正しく機能することを確認することの2つを慎重に作成しました。 まだコード修正を行っていないため、最初のものは正しく完了し、2番目のものは失敗します。



私はすぐにコード修正を試みましたが、そのような単純な修正でさえ、それほど簡単に解決できないニュアンスが既に含まれていることに気付きました。

-どのネームスペースからNotNull属性を追加しますか？ Resharperから。 そして、いくつかのオプションがある場合：あなたの属性とResharperからのパッケージ？

-使用して追加する方法：名前空間内、またはファイルの上に？ 衝突はありますか？ おそらく、エイリアスを登録する方が良いでしょうか？

-属性を持つアセンブリへのリンクがない場合は、それを追加する必要がありますが、どのようなルールですか？ 最初のものを取得するか、nugetからダウンロードしてみますか？ または企業のナゲットリポジトリから？



いくつかの修正を試みた後、私はそれに気付きました：

1.動作します。 Roslynは実際に属性を追加し、結果をコンパイルします。

2.アルゴリズムは非常に単純です。必要な* Syntax要素を見つけ、SyntaxFactoryを使用して正しいものを作成し、ReplaceNodeを呼び出す必要があります。

3.正しいコード修正は、一見したほど簡単ではありません。 また、問題のある解決策を提案する代わりに、プログラマーに自分で修正するように依頼することをお勧めします。



アナライザーをテストするには、Nugetパッケージをインストールするだけです（つまり、パッケージマネージャーコンソールでコマンドInstall-Package NullCheckAnalyzerを入力します）。 ただし、ほとんどの場合、最初にPowerShellスクリプトにエラーが含まれるため、コンパイルしたパッケージは機能しません。何らかの理由で、アナライザーでdllパスに「C＃」サブフォルダーが追加されます。 したがって、これらの行はここで行うように変更するのが最適です 。 これらの手順の後、nugetパッケージの準備ができました。nuget.orgにアップロードして、プロジェクトに追加できます。



そして、Microsoft Visual Studio 2015では次のようになります。





その結果、出力では拡張子が取得されます。

1. Nugetを介して接続および更新する

2.書き込みおよびコンパイル中にコードをチェックします（MSVSなしを含む）

3.簡単かつ迅速に書かれているため、企業での平均的なプルリクエストのレビューに時間がかかる



最後に、いくつかのヒント：

1.ご覧のとおり、Microsoftは不変型を好みました。 したがって、ほとんどのコード修正コンストラクトを事前に作成してから、リンクを提供するだけです。

2.テストプロセスでは、1つのファイルのみを簡単に確認できるため、部分クラスやその他のマルチファイルデザインのオプションを具体的に提供することをお勧めします

3. Roslynのリリースバージョンはまだないため、APIは若干変更される可能性があります。 すでに、 一部のStackoverflowの回答には古いAPIヒントがあります。

4. Ordosは、 同様の説明を含むインターネット上のページを提案しました。