Riderの.editorconfig設定｜DotSettingsとの優先順位・既存コードからの自動検出・CI強制

JetBrains RiderでC#のコーディングルールをチームに揃えるなら、規約の置き場所は.editorconfigに決めるのが近道です。Riderの設定画面で整えたコードスタイルは.DotSettingsという独自形式のファイルに入りますが、公式ヘルプは「EditorConfigで設定したコードスタイルとコードインスペクションは、すべての設定レイヤーを常に上書きする」と明記しています。本記事はRider 2026.2.4.1（ビルド262.11879.119、2026年11月3日リリース）の公式仕様をもとに、既存コードから規則を抜き出して.editorconfigを作るところから、重大度の書き方、保存時とコミット時の整形、CIでの違反検知までを導入の順に並べます。

まとめ：Riderで規約を.editorconfigに集約する6つの手順

1. 既存コードから規則を検出する。設定のEditor | Code Style | C#にあるAuto-Detect Code Style Rulesで、今のコードが実際に従っている書式を拾い、.editorconfigへ保存します。
2. VCSに入れるのは.editorconfigと<SolutionName>.sln.DotSettings。個人設定の.sln.DotSettings.userはコミットしません。
3. 重大度は記法で値の一覧が違う。Rider固有の検査はresharper_..._highlightingでerror | warning | suggestion | hint | none、コンパイラ警告はdotnet_diagnostic.<ID>.severityでnone | silent | suggestion | warning | errorです。
4. 検査の重大度が効かないときは「Read settings from editorconfig, project settings and rule sets」を確認する。整形は既定で読むのに、検査と命名スタイルはこのチェックが要ります。
5. 保存時とコミット時に整形を当てる。Actions on Saveは明示保存でしか動かないので、Commit ChecksのCleanup with…も併用します。
6. 最後の関門はCI。無償のReSharper Command Line Toolsでjb cleanupcodeとjb inspectcodeを回し、差分か検出が出たらジョブを落とします。

設定の保存先となる3つのレイヤーと.editorconfigの優先順位

Riderは設定を1か所に持たず、重なり合う複数のレイヤーに保存します。標準のレイヤーはThis computer、Solution team-shared、Solution personalの3つです。どのレイヤーに保存したかを意識しないまま設定を触ると、手元では規約どおりなのに他のメンバーの環境では違う整形になる、という食い違いが起きます。

3つのレイヤーが書き込むファイルと適用範囲

This computerの実ファイルは、Windowsが%APPDATA%\JetBrains\Rider2026.2\resharper-host\GlobalSettingsStorage.DotSettings、macOSが~/Library/Application Support/JetBrains/Rider2026.2/resharper-host/GlobalSettingsStorage.DotSettings、Linuxが~/.Rider2026.2/config/resharper-host/GlobalSettingsStorage.DotSettingsです。パスにバージョン番号が入っているため、2026.3へ上げると別ファイルになります。このレイヤーはチームへ配布されないので、全員に守らせたいルールをここに置いても効きません。

Solution team-sharedは、命名スタイルや整形ルールなどチームの設定を現在のソリューションに強制するためのレイヤーです。ファイルをVCSに入れてメンバーが取得すると、ソリューションを開き直さなくても適用されます。Solution personalは共有設定を変えずに自分だけ上書きするためのもので、公式ヘルプも「VCSに追加すべきではない」としています。

.editorconfigが全レイヤーより優先される根拠

公式のLayer-based settingsはCode style and code inspections settings configured in EditorConfig will always override settings from all settings layers.と書いており、EditorConfigはレイヤー構造の外側から全体を上書きします。Use EditorConfigにも、既定でEditorConfigプロパティがRider設定の指定を上書きすると書かれています。

二重管理する意味はありません。コードスタイルと検査の重大度は.editorconfigへ一本化し、.sln.DotSettingsにはコードクリーンアップのカスタムプロファイルのように、EditorConfigで表現できない項目だけを残します。.editorconfigはディレクトリ階層をさかのぼって適用されるので、サブプロジェクトだけ規約を変えたいときは該当ディレクトリに追加のファイルを置けば済みます。

