dotSettings layers: shared file over user application data folder

Avatar
Permanently deleted user
Created

Hi All,

For our company, I'm trying to setup a "company shared settings file", simular to this.

This works fine, however, the global user's settings file (C:\Users\<USER>\AppData\Roaming\JetBrains\ReSharper\vAny)
always takes precedence over this "company shared setting file".

I understand the layering approach:

  1. Solution - personal
  2. Solution - team shared
  3. This computer


I can live with layering idea that a team can overwrite default computer settings, and a person can overwrite team settings.
However, within the "This computer" layer, there is no option to reorder settings files from "This computer".
This means that the global user's settings file (C:\Users\<USER>\AppData\Roaming\JetBrains\ReSharper\vAny), always takes precedence over the company wide settings file.


How can one force the company settings to be applied over the global user's settings?

  • Is it possible to reorder usages in the "This computer" layer?
  • Is it OK to just delete all .dotSettings from C:\Users\<USER>\AppData\Roaming\JetBrains\ReSharper\vAny, so that no global user settings exist?



How are other people dealing with company wide settings?
I think it would be a good option to make it possible to "switch off" layers / elements within layers, so one always knows it's (for instance) using company settings.

Thanks for your time,
Koen
 

Votes

0

Share

4 comments
Avatar
Alex Berezoutsky
Created

Hi Koen,

Thanks for the message.

The thing here is playing with 'Default ReSharper Settings' (and 'Not-Default' ones). If the dotSettings file contains non-changed value (e.g. default one), and 'This Computer' layer contains changed options - the option will still be overriden.
Here are some steps to workaround this behavior:
1) Reset This Computer layer in the Manage Options dialog (removing the 'vAny' folder content does the same).
2) Apply the 'check-uncheck' step for Shared Settings layer. E.g. if a some R# options checkbox is checked by default, just uncheck it -> Save the settings -> check it back. Doing this will provide R# the info, that this option in now in non-default value, and override the 'This Computer' settings.

I agree that this behavior is not very logical (sometimes) and is not easy to understand, but this is how things work now.
Hope it helps.

P.S. We will discuss this layer behavior inside the team. IMHO, possible solution for this is to export full settings with their default values to the dotSettings file... We will look into it.

0
Avatar
Permanently deleted user
Created
Hello, The current state of the settings system is such that it has the "enabling" features (to allow sharing) but does not include any "limiting" features (... yet?). With "enabling" features it was more or less clear what we could do. We introduced layers as a metaphor for levels of sharing (local settings, team-shared along the solution, arbitrary files mounted on the local machine, additional files mounted with the solution, etc), and we made it possible for each and every setting to be defined on any of these layers.We also kept the possiblity to open the good old options dialog without any layers standing out, and edit the settings as if they were plain — any change is heuristically applied to the layers so that (a) it takes effect in the current context, and (b) it doesn't touch shared layers and mounted side-files by default. This way as a new user you don't have to deal with layers out-of-the-box, these details can be ignored until you need to set up smth advanced with layers. Even if you're receiving some "team-recommended defaults" with the solution context, you can still open the Options dialog and change something — the change will be successful (a), and the others on the team won't be affected with your personal preference (b). Currently, it's up to each team member to make sure that the personal preference he changes does not make his code look bad for the others on the team — as there's no "technically-limiting" functionality. All limiting is voluntary. That's because we couldn't come up with any good and consistent limiting scenario (maybe didn't take enough time to design it properly, but anyway). Moreover, the system (which is non-trivial already) gets even more complicated with restrictive functionality.We can't just remove the ThisComputer layer because there're lots of environmental settings, like UI preferences, window positions, MRU items, and so on.Right, these can be filtered by root settings keys and put aside, but even code-related settings might be different in semantic. Some analysis/highlighting choices, like "warnings as errors", are team-important. But other highlightings are entirely a matter of taste. With Live Templates (or Search Patterns), some templates are useful for all the team, but others might be created for personal (private) use and should not occupy completion listst of other team members. This distinction is hard to set up with a limiting system. Right now the idea is that you're changing everything privately by default, but you can share anything with an explicit action (by copying a section of the settings, or by doing Save To, or by editing settings in context of a specific layer).Also with the current UI it is not possible to visualize the fact that we are not allowed to change the certain setting, and (more importantly) why. So we'd be violating the invariant (a) without any proper UI feedback, which would be much confusing for the user. The order of layers is chosen so that it satisfies the (a) and (b) invariants: the shared file is not touched by default (why, it might be readonly on a network share!), and we always have a writable higher-priority layer over it in case the user changes some setting in the simple mode of the Options dialog. In our case, ThisComputer has a slightly higher priority than the mounted file. So, with the current system:* The parent layer always takes precedence over the mounted layers added under it.* If you delete the disk backend file of any layer (predefined or mounted), this will empty the layer contents, but the layer itself will be functional just as good. With ThisComputer, some UI settings will inevitably reappear quite soon.* The predefined layers cannot be switched off, mostly because of the (a) and (b) invariants.* This non-restrictive mode works at least for our team. Some defaults (not for everything, just most important things like naming and some formatting) are shared with the Solution Shared layer, and we're free to adjust personal perferences, as long as they're within the reasonable limits of the code style guidelines. The scenario for starting the sharing might look like this:* If you're sharing with a file mounted on each machine under ThisComputer, you might want to clear the corresponding sections in the old layer (like these: CodeInspections, CodeStyle, and CodeEditing). The "Reset" functionality shows you a tree view of the settings sections defined in this layer, and allows to choose which of them to wipe out.* If you're sharing with a file mounted under the SolutionShared, you don't have to set up each machine (set up each solution instead), and it will take precedence over local settings by default. Anyway, you might still want to reset these sections in ThisComputer to ensure a clean experience.* The person who's allowed to change the team-shared settings should either be opening the specific layer for editing, or might instead be copying own settings to that layer from time to time (the Copy function also allows to choose the sections).* Others should not be changing the settings covered by team-sharing without a good reason. Hope this helps.
0
Avatar
Permanently deleted user
Created
The forum is eating all of the line breaks when posting. I'll try to fix the formatting tomorrow. Sorry for that ;-)UPD: the bloody forum keeps eating the line breaks. Adding image screenshots of the original posting.

Attachment(s):
TxtPage2.png
TxtPage1.png
0
Avatar
Permanently deleted user
Created

Thanks for your clarification.

In order to create a set of rules for our company, over all of our projects, we took this approach:

  1. Created a shared .dotSettings file, pushed into a GIT repo
  2. Every developer makes sure that this file is mounted in his "This Computer" Layer (one-time action)
  3. Every developer is responsible for clearing his global "personal" .dotSettings file (C:\Users\<USER>\AppData\Roaming\JetBrains\ReSharper\vAny)
    If he chooses to override certain settings, he will break the build in step 4
  4. TeamCity checks out the shared .dotSettings file, and runs CodeInspection on every build

We're running this for a couple of weeks now, without too many problems.


Thanks for your time!
Koen
0

Please sign in to leave a comment.