How ReSharper Settings Layers Are Applied — and Why the Order Surprises People

ReSharper settings don’t come from one file — they’re assembled from a stack of layers: global machine settings, team-shared settings under version control, personal per-developer overrides, and optionally custom injected layers on top of that. Most of the time this just works quietly in the background. The one place it tends to surprise people is precedence — specifically, which layer wins when two of them disagree.

Where layer files live

Adding a custom layer

Adding a new settings layer file creates reference entries in the “parent” settings layer file. For example, adding a new teamshared2 settings file creates “InjectedLayers” entries that look roughly like this:

<s:String x:Key="/Default/Environment/InjectedLayers/FileInjectedLayer/=SomeGeneratedKey/AbsolutePath/@EntryValue">C:\MySolution\Source\teamshared2.DotSettings</s:String>
<s:String x:Key="/Default/Environment/InjectedLayers/FileInjectedLayer/=SomeGeneratedKey/RelativePath/@EntryValue">..\teamshared2.DotSettings</s:String>
<s:Boolean x:Key="/Default/Environment/InjectedLayers/FileInjectedLayer/=SomeGeneratedKey/@KeyIndexDefined">True</s:Boolean>
<s:Boolean x:Key="/Default/Environment/InjectedLayers/InjectedLayerCustomization/=FileSomeGeneratedKey/@KeyIndexDefined">True</s:Boolean>
<s:Double x:Key="/Default/Environment/InjectedLayers/InjectedLayerCustomization/=FileSomeGeneratedKey/RelativePriority/@EntryValue">1</s:Double>

How precedence actually works

ReSharper’s settings layers follow a bottom-to-top precedence hierarchy: lower layers have lower precedence and get overridden by higher layers when there’s a conflict; higher layers win outright when settings differ.

The default order, from lowest to highest precedence:

1. ReSharper Default Settings — the built-in baseline, lowest precedence of all.
2. Global Settings (This Computer) — machine-wide settings applying to every solution on the machine.
3. Solution Team-Shared Settings — stored in version control (e.g. SolutionName.sln.DotSettings), shared across the whole team, overriding global settings.
4. Solution Personal Settings — individual, unshared, stored in a user-specific file (e.g. SolutionName.sln.DotSettings.user), overriding team-shared and global.
5. Custom Settings Layers (optional) — applied in the order they appear, with a layer placed higher in the hierarchy overriding those below it.

When ReSharper resolves a setting, it starts at the bottom and works up: each subsequent layer can override or augment what came before, and the topmost layer wins any conflict.

The precedence trap

Here’s the part that catches people off guard. Suppose the team-shared layer “Product.Frontend” sets the file header text to “A”, and an injected additional layer teamshared2 sets it to “B”. In a new class, “A” wins — not “B”.

That’s the opposite of what a lot of people intuitively expect from an “injected” layer — the natural assumption is that something injected on top should override what’s underneath. Instead, injected layers sit below the default team-shared layer in precedence, which means the default team-shared settings can’t be flexibly toggled on and off via an injected layer the way you might want. If injected layers instead overruled the default team-shared layer, you’d get a genuinely useful pattern: keep baseline settings in the default layer and selectively override them via an injected one. That’s not how it resolves.

A second example, this time with Code Cleanup profiles configured differently across layers:

• Global (This Computer): Profile A
• Team-Shared (Solution <name> team-shared): Profile B
• Personal (Solution <name> personal): Profile C

Running Code Cleanup uses Profile C — Personal — because it’s the highest-precedence layer in play. No surprise there; it’s the injected-layer case above that actually trips people up.

This precedence quirk also interacts with profile naming — reusing a profile name across layers hides the lower layer’s version of that profile entirely. See the comparison of ReSharper’s built-in cleanup profiles for a concrete example of that collision.

Managing layers without the surprises

Team settings. Use team-shared settings to enforce consistency for style rules, inspections, and code cleanup — and keep them version-controlled.

Personal preferences. Use personal settings for individual customizations that shouldn’t affect the rest of the team.

Global settings. Reserve global settings for preferences that genuinely apply across every solution — UI themes, keyboard shortcuts, and the like.

Custom layers. Add them for specific purposes — experimental configurations, or settings scoped to a subset of projects — but remember where they actually sit in the precedence order before relying on them to override a default.

Layer order. The Settings Layers dialog lets you reorder or remove layers directly, which is the place to check if a setting isn’t resolving the way you expect.

The takeaway

The precedence model itself is simple — bottom to top, highest layer wins. Where it gets people is the assumption that “injected” implies “overriding.” It doesn’t. Knowing the actual default order in advance is the difference between a five-minute settings change and an hour spent wondering why an injected layer isn’t taking effect.