VCSにコミットするファイルと除外するファイル

GitHubが公開しているgitignoreテンプレート集のVisualStudio向けファイルには、ReSharper関連として*.DotSettings.userが登録されています。Riderのソリューション個人設定もこのパターンに一致します。自前の.gitignoreを書く場合、先頭のワイルドカードを落とすとMyApp.sln.DotSettings.userに当たらないので注意してください。

# .gitignore
# チーム共有設定はコミットする（除外しない）
# MyApp.sln.DotSettings
# .editorconfig

# 個人設定だけ除外する
*.DotSettings.user

# ReSharper の作業ディレクトリ
_ReSharper*/

# .idea は共有したい設定も含むため、個人用ファイルだけを除外する
# （github/gitignore の Global/JetBrains.gitignore と同じ方針）
.idea/**/workspace.xml
.idea/**/tasks.xml
.idea/**/shelf

Riderの版が混在するチームで.DotSettingsの変更が読まれないケース

Riderの新しい版は、設定の保存形式を変えたときに.DotSettingsを初回起動時に自動で書き換えます。公式の説明では、新形式の設定を追記し、旧形式の項目は変更も削除もしないので、アップグレード済みのファイルを古い版のメンバーと共有してもかまいません。書き換え済みの印として、次のような項目がファイルに追加されます。

<s:Boolean x:Key="/Default/Environment/SettingsMigration/IsMigratorApplied/[migration_ID]/@EntryIndexedValue">True</s:Boolean>

落とし穴は逆方向にあります。新しい版に上げたあと古い版に戻って設定を変え、再び新しい版に戻ると、Riderは2回目のアップグレードをしません。公式は、このとき古い形式で保存された設定が新しい版に読まれない場合があると注意しています。2026.2系と2026.3系が混在する時期は、.sln.DotSettingsを触る人を新しい版の利用者に限るか、変更後に両方の版で読まれているかを確かめてください。.editorconfigに寄せた項目はこの影響を受けないので、混在期間を短く保てないチームほど.editorconfigへの集約が効きます。

.editorconfigを作る：既存コードからの自動検出と設定画面からの書き出し

ゼロから手で書く必要はありません。既にコードがあるリポジトリなら自動検出、設定画面でスタイルを整えてあるならエクスポートが入口になります。

既存コードの規則検出と.editorconfigへの保存

規約を後から入れるときに困るのは、決めたルールと今のコードがずれていて、最初の一括整形で巨大な差分が出ることです。RiderのCode Style: C#ページにあるAuto-Detect Code Style Rulesは、現在のソリューションで使われている整形と構文スタイルを分析し、今の設定と異なる規則を検出します。検出結果は確認・修正したうえで、設定レイヤーか、.editorconfigまたは.clang-format形式のファイルへ保存できます。

先に今のコードの実態を規則として書き出し、それを出発点にチームで変えたい項目だけを議論する順序にすると、規約導入のPRが「議論した変更」と「機械的な整形」に分かれてレビューしやすくなります。ソリューション全体でなく一部のコードだけを手本にしたいときは、エディターでコードを選択してAlt+EnterからReformat and cleanup | Detect code style settingsを実行します。公式は整形ルールの検出がC#とC++だけで動くとしています。命名規則も既定では既存コードから学習する設定になっており、手で決めたい場合はEditor | Code Style | C# | NamingのUse auto-detected rulesを外します。

設定画面から.editorconfigへの書き出し

RiderのUIで整えたスタイルがあるなら、そのままエクスポートできます。Ctrl+Alt+Sで設定を開き、Editor | Code StyleのEnable EditorConfig supportの横にあるExportをクリックします。既定ではソリューションのルートに新しい.editorconfigが作られ、既存ファイルがある場合はディレクトリ階層上で最も近いファイルが使われます。

