ReSharper Settings in 6.1

This post is about ReSharper 6.1. For other features in ReSharper 6 (both 6.0 and 6.1), please see previous posts introducing ReSharper 6:

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

image

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

image

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:

image

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:

image

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.

image

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

image

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:

image

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.

This entry was posted in News and Events and tagged , , , . Bookmark the permalink.

49 Responses to ReSharper Settings in 6.1

  1. psulek says:

    Seems interesting, hope all will works as is expected to.

  2. Joe White says:

    Two questions:

    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?

  3. Hadi Hariri says:

    @Joe

    1. When you hit save/ save to only the things you’ve just changed and which are different from defaults are get saved.

    2. All the settings are saved immediately. And moreover, if the file is changed externally somehow, the settings are immediately applied.

  4. Carel Lotz says:

    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.

    Keep up the good work.

  5. Rangoric says:

    If this results in being able to have different headers in different projects easier then I’m happy. However sharing these settings once the rest of my team starts using Resharper will be a huge boon.

  6. Valeriu Caraulean says:

    I’d like to be see a response to scenario of Carel Lotz, how do we share settings between solutions in a team.

    Another (similar one) is to have few solutions in same folder covering different set of projects. How to we share settings across them in a team?

  7. Asbjørn Ulsberg says:

    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?

  8. Eric says:

    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.

  9. Tim Herby says:

    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.

  10. Bill Sorensen says:

    I’d also like what Carel, Eric, and Tim requested – share settings across a team for all projects.

  11. Hadi Hariri says:

    @Valeriu, Carel, Bill and Eric,

    I’ll be covering more scenarios in upcoming posts, as I mentioned in the last paragraph.

  12. Hadi Hariri says:

    @Asbjørn

    AFAIK it’s something we can’t change last I talked to Sergey, but I’ll check again.

  13. Hadi Hariri says:

    @Rangoric

    You can do this now (different headers for different solutions)

  14. Hadi Hariri says:

    @Tim,

    1.I’ll be covering other scenarios soon.

    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.

  15. Markus Springweiler says:

    Where does the information about additional layers get stored? Is this per solution?

  16. Markus Springweiler says:

    Ok, just found it: It’s stored inside MySolution.sln.DotSettings

    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.]

  17. Hadi Hariri says:

    @Markus,

    Sorry, I’m missing something. I pointed out the filename and said that it should be added to version control.

  18. Markus Springweiler says:

    All our company solutions look like this (“.” stands for solution root):

    .
    .ProjectX
    .Helpers (Model, Viewmodel, etc.)
    .libs
    .libscorporate
    .libsotherlibs

    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:

    .libscorporateLayerFileName.DotSettings

  19. Hadi Hariri says:

    @Markus,

    That issue will be resolved in an upcoming build. Thanks for pointing it out.

  20. Julien Lebosquain says:

    @Hadi,

    Thanks, the new settings system is great!

    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.

  21. Hadi Hariri says:

    @Julien,

    Highlighting changes is on the list, however I’m not sure it will make it to 6.1.

  22. Marcos says:

    The new options are increible useful :)

    We are finally using the same options with the team.

    Just a important thing, when you are custumizing the options from zero the best way to customize the quick fixes is via the bubble menu, inspections options for …

    But there you can’t select what layer are you changen and the options go always to Global Resharper Options

    I just created a ticket for that.

    http://youtrack.jetbrains.net/issue/RSRP-283177

    Thanks

  23. Joe White says:

    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.

  24. Hadi Hariri says:

    @Joe,

    When you save to Team, it will save everything. You don’t need to worry about that. Have you actually had an issue here?

  25. Joe White says:

    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.)

  26. Hadi Hariri says:

    @Joe

    We’re looking at this and hopefully it won’t be an issue by the time of release.

  27. George says:

    Is it possible to unload/load resharper per solution? I have large legacy solution and using resharper with it causes lots of out of memory exceptions.

  28. Hadi Hariri says:

    @George,

    You can disable ReSharper via Tools | Options | ReSharper and assign a hotkey to it.

  29. Pratik says:

    My Resharper 6.1 EAP build expired. Is there any way where I can get unlimited usage of R# 6.1 EAP?

  30. Hadi Hariri says:

    @Patrik,

    We are providing nightly builds: http://jetbrains.net/resharper

  31. Oleg Gerovich says:

    +1 for Carel’s scenario. I consider that part of http://youtrack.jetbrains.net/issue/RSRP-47805.

  32. Jacek Sieka says:

    Ok, so I installed 6.1 EAP and have to wonder – what’s in the .6.1.resharper file if all settings are supposed to be stored in the “.DotSettings” file?

  33. Hadi Hariri says:

    @Jacek,

    Can you please give me the build number?

  34. Jacek Sieka says:

    Hi,

    6.1.33.62 is the only EAP I installed.

    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.

    Regards,
    Jacek

  35. Jacek Sieka says:

    Hi,

    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?

    Regards,
    Jacek

  36. Bhanu says:

    I am using the R# 6.1 released version.
    With respect to the following ticket:
    http://youtrack.jetbrains.net/issue/RSRP-283177

    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?

  37. @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.

  38. Jason Taylor says:

    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?

    Thanks!

  39. Bhanu says:

    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.

    Is there a plan to address this requirement?

  40. Bhanu says:

    Related to my earlier post:
    I think this requirement is being discussed here — http://blogs.jetbrains.com/dotnet/2011/12/resharper61-settings-dropbox-and-company-wide/
    Please Ignore my previous post.

  41. Bhanu says:

    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.

    Has anybody faced this problem?

  42. Roger Lipscombe says:

    Can we have a per-project layer? I’d like to be able to configure things differently for unit test projects versus application code, for example.

  43. Jimmy says:

    This still doesn’t seem to be working correctly, I’ve raised an issue here:

    http://youtrack.jetbrains.com/issue/RSRP-300829

    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)!

  44. Hadi Hariri says:

    @Jimmy

    Thanks. We’ll look into it.

  45. Jan Nordén says:

    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.

  46. Hadi Hariri says:

    @Jan,

    Thanks. We’re aware of this issue and will try and solve it in some way.

  47. He Fen says:

    @ Hadi Hariri How do we apply the same settings shared across all projects across the whole team? I see that you said you would talk about this issue at your next post, could you give me the link?

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>