EAP Warning: This post is based on ReSharper 6.1 Early Access Program and some things such as screenshots and minor details might vary from the time this has been written to the time of release.

This is a first in a series of posts about some of the new options available in terms of settings with ReSharper 6.1.

One of ReSharper’s pain points has always been settings, specially when it comes to managing them across projects and/or teams. With ReSharper 6.0 we started to make changes to build in support for a new way to manage settings, but unfortunately due to time constraints, we could not get it done in time for the 6.0 release. It has however made it into the 6.1.

Unified Settings Storage

An important change is that all settings have been unified into a single storage mechanism. This means that when you load or save settings, they apply to everything, from code style to templates, patterns and naming conventions. This should make it easier than before where different things were stored in different places.

Settings for every scenario

Everyone has their own style and methodology of working. Some like to name their properties in a certain way, others don’t like to be explicit about their privates. Some use underscores, others don’t. Some like the var suggestions. Others despise it. We are all different.

When it comes to working together, we have to make compromises and settle in a series of settings and ways in which to work. One day, hopefully, we won’t have this limitation and it will be transparent to us, but until then we need to find a way to not only cope with it but define it.

This scenario is very apparent when working on a team, but even as a solo developer, we can still require different settings based on different factors. We can be working on private projects that follow our own standards or be part of an open source team that follows the standards for the OSS project.

We hope with ReSharper’s new settings we can try and accommodate different scenarios. Let’s cover a few of the simpler ones.

Single developer and same settings for all solutions

If you are a solo developer or like to have the same settings across every single solution, then you won’t notice much difference in how you save your settings. You access the settings using the regular ReSharper | Options dialog and once done you press the Save button

These are also known as ReSharper Global Settings and are stored in

%AppData%JetBrainsReSharpervAnyGlobalSettingsStorage.DotSettings

making them easily accessible for backup and restore as well as persistence during upgrades.

Different private settings on different solutions

Sometimes we’d like to have different settings based on different solutions, even if we are not necessarily sharing these settings with a team. We’ve made this scenario quite simple too. Once again we open up the ReSharper | Options dialog and make the required changes. This time however, instead of clicking on the Save button, we click on Save To and select %SolutionName% Solution – Private where %SolutionName% varies based on the active solution

This will create a file called %SolutionName%.SLN.DotSettings.user in the solution folder (in our case ConsoleApplication2.SLN.DotSettings.user) which holds the settings for this particular project. It is important to note that this file should not be checked in to source control as each user would have their own specific settings and thus one would override the other. We recommend that this file be added to the list of files to ignore by the VCS (i.e. add to .gitignore).

Shared team settings

The next step is to have a series of settings shared across the team. As you can guess from the previous screenshot, this is merely just choosing the next option down when saving settings:

which will create a a %SolutionName%.SLN.DotSettings file in the solution folder. This file should be checked in to source control.

These cover some of the simple scenarios when it comes to settings. However, sometimes it is not that simple. Often we want to have the best of both worlds. For instance, we might like to have team settings and tweak them a little bit to our own use. That’s where ReSharper’s smart settings come in.

Combining Settings: Layers

Settings in ReSharper are like onions, they have layers, and these layers, combined with what we call internally “smart savings”, provide more flexibility when it comes to tweaking settings.

Say for instance we are using some shared settings from a team settings file checked in with the project, yet there are certain settings we’d like to change privately that only affects us. How would we do this?

Quite simple. We modify the settings we want tweaked and then save it as Solution Private. ReSharper realizes that there are different values for a setting and the layering kicks in which one layer override another one. The actual order of the layering is:

Private Settings currently override Solution Shared, which in turn override Global settings. As such, by tweaking the settings to our individual needs (only those required), we can override specific team settings.

[Note: Some have mentioned that this wouldn’t enforce team settings. True, it does not, and we believe in discipline versus constraint.]

Managing Options

You might have noticed that in the ReSharper menu, as well as the Options dialog there is a new entry / button labeled “Manage Options” and “Manage…” respectively. These provide access to managing the different settings layers easily as well as importing/exporting and resetting.

When clicking on them, we’re displayed the following dialog:

The dialog box lists all the different layers currently available. Out of the box, ReSharper ships with the three we’ve already discussed: Global, Private and Shared with Team. Each of these are appropriately placed in the correct Group, which also happens to be three. From this dialog box we can edit each of these as well as import and export settings.