ダイアログのShow additional optionsを開くと、既定値のままの設定も書き出すか、JetBrains固有のスタイルを含めるか、検査重大度を含めるかを選べます。既定では変更した設定のプロパティだけが保存されます。変更した設定だけの書き出しは差分を追いやすい反面、未出力の項目は各IDEの設定に依存します。全員で固定したい項目は、既定値と同じでも明示してください。書き込み前のプレビューでは、既存ファイルと値が衝突するプロパティが赤く示されます。

Riderが解釈する.editorconfigプロパティの3系統

Riderの設定ダイアログで変えられるコードスタイル設定には、それぞれ対応するEditorConfigプロパティがあります。書けるプロパティは3系統に分かれ、どの系統かで他のエディタに効くかどうかが決まります。

標準プロパティ・.NET規約プロパティ・JetBrains固有プロパティの使い分け

1つ目はEditorConfig標準プロパティです。標準といっても対応状況は一律ではなく、EditorConfig公式のプロパティ一覧はindent_styleやindent_sizeを「Widely Supported by Editors」、max_line_lengthを「Supported By A Limited Number of Editors」と分けています。2つ目はcsharp_style_var_for_built_in_typesのような.NETコーディング規約プロパティ。3つ目がresharper_で始まるJetBrains固有プロパティで、Rider独自の整形・構文スタイル・検査重大度はここで指定します。以下は公式ヘルプの掲載例をもとに、3系統が並ぶようにした設定例です。

root = true

[*]
# 標準プロパティ
indent_size=2
max_line_length=100

# .NET コーディング規約プロパティ
csharp_space_between_parentheses=expressions, type_casts, control_flow_statements
csharp_style_var_for_built_in_types=true

# コンパイラ警告の重大度
dotnet_diagnostic.CS8618.severity = none

# JetBrains 固有：整形スタイル
resharper_csharp_brace_style=next_line
resharper_csharp_blank_lines_around_invocable=2

# JetBrains 固有：構文スタイル
csharp_default_private_modifier=explicit
braces_for_ifelse=not_required

# JetBrains 固有：検査の重大度
resharper_possible_null_reference_exception_highlighting=error
resharper_replace_with_string_is_null_or_empty_highlighting=none

取り違えやすいのはdotnet_diagnostic.*の守備範囲です。公式ヘルプはこの記法の値をnone | silent | suggestion | warning | errorとし、適用先を「C# 8.0以降のコンパイラ警告と、コンパイラ自身が出すものを含むRoslyn解析規則」に限っています。Rider独自の検査（上の例のpossible_null_reference_exceptionなど）はこれに当たらないため、resharper_..._highlightingで書きます。値の一覧も一致しておらず、dotnet_diagnostic側にはsilentがあってhintが無く、resharper_..._highlighting側はその逆です。片方の感覚で値を書き写さず、該当ページの一覧を見て決めてください。

Visual Studioとの違いが1つあります。Riderはプロジェクトファイルから参照されている.globalconfigに書かれたEditorConfig標準プロパティも解釈し、公式ヘルプはこれを(unlike Visual Studio)と対比しています。参照されていない.globalconfigは対象外です。命名規則のdotnet_naming_rule.*系は、指定したシンボルの種別がRiderの命名設定で扱える種別と一致する場合にだけ機能します。

検査の重大度を.editorconfigで調整する手順と、効かないときの確認箇所

IDEが出す警告が多すぎれば誰も読まなくなります。落としたい違反だけをエラーに引き上げ、それ以外を下げる運用にしてください。

重大度の5値と書き換えの実例

公式のConfigure warningsは構文を[inspection_property]=[error | warning | suggestion | hint | none]と示しています。Possible 'System.NullReferenceException'検査をエラーに上げるならresharper_possible_null_reference_exception_highlighting=error、Redundant argument with default value検査を無効にするならresharper_redundant_argument_default_value_highlighting=noneです。同じページは、.editorconfigの検査設定が設定画面のInspection Severityページより優先されるとも書いています。

重大度が反映されないときに開く設定

