3

多数の大規模なソリューションがあり、さまざまなプロジェクト タイプに基づいた多数のルールセット ファイルがあります。たとえば、次のようなものがあります。

  • 以下を含む Sharepoint ルールセット:

    • マイクロソフトのすべての規則
    • MSOCAF 規則
    • SPDisposeChecker ルール
    • 多数のカスタム ルール

  • テスト プロジェクトのルールセット

    • マイクロソフトのすべての規則
    • いくつかの命名ガイドラインのルールを無効にしました (たとえば、アンダースコアの使用)
    • TypeMock TestLint に似た多くのテスト固有のルール
    • 多数のカスタム ルール

  • 標準ルールセット

    • マイクロソフトのすべての規則
    • 多数のカスタム ルール

コード分​​析がプロジェクトの種類に基づいて適切なセットを自動的に選択できるようになれば幸いです。

これを行う理想的な方法が見つかりませんでした。私が検討すること：

  • 特定のビルド ターゲット (yuk) の存在に基づいてプロジェクト タイプを派生させるビルド サーバーの msbuild フォルダーにターゲット ファイルをドロップします。
  • 各プロジェクト タイプ (yuk) の各ターゲット ファイルに CodeAnalayis ルール ファイルを指定します。
  • カスタム ターゲット ファイルを作成し、それをすべてのプロジェクトに含め、各プロジェクトでプロパティを設定して正しいプロジェクト タイプを選択します。(ユク)
  • ルール自体を変更して、それらが正しいコンテキストにあるかどうかを確認します (カスタム ルールでは可能ですが、デフォルト ルールでは実行できません)。

現在行っていること:

  • プロジェクトごとにルールセットを手動で指定します。

より良い解決策のアイデアを聞きたいです...

4

2 に答える 2

1

さらに別のアプローチは、コード分析ターゲットファイルまたはビルドタスクのいずれかを、推論を可能にするバージョンに置き換えることです。個人的には、インターセプトポイントが私の好みには少し隠されているので、私はこれのファンではありませんが、ymmv ...

これが単一のチームによって長期にわたって維持される製品の場合、私はおそらくあなたの3番目のオプションに沿ったものを選ぶでしょう。一方、これが最終的にコードベースが別のチーム（内部または外部）に転送されるプロジェクトの場合は、VisualStudioUIを介して実行できるものを選択します。残念ながら、それはプロジェクト固有のルールセットの選択を意味します。唯一の良いニュースは、特定のソリューションのすべてのプロジェクトでこれを管理できるUIがあることです（[分析...ソリューションのコード分析の構成]メニューからアクセスできます）。

于 2012-04-17T18:02:26.247 に答える
1

ほとんどのプロジェクト タイプで機能するソリューションを見つけました。Microsoft が提供する既定の Msbuild ターゲットの多くには、問題のターゲットを Msbuild フォルダー構造の特定のフォルダーに配置することで、BeforeTargets と Aftertargets を読み込むオプションが含まれています。

ターゲット ファイルをこれらのフォルダー (プロジェクトの種類が期待する方法に基づく命名。プロジェクトの種類によって異なる傾向があります) に配置し、そこで既定の CodeAnalaysis.rules ファイルを指定します。プロジェクトはこれらをオーバーライドできますが、そうでない場合はデフォルトが使用されます。

たとえば、Sharepoint は次のファイルを探します。

$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\SharePointTools\Custom.After.Microsoft.VisualStudio.SharePoint.targets

これらの参照は、$(CustomAfterSharePointTargets)必要に応じて拡張またはオーバーライドできる msbuild プロパティに格納されます。

私のソリューションは、この機能とこの機能に基づいて構築されています。

これを Visual Studio 11 でさらに標準化するようリクエストしました。投票してください。

于 2012-04-22T15:08:59.717 に答える