問題タブ [roslyn-code-analysis]

ライブラリが適切に使用されているかどうかを確認するコード分析を書いています。そのためには、プロジェクト (= 分析されたドキュメントの親プロジェクト) によってどのアセンブリが参照されているかを知る必要があります。そのコンテキストには Document プロパティが含まれているため、CodeRefactoringProviders で可能です。ドキュメントから、プロジェクトとその参照にアクセスできます。

しかし、CodeAnalysis コンテキスト (SyntaxNodeAnalysisContext など) から情報を取得する方法がわかりません。

CodeFixProvider では、ラッピングする if-condition (たとえば) を削除する必要があります。

そして、調整された内部表現のみを残したい:

「if-block」のノードを line-line ステートメントに置き換えようとするとすぐに、「キャストできません」という例外がスローされます。あなたはそれを行う適切な方法を知っていますか？

VS 2015 にアップグレードして以来、私のチームはランダムな奇妙なことを経験しており、現在 Microsoft で解決されていると確信しています。非常に厄介な問題の 1 つは、特に分岐後に、プロジェクトの参照が失われているように見えることです。私は昨日、ソリューションの新しいブランチに取り組み始めましたが、型が認識されておらず、名前空間の使用が不要であると引用されていることがわかりました (それらは突然認識されなくなった型のためだったため)。

プロジェクト内の参照には、参照の問題を示すアイコンは表示されませんでしたが、機能するかどうかを確認するために、プロジェクト参照を削除して再度追加したところ、そのタイプがもう一度認識されました。

もちろん、これによりプロジェクト ファイルが更新されたので、どのような変更が行われたかを確認しました。参照を検出できなかったプロジェクトと検出できるようになったプロジェクトの唯一の違いは、GUID の英字が小文字から大文字に変更されたことです。例えば：

古い壊れたリファレンス:

新しい修正された参照:

これが起こっている理由と、参照を手動で削除して再追加することなく (そしてすべてのプロジェクト ファイル GUID を大文字に変換することなく) 修正する方法を探しています。

これらの「壊れた」参照はビルドを壊すものではなく、ビルド エラーではなく、IntelliSense エラーとしてのみエラー一覧に表示されることに注意してください。したがって、参照は実際には壊れているわけではなく、単に IntelliSense が壊れているだけです (これは間違いなく悪いことです?!)。

カスタムコード分析を作成できる可能性があるため、診断の識別子に関するガイドラインがあるかどうか疑問に思います。

DiagnosticDescriptorのドキュメントでは、一意である必要があるとのみ言及されていますが、たとえばプレフィックスの付け方など、他のガイドラインはありますか?

Visual Studio 2015 内でSonarLintおよびStyleCopアナライザーを使用しています。これらは開発中にうまく機能しますが、Jenkins ビルド中にこれらを実行できるかどうか疑問に思っていましたか?

私は SonarLint.Runner を見たので、これは可能だと思います。

私がやろうとしていること:Class1 assembly 内 にクラスがあるとしましょうOldAssembly。このアセンブリは、多数の不明なプロジェクトによって参照されています。このクラスを新しいアセンブリに移動しNewAssemblyます。最終的には名前と名前空間も変更されます。ここで、すべての使用法を調整する必要があります。これらのコード調整を自動化するツールを作成したいと考えています。

私がこれまでに行ったこと: 私は roslyn をいじりましたRenamer:

ただし、ソース クラスの名前も変更します。そのため、コードを調べてRenamer、ユースケースに合わせようとしましたが、内部で使用されているために失敗しました。

質問: クラスをあるアセンブリから別のアセンブリに移動した後、コードの調整を自動化するにはどうすればよいですか。

ご想像のとおり、私は roslyn について、特にコード アナライザーとして学んでいます。

構文の強調表示は完全に機能しています。ただし、次のコード アクションは、ノードを削除するときにサイレントに失敗します。

主題：

Roslyn の操作方法に関する「より大きな」全体像を見逃しているように感じます。そのため、ここでのヘルプは素晴らしいものですが、役立つリンクやリソースもいくつかあります。

このプロジェクトをここにアップロードしましたが、「最小限の」例ではありませんが、問題を簡単に再現できます。上記のコードはCodeFixProvider.cs.

ありがとう

私がやろうとしていること:

roslyn を使用してコード リファクタリングを作成しています。私の目標は、カルスを切り開くことです。だから私がやっていることは、基本的に私はすべてのプライベートスタッフを削除し、非プライベートスタッフの体をthrow new NotImplementedException().

私の問題は何ですか:

すべて正常に動作しますが、次のような多くのコードの重複が発生しました。

その理由は、プロパティを使用する必要があり、Membersを宣言する構文クラスに共通の基本型またはインターフェイスがないためMembersです。これらすべてに共通するプロパティに同じ問題がありますBodyが、共通のベースまたは共通のインターフェイスはありません。

質問: API 設計がこのようなものである理由はありますか? それとも、何か不足していますか? これらおよび他の多くの同様のケースで重複を回避する方法はありますか?

更新 roslyn リポジトリに問題を作成しました: #10455