.editorconfigに重大度を書いたのに表示が変わらないときは、Rider側の受け入れ設定を確認してください。公式ヘルプはTo configure code inspections and naming styles from EditorConfig, you have to select the Read settings from editorconfig, project settings and rule sets checkbox on the Editor | Inspection Settings page of JetBrains Rider settings.と条件を書いています。整形スタイルは既定で読まれるのに、検査と命名スタイルだけこのチェックボックスを要求する非対称があります。

有効になっていれば、Riderは適用状況を画面上で示します。コードスタイル設定ページの項目がEditorConfigで上書きされていると黄色の警告が出て、上書きされた項目も黄色でハイライトされます。現在のファイルにどの.editorconfigが効いているかは、Help | Find ActionからShow Code Style Configurationを開いて確かめます。

generated_codeによる生成コードの検査対象の限定

生成コードは手作業で修正せず、通常のソースと検査対象を分けます。Riderは生成コードとして指定された範囲では、コンパイラのエラーと警告を調べる検査だけを実行します。*.designer.csのような典型的なマスクは既定で登録済みで、独自の生成物は.editorconfigからも指定できます。

[*generated.cs]
generated_code = true

検査体系そのものをどう設計するかは、IDEの機能に限らない話です。ツール選定の観点は静的解析とは？検出できる欠陥と静的解析ツールの選び方｜Coverity・cppcheckを比較で整理しています。

保存時とコミット時にコードクリーンアップを当てる設定

ルールを書いても、適用が手動なら守られません。Riderには保存時とコミット時の2か所にクリーンアップを差し込む設定があり、役割が違います。

Actions on Saveによる保存時の自動整形

Ctrl+Alt+Sで設定を開き、Tools | Actions on SaveのReformat and Cleanup Codeをオンにします。ここで適用するクリーンアッププロファイルと、ファイル全体か変更行だけかを選べます。変更行だけに絞れば、古いファイルを開いて保存しただけで巨大な差分が出る事故を避けられます。

トリガーは明示的な保存に限られます。公式のCode cleanupはNote that this will only happen when you save changes explicitly with Ctrl+S or Ctrl+S and will not be triggered by auto-saving.と書き、自動保存されたファイルは整形キューに入り、次の明示保存でまとめて処理されると説明しています。Ctrl+Sを押す習慣のない人の変更は、整形されないままコミットまで進むことがあります。

Commit Checksによるコミット前のクリーンアップ

保存時の整形をすり抜けた変更は、コミットの時点で止めます。Ctrl+KかGit | CommitでCommitツールウィンドウを開き、Show Commit OptionsのCommit ChecksでCleanup with…にチェックを入れます。コミット画面のリファレンスはこの項目を「コミットまたはシェルブするファイルにFull Cleanupプロファイルを実行する」と説明しているので、保存時やCIと揃えるならChoose profileで同じプロファイルを指定します。この状態でCommitかCommit and Pushを押すと、Riderはステージ済みのファイルにクリーンアップを当ててからコミットします。

対象はコミットするファイルですが、そのファイル内の未変更箇所にもクリーンアップが及び得るため、実行後の差分を確認してください。この設定はRiderのUIからコミットしたときだけ効きます。ターミナルのgit commitや他のGUIクライアントは通らないので、全員に効く関門はCIに置きます。

特定ファイルの整形除外とプロファイル差し替え

生成物やベンダー提供のソースなど、整形してはいけないファイルは必ず出てきます。C#ではdisable_formatter=trueを付けたEditorConfigマスクでRiderのフォーマッタを止められます。ファイルの集合ごとにクリーンアッププロファイルを差し替えるresharper_substitution_for_cleanup_profileプロパティもあります。

