Save or Save To in ReSharper Options

Since ReSharper introduced the layered structure for saving its options, we all face the choice of clicking Save or Save To whenever we change any settings. The good news is that the Save button will do the job for most users in most situations. The bad news is that, being tempted to go advanced and use the Save To button, you may not get what you expected without proper understanding of its design and purpose.

This post will hopefully help you click Save more confidently and opt for the Save To items only when you really need it.

Regardless of how you save ReSharper settings, you should always bear in mind that all settings you modify during one transaction (that is, between opening the Options dialog and clicking Save or Save To) can only be saved together. If you need these modifications to be saved in different layers, you have to repeat the transaction for each group of settings.

A rule of thumb when choosing between Save and Save To is the following:

  • If you want to apply your modification but keep team-shared and/or custom layers (if any) intact, click Save.
  • When you want to save modified settings to the Solution team-shared layer or a custom layer, click Save To and select the target layer.

If you want to know exactly how it works and why, please read on.

Default Settings

When you start with a fresh and clean installation of ReSharper, you can go to ReSharper > Manage Options and see that the following settings layers are prepared for you:

There are three predefined layers in order they apply (from bottom to top):

  • This computer
  • Solution team-shared
  • Solution personal

You can even see the file names and locations of these layers. But do they really exist? If you haven’t made any changes to ReSharper options, the answer is NO: just look for settings files in your solution folder or your local application data folder, none of them are there. What you are seeing right now in the Settings Layers dialog are rather predefined destinations for settings layers that will be created as soon as you change any settings.

However, default settings must be defined somewhere…  and they are in fact defined in ReSharper system files; moreover, they are never changed. The trick here is that instead of changing default values of settings, ReSharper overrides them in different settings layers and then applies the value of the uppermost layer in the layer stack for each setting. Default settings are not shown in the Settings Layers dialog, and that’s why you may think that default settings are stored in This computer layer.

Let’s visualize the default state of ReSharper options. Imagine that ReSharper has only three settings (I wish it did) that define different colors. The default value is ‘blue’ for all three settings and the ‘Resulting settings’ are what we see in the ReSharper’s Options dialog:

As long as any settings layers are empty or do not exist, they are transparent for ReSharper and it applies values from the default settings.

Why Three?

At this point you may ask, why are there three predefined settings layers, no less and no more?  Well, they are there for your convenience. Here are some scenarios in which you may need these layers:

  • Need to have your settings applied globally in your computer – they will be saved it in This computer layer
  • Work on a team-shared solution and need to use the same code styles, templates, SSR patterns, etc. within this solution – then save these settings in the Solution team-shared layer; according to the concept, setting values defined in this layer will override not only the default settings, but also your personal global settings defined in This computer layer.
  • Need to have some settings applied only in a particular solution independent of your team – then save them in the Solution personal layer; this layer will override all other settings, including those defined in the Solution team-shared layer.
  • Want to have a set of settings for some solutions, another set for others, etc. – this is a less common case and it is not covered by the predefined setting layers; however it is possible with custom layers: see Per Project Settings or How to have different naming styles for my test project
  • Want to have the same settings for all solutions within your team – this is also possible with custom layers: see ReSharper 6.1 Settings: DropBox and Company-wide

The chart below explains the use of all three layers. Suppose that you changed all default settings globally and had ‘green’ instead of ‘blue’ values. Then, after a discussion with your team, you decided that you would have settings A and C ‘yellow’ within your team-shared solution. Finally, you realized that you felt more comfortable with the ‘green’ value for setting A, and you changed it in the Solution personal layer, so as to have the desired value applied without changing the team-shared layer:

As you can see, all this is possible using the three predefined setting layers.

How Does Save Work?

The Save button is called ‘smart save’ within the ReSharper development team, and for a good reason. Not only does it decide where to save the value of a modified setting, but it also compares the new value with the default value and those in other layers. Here are some common scenarios of how the Save button works:

First, let’s see what happens if the setting is not defined in any layers. Here everything is pretty simple: If the new value differs from the default value – the value is saved in This computer layer; if the value matches the default, it is cleared from This computer layer.

The setting that you change  may be already defined in the Solution team-shared layer and/or in custom layers. If this is the case, the  new value is saved in This computer layer (to be applied in other solutions) and in the Solution personal layer ( which always overrides all other layers for the current solution). If the new value is the same as the resulting value on the top of the  stack of layers, it is simply cleared from the Solution personal layer.

What About Save To?

Unlike Save, the Save To button is pretty straightforward: it saves all changes in the current transaction to the selected setting layer. Let’s see why, and when you need to use this button.

There are several approaches to have ReSharper settings saved in the Solution team-shared or any custom layers, including copying settings from other layers and import of settings. But the simplest way is to change the desired settings in the ReSharper’s Options dialog, and then use the Save To button to save the modifications to the particular layer.

The only catch with Save To is that after saving a setting to a particular layer, it may NOT be applied if the same setting is defined with another value in other layers above in the stack of layers. The illustration below shows how we tried to change setting C to ‘red’ by using Save To and why the resulting setting failed to be changed.