To edit specific settings, we merely select the one we’re interested in and click on the Edit… button on the top-left corner. This opens up the regular Options dialog box for us, with a minor difference. It now displays the name of the layer we are editing:

This difference is also apparent in that the Save To Button is no longer present, as when clicking Save we will automatically save the layer we are editing. When we edit the settings, only those of that specific layer are updated. Everything else stays intact.

Summary

The new ReSharper settings is hopefully designed in a way which allows to not only ease the pain of sharing settings, but provide for a variety of options and maximum flexibility. In the next parts we’ll cover how to add additional layers (including storing settings on Dropbox for instance), re-order, as well as importing and exporting of old and new settings.

49 Responses to ReSharper Settings in 6.1

1. When you save the user file, does it automatically look at what’s in the global and group files, and only save what’s different? And if so, does it do the same for the group file? The group file really should have *all* the settings, not just the diffs from the global settings.

2. Does this finally fix the problem where the shared solution settings wouldn’t get saved until you closed the project? Will they save immediately now?

How do we apply the same settings shared across all projects across the whole team? To me that is the real scenario that needs to be supported. Typically a dev shop has got one coding standard that is applied across all development efforts. Do we need to create copies of these settings for all solutions? Hopefully not.

This is awesome! Just what I’ve been waiting for. This will make collaboration in FOSS projects so much easier while maintaining a separate R# profile at work. The only missing piece now seems to be tab settings. Why does tabs still need to be configured in Visual Studio?

I to would like to see support for sharing a single set of settings across a team and multiple projects. We have 100+ applications and 20 developers. It’d be nice if they were all on the same page regardless of what project they were working in.

This is awesome. I’m happy to see settings management integrated into the core tool. As a team that has been sharing settings for a while, I’m looking forward to this.

However I have a few questions:
1) Similar to the question by Carel Lotz. We currently also share settings at a level above our solutions so that they apply to all solutions. I assume that you can do this by adding an extra layer. But if so, does everyone have to manually add that layer in their local configuration, or is it automatically detected by virtue of having a “x.DotSettings” file in the folder hierarchy (like StyleCop does)?

2) As Joe White already mentioned, is there an easy way to override settings at the team-level rather than relying on defaults. If you rely on defaults and someone changes their defaults, then the assumption is invalid. It would be great to have a way of applying all settings at the shared team level (without having to walk through each setting and apply it).

3) Are settings refreshed automatically if the files on disc change (for example when new sources are pulled)?

4) Is anything being done as part of this effort to fix where “Namespace Provider” settings for directories are stored or how they integrate with source-control? They are currently being stored in a file called “{ProjectName}.csproj.ReSharper” with each project that constantly gets checked out (even when no changes have been made), and sometimes gets deleted arbitrarily. This generates a lot of noise to sort through when checking in. Changes on disc are also not reflected at runtime, but you have to unload the solution and re-load to have them apply.

2. Not sure I understand your question. If you save team settings (whatever you want) and check in the file, it will override the global settings. Nobody has to do anything in order for this to take effect. If an individual member of the team now wants to override the team settings, they’d need to change their setting and save as private solution.

3. Yes

4. All previous settings are now invalid, including where they were stored. The new settings (and files) take effect.

BUT: MAKE THIS PATH RELATIVE to the solution file!!! and don’t store there an absolute path containing the drive letter! [From the manage options dialog this file (MySolution.sln.DotSettings) can and should be added to version control.]

All directories below “.libs” are imported by either svn:externals or hg-subrepos.

For StyleCop each solution has this very simple “Settings.StyleCop”-file at “.”:

.libscorporateSettings.StyleCop
Linked

So I did the same with R#: I added a layer to “Solution — Shared With Team Group” and placed the file inside “.libscorporate”.

But now your R# file “.MySolution.sln.DotSettings” has a new entry “/Default/Environment/InjectedLayers/FileInjectedLayer” which contains the full path:
DRIVE:SomepathtomymercurialrootSolutionNamelibscorporateLayerFileName.DotSettings

But I should just have this relative path because this full path would not make sense at any different machine which gets .MySolution.sln.DotSettings” via source control:

However, I’m seconding Tim’s second question: when you choose to “Save to” team settings, only the settings changed from the global settings are saved. If someone in the team changes one of its global settings (not solution private, so placed at the bottom of the settings layers) that is not overridden by team settings (because the default setting value was fine for the team), it will then prevail.

Please provide an option to force saving all settings, even those that aren’t modified. Currently, to share an “override all” settings file with your team, you have to properly configure your global settings, export them, and import them back to the team settings. This works fine but isn’t very intuitive.

I spent some time configuring everything in my global settings and team settings, and I asked myself more than once, “where do this setting actually come from?”. It would be a very welcome addition to see, for each one of the setting, when it’s inherited, overridden, by which layer, etc.

People are never happy with what you give them 😉 Still, the settings system is way, way better than before, it just adds a little confusion.

The shared file should have everything by default — not just the diffs from the global options. The whole point of sharing the options is to make them the same everywhere, and if you base them on something that’s different everywhere, you’re sabotaging the whole thing from the start. There might be cases where someone wouldn’t want everything in the shared file, but that would be really unusual — and could probably be dealt with by adding a local options file. Don’t optimize for rare, weird, and easily-worked-around cases by making life harder for the other 95% of your users. The default should be for shared settings to contain everything.

No, I was just reading what you wrote — which, as far as I could tell, said that the shared settings file would only contain those settings that were different from the machine-wide settings. (And based on the other comments here, I’m not the only one who got that impression.)

I’m guessing from your answer that the file shouldn’t be there? In my case, I had 6.0 installed (and thus a .6.0.resharper file in that project) and it seems to me the contents of 6.0 and 6.1 are pretty much the same.

The same thing happens with 6.1.37.86 (the released version) – I open up a solution with a .6.0.resharper file and get a 6.1.resharper file (and the .user versions of them). So which files should I be adding to my VCS?

While editing the code – if I want to change the “Inspection Options” and “Naming Style Options” on the fly, I can select the layer where I would like to make the changes. (I would like to change in the ‘team shared’ layer). But, when I add an abbreviation to the list of abbreviations, it gets added to the ‘computer’ layer, and doesn’t give me an option to choose the layer.
Is this going to be fixed in a future release?

@Bhanu
This certainly makes sense. I have created a request based on what you’re suggesting.
I’m not ready right now to announce the deadline for this fix but this definitely should be done.
The problem here is that the quick-fix is applied silently, without any UI item where we could add the Save/Save To combo.

In looking at the new 6.1 settings support – I’d like to take advantage of layering, so that developers can have global settings and apply team settings over the top of them. However, it appears that the only way to do that is by having a shared solution. Is that correct?

At my company we don’t use shared *.sln files – there are too many DLL’s, and each developer creates their own set of .sln files with the DLL’s that they work on. Is there a way to use ReSharper’s settings layering in this type of environment?

Now, this is the big bang requirement:
I would like to share the settings across the teams, across the solutions and across the computers. Is there a way that it can be done? (I can export from one solution and import into another, but that’s a manual process that needs to be done everytime any setting changes in any of the solution)
Going by some of the posts submitted earlier, it looked like http://youtrack.jetbrains.net/issue/RSRP-47805 addressed this requirement – But, it doesn’t look like it did. I am using JetBrains ReSharper 6.1 C# Edition
Build 6.1.37.86 on 2011-12-20T15:45:24.

There seems to be a bug in integration with TFS (source control)
Let’s say my .DotSettings file in source control and checked-in. I make modifications to the ‘team-shared’ options (using quick-fix prompt, or by explicitly selecting these settings to be edited) & save the options (using ‘Save To’).
VS prompts me whether to checkout the file (this is my setting, to prompt instead of checking out files silently) and I say Yes.
The options are saved, and when I close all the dialog boxes, I can’t edit using the keyboard anymore!
If I close the VS and open it again, I can edit. I have also verified that changes to my options are saved in the appropriate layer.

Suppose the .DotSettigns file is already checked-out, then I don’t face this problem.

As the solution level settings are simply ignored by the individual developers settings in some cases, and in others the solution level settings override developer settings that have not been specified in the solution layer (such as code completion, intellisense and colour styling)!

The way things currently are, if you have a non-default setting in you private options,
there is no way to force it to the factory-default value via the group settings, since the group settings only save values that differ from the factory default.