[Generated/**.cs]
# このディレクトリ配下はフォーマッタを動かさない
disable_formatter=true

[reformatIfRunWithFullCleanup.cs]
# フルクリーンアップ指定時も整形のみに差し替える
resharper_substitution_for_cleanup_profile.anysuffix=Built-in:Full Cleanup => Built-in: Reformat Code

組み込みプロファイルは3種類です。Built-in: Full Cleanupはファイルヘッダーの更新を除く全タスク、Built-in: Reformat Codeは整形のみ、Built-in: Reformat & Apply Syntax Styleは整形と構文スタイルの適用です。保存時・コミット時・CIで別のプロファイルを使うと結果がずれるので、1つに決めて.sln.DotSettingsで共有し、コマンド側でも--profileで同じ名前を明示してください。

CIでの規約強制：jb cleanupcodeとjb inspectcode

IDEの設定だけに頼ると、Riderを使っていないメンバーやAIエージェントが書いたコードが規約をすり抜けます。JetBrainsはIDEなしで同じ整形と検査を実行できるコマンドラインツールを配布しており、公式ヘルプはReSharper Command Line Tools is a set of free cross-platform standalone toolsと説明しています。NuGetのJetBrains.ReSharper.GlobalToolsの安定版はRiderと同じ2026.2.4.1（2026年11月3日更新）で、パッケージの対象フレームワークは.NET 8.0です。

dotnet tool install -g JetBrains.ReSharper.GlobalTools

# Windows ARM64 ではアーキテクチャの明示が要る
dotnet tool install -g JetBrains.ReSharper.GlobalTools --arch arm64

# 整形と検査（パッケージ共通のコマンドは jb）
jb cleanupcode MyApp.sln --profile="Built-in: Reformat Code"
jb inspectcode MyApp.sln -o=inspect.sarif -e=WARNING

規約を揃えるのが目的なので、ツールの版も固定します。-gでのグローバル導入は実行環境ごとに入る版が変わり、同じコミットでも整形結果が変わり得ます。リポジトリでdotnet new tool-manifestとdotnet tool install JetBrains.ReSharper.GlobalTools --version 2026.2.4.1を実行し、生成されたマニフェストをコミットしておけば、CIはdotnet tool restoreで同じ版を取得します。マニフェストの置き場所はSDKで違い、.NET SDK 10.0.401で実行するとカレントディレクトリ直下にdotnet-tools.jsonが作られ、.configフォルダは作られませんでした。同じSDKのdotnet new slnはソリューションを.slnx形式で作りますが、jb cleanupcode MyApp.slnx・jb inspectcode MyApp.slnxはどちらもそのまま受け付けました。

git diffによるCleanupCodeの変更検知

CleanupCodeはコードを書き換えるツールなので、CIでは「書き換えが発生したら規約違反」と扱います。公式のCleanupCode Command-Line ToolもIf your project is under Git VCS, use git diff after running CleanupCode to reveal any changes that were made by the tool.とこの使い方を案内しています。git diff --exit-codeを続ければ、差分が出た時点でジョブが失敗します。整形の崩れたFoo.csを1つ置いたコンソールアプリで下のワークフローの手順を順に流すと、cleanupcodeの書き換えでgit diff --exit-codeが1を返し、inspectcodeのSARIFにはCSharpWarnings::CS8600（null許容でない型へのnull代入）の警告が1件入って、件数判定のtestも1を返しました。

CleanupCodeは.DotSettingsから整形ルール・構文スタイル・C#のファイルと型のレイアウトを読み、--settingsで共有設定ファイルのパスを明示することもできます。そのうえでEditorConfigのコードスタイルプロパティが同じ項目を上書きします。ローカルと同じ結果を得るには、.editorconfigと.sln.DotSettingsの両方がチェックアウトされている必要があります。

InspectCodeの出力形式と最低重大度

InspectCodeは2024.1から既定の出力形式がSARIFです。XMLは-f="xml"で取得でき、既定のまま-o=inspect.xmlと書いてもXMLは出ません。形式を決めるのは拡張子ではなく--formatです。

既定ではSuggestion以上の重大度が報告されます。--severity（短縮形-e）にINFO, HINT, SUGGESTION, WARNING, ERRORのいずれかを渡すと下限を変えられるので、CIでは-e=WARNING程度に絞ります。この指定は報告対象を絞るだけで、合否は決めません。CIで落とすには、出力したSARIFの検出件数を読んで終了コードを立てます。解析前のビルド有無は--buildと--no-buildで明示でき、公式は既定動作か--buildを推奨しています。

# .github/workflows/code-style.yml
name: code-style
on: [pull_request]
jobs:
  style:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '10.x'
      - run: dotnet tool restore
      - name: format check
        run: |
          dotnet tool run jb -- cleanupcode MyApp.sln --profile="Built-in: Reformat Code"
          git diff --exit-code
      - name: inspection
        run: |
          dotnet tool run jb -- inspectcode MyApp.sln -o=inspect.sarif -e=WARNING
          test "$(jq '[.runs[].results[]] | length' inspect.sarif)" -eq 0

AIエージェントの変更に対する品質チェックフック

エージェントにコードを書かせる運用では、PRより手前で規約を当てられるほうが手戻りが小さくなります。Rider 2026.2はこの用途にコード品質チェックフックを追加しました。有効にするのは設定のTools | AI Agent Hooksで、2026.2 EAP 5の告知によれば、RiderがClaude Code側に必要なフックの設定項目を自動で書き込みます。JetBrainsの2026.2リリース記事はCode quality check hooks for Claude Code validate every change an agent makes before it can continue, blocking on errors and returning warnings as feedback.と説明しています。エージェントの変更をRiderのインスペクションで検査し、エラーなら続行を止め、警告はフィードバックとして返す仕組みです。続く2026.2.1ではRider's quality-check hooks now support Codex in addition to Claude Code.とあり、Codexにも対応しました。

このフックが判定に使うのも、ここまでで整えた.editorconfigと.sln.DotSettingsです。規約が個人のThis computerレイヤーに残っていると、そのIDEで動くフックと共有設定だけを読むCIとで判定が食い違います。JetBrains製IDEのAI機能の料金と使い方はJetBrains AI Assistantとは？料金・AIクレジット・使い方とGitHub Copilotとの違いで扱っています。

規約をCIに載せる考え方は他言語でも同じです。TypeScript側はBiome v2とは？最新2.6の導入・biome.json設定とESLint/Prettier移行、インフラコード側はTerraformコーディング規約とterraform fmtの使い方｜公式スタイルガイド準拠の命名・コメント・CI強制が参考になります。

Visual Studio・外部フォーマッタと併用するときの住み分け

チーム全員がRiderを使うとは限りません。混在環境では、どのツールが何を担当するかを先に決めます。

Visual Studio単体の環境が混じる場合、resharper_プレフィックスのプロパティは読まれません。全員に守らせたい項目は標準プロパティと.NETコーディング規約プロパティの範囲に収め、Rider固有プロパティはRiderユーザー向けの追加分と割り切ってください。Visual Studio 2026側の変更点はVisual Studio 2026の新機能｜VS2022との違い・サポート期限とVS2027への更新【2026年10月】、Visual StudioにReSharperを入れる場合の費用と機能はReSharperとは？使い方・料金・日本語化とVS Code版まで解説【2026.2】にまとめています。

整形をCSharpierに任せる構成も選べます。CSharpierのリポジトリにあるRiderプラグインは、dotnetツールのCSharpierを呼び出して整形する仕組みで、本体とは別に版が振られています。JetBrains Marketplaceのcsharpierプラグイン（ID 18243）は、2026年9月25日公開の10.0.7が最新で、対応ビルドは251.0から262.*まで、つまりRider 2025.1〜2026.2系です。いずれも2026年11月6日にMarketplaceのAPIで確認した値なので、2026.3（ビルド263）へ上げる前にプラグイン側の対応を確かめてください。この構成ではRider側の整形をdisable_formatter=trueで止め、検査だけRiderに担当させます。整形ルールを2つのツールに持たせたままにすると、保存のたびに整形結果を打ち消し合います。

Riderの日本語化と、無償で使える範囲

規約の設定そのものではありませんが、Riderを配る前に確認しておく2点です。どちらも2024年に仕様が変わっており、古い手順の情報が残っています。

Rider 2024.2以降の言語パック同梱とUI言語の切り替え

「Riderの日本語化にはMarketplaceから言語パックを入れる」という手順は、現行版では不要です。公式のLanguage and regionはJetBrains Rider is available in English but also includes bundled plugins that support Chinese, Korean, and Japanese.と記載しています。切り替えはAppearance & Behavior | System Settings | Language and Regionで行い、OSの言語とRiderの言語が違う場合は揃えるかどうかの提案も表示されます。同じJetBrains系IDEの日本語化はIntelliJ IDEAでJava開発を始める手順｜インストール・JDK設定・日本語化【2026.2対応】でも扱っています。

非商用無料ライセンスで使える範囲

Riderは2024年10月24日のJetBrainsの発表で非商用利用が無償になりました。発表は対象をlearning, open-source project development, content creation, or hobby developmentと列挙し、For commercial projects, nothing will changeとして商用は従来どおり有償だと述べています。社内の業務コードに使う場合は有償ライセンスが要ります。JetBrains製品のライセンスの整理はRubyMineとは？最新版2026.2.4・料金と無料の条件・初期設定【2026年11月】が詳しいです。

CIで使うReSharper Command Line Toolsは前述のとおり無償です。有償ライセンスを全員分そろえる前でも、規約チェックだけはCIに載せられます。

よくある質問

.editorconfigはどこに置けばいいですか？

ソリューションのルートディレクトリに置き、先頭にroot = trueを書くのが基本です。Riderは現在のファイルのディレクトリから親をさかのぼって.editorconfigを探し、ルートディレクトリに到達するかroot=trueのファイルを見つけるまで適用を重ねます。サブプロジェクトだけルールを変えたい場合は、そのディレクトリにroot指定なしのファイルを追加して差分だけ書きます。

.DotSettingsと.editorconfigはどちらを使うべきですか？

コードスタイルと検査の重大度は.editorconfigに寄せてください。両方に書くと.DotSettings側は必ず上書きされます。.sln.DotSettingsには、コードクリーンアップのカスタムプロファイル定義など、EditorConfigで表現できない設定だけを残します。

既存プロジェクトに規約を入れると差分が大量に出ませんか？

先にAuto-Detect Code Style Rulesで今のコードの書式を規則として保存すれば、規約を入れた直後の差分を小さく抑えられます。変えたい項目は別のPRで1つずつ変え、Actions on Saveは「変更行だけ」に設定すると、触ったファイルの全体が書き換わることもありません。

CSharpierとRiderのフォーマッタは併用できますか？

併用はできますが、整形の担当は片方に寄せます。csharpierプラグイン（Marketplace ID 18243）でCSharpierに整形を任せる場合は、対象ファイルのマスクにdisable_formatter=trueを指定してRider側の整形を止めます。両方を有効にしたままActions on Saveを使うと、保存のたびに互いの整形結果を上書きし合います。

Visual Studioと比べて規約運用で何が違いますか？

Riderはresharper_プレフィックスのJetBrains固有プロパティを解釈し、プロジェクトファイルから参照された.globalconfigの標準プロパティも読みます。混在環境では標準プロパティと.NETコーディング規約プロパティを共通の土台にし、固有プロパティは追加分として扱ってください。

関連記事

• ReSharperとは？使い方・料金・日本語化とVS Code版まで解説【2026.2】
• 静的解析とは？検出できる欠陥と静的解析ツールの選び方｜Coverity・cppcheckを比較
• Visual Studio 2026の新機能｜VS2022との違い・サポート期限とVS2027への更新【2026年10月】
• Terraformコーディング規約とterraform fmtの使い方｜公式スタイルガイド準拠の命名・コメント・CI強制
• JetBrains AI Assistantとは？料金・AIクレジット・使い方とGitHub Copilotとの違い