This article touches upon the basics of ReSharper’s layered concept of saving settings. Custom layers, which were not discussed here, follow this concept and bring ultimate flexibility to the way you can store and share ReSharper settings. If you want to learn more, please follow the ReSharper settings tag here at JetBrains .NET Tools Blog.

This entry was posted in How-To's and tagged , . Bookmark the permalink.

6 Responses to Save or Save To in ReSharper Options

  1. Igal Tabachnik says:

    It’s important to note, however, that the default ReSharper values will NOT be exported, only the values you have changed. For example, in C# naming conventions, ReSharper uses ‘_lowerCamelCase’ for fields. If you export the settings, the field naming will NOT be exported.

  2. Joe White says:

    So “Save” is really “Save Local and Ignore the Team”, which means it’s exactly the wrong option most of the time. Good to have that clarified.

    If the option was already defined in the team-shared file, and I was actually trying to change the shared setting (since, y’know, I work on a team), then it sounds like “Save” would permanently override the team-shared setting on my computer. I could go back in and save it correctly, as a team-shared setting, but my computer wouldn’t pick up any future changes to the team-shared setting since it already had a solution-personal setting.

    Would there be any way to clear the solution-personal setting so that ReSharper would correctly respect the team-shared settings again?

    There’s really very little reason to *ever* use solution-personal if you work on a team, and I regard it as a big design flaw that it’s so easy to accidentally save settings to solution-personal and then have to figure out how to clean up the mess.

  3. Dmitry Matveev says:

    Thank you for your feedback, Joe. You are digging deep enough. It is true that currently we lack the possibility of clearing a particular setting value in a particular layer. We are working on UI implementation of this, and your comment may help reviewing the priority of the task.
    However, I don’t quite agree on your point that ‘Save’ is ‘the wrong option most of the time’. There are a lot of scenarios where one would like to override a team-shared option, especially taking into account that some options have complex, non-mutual exclusive values.
    Take ‘Code Inspection > Custom Patterns’ for example. If some patterns are defined in the team-shared layer and you want to add one for your personal use, you can go ahead using ‘Save’. The personal pattern will be saved in the solution-personal layer and available together with the team-shared patterns on your computer, but it will not bother your colleagues.
    As to your question of clearing solution-personal settings, the only way to do it now is to delete the ‘[YourSolution].sln.DotSettings.user’ file in the solution folder. This will make ReSharper apply all team-shared settings for the solution (from the ‘[YourSolution].sln.DotSettings’ file) but will not affect your core settings saved in ‘This computer’ layer.

  4. Maximilian Haru Raditya says:

    I keep on wondering why those buttons don’t get merged into one drop down button.

    I think the UX could be improved by merging them into one. That way, a user can select which default action to choose. It’s set by default to machine level upon R# installation, but afterward it’s up to user to choose which one fits better. Then the default action setting is persisted so that next time VS being launched, the setting would be restored (and even better, it can be made configurable whether to restore the setting on solution level or machine level).

    What do you think?

  5. Joe White says:

    Yes, it might occasionally be valuable to save a custom pattern without sharing it. It wouldn’t happen often, but it could happen — in fact, we did have one person who needed to do that, six or eight months ago. That’s one example where “non-shared personal” could be useful.

    But if you practice shared code ownership, then it’s pretty rare for one person to take sole ownership of a particular kind of refactoring. More likely, patterns will either be used once and not saved (the “Find with Pattern” menu item), or given a replacement pattern and saved permanently for the team’s benefit.

    Even that is just one small piece of ReSharper configuration. What about code-formatting settings (maybe ReSharper added a new formatting option and we want to take advantage of it), or editing a code template or a file template (perhaps we upgraded a third-party library and need to change our templates accordingly), or changing the XML for the custom file-cleanup template (maybe we’ve started using MSpec and want to try to make the formatting accommodate MSpec tests, or maybe we’ve decided that we want to put nested classes last instead of first), or adding an acronym to the all-caps-allowed list (though we gave up on this, it’s easier to remember if we just PascalCase all our acronyms), or turning off a particular code inspection (like the “could be made static” that usually ends up biting us a few refactorings later)?

    Anything to do with code formatting, templates, coding style, etc., needs to be shared; otherwise the next person to touch your code would have a lot of work ahead of them trying to avoid unnecessary diffs. It just doesn’t make sense to even allow personal overrides for coding style. And coding-style settings are what we’re most likely to go into ReSharper Options to change.

    In my experience, your one example where it might be useful to save a local setting is outweighed by the (again, in my experience) far larger number of cases where saving a local override is the worst possible default (as well as being a difficult mistake to recover from).

  6. Dmitry Matveev says:

    @Maximilian, @Joe,
    Thank you again, your feedback is very helpful to us. We plan some improvements in the layered settings for ReSharper 8, and your arguments will be taken into account. You can follow developer discussion and the progress of the task on our issue tracker: Feel free to register and post your comments there.

Leave a Reply

Your email address will not be published. Required fields are marked *