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.
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.
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.
Subscribe to Blog updates
Thanks, we've got you!
Eager, Lazy and Explicit Loading with Entity Framework Core
Entity Framework Core (EF Core) supports a number of ways to load related data. There’s eager loading, lazy loading, and explicit loading. Each of these approaches have their own advantages and drawbacks. In this post, let’s have a quick look at each of these ways to load data for navigational prope…
OSS Power-Ups: bUnit – Webinar Recording
The recording of our webinar, OSS Power-Ups: bUnit, with Egil Hansen and Steven Giesel, is available. This was the twelfth episode of our OSS Power-Ups series, where we put a spotlight on open-source .NET projects. Subscribe to our community newsletter to receive notifications about future webi…
Accelerating Your Testing Workflow with Unit Test Creation and Navigation
Unit tests play an important role in our daily development workflow. They help us ensure our codebase's correctness when writing new functionality or performing refactorings to improve readability and maintainability. In the process, we often create new test files that accompany the p…
Introducing Predictive Debugging: A Game-Changing Look into the Future
With the introduction of debugging tools, software developers were empowered to interactively investigate the control flow of software programs to find bugs in live environments. At JetBrains, we've always strived to improve the art of debugging. Besides the more standard things you expect from a de…