We want to share .DotSettings
between several solutions. The goal is to have one CodeStyle.DotSettings
that we reference as a layer in all our X.sln.Dotsettings
. However, I am seeing unexpected behaviour when I add the layer.
I go to "Manage Options", right click "Solution X team-shared" -> "Add Layer" -> "Open Settings File", select CodeStyle.DotSettings
and click "Open".
I then inspect X.sln.DotSettings
, and see two references, one using an absolute path, and one using a relative:
<s:String x:Key="/Default/Environment/InjectedLayers/FileInjectedLayer/=3BE2D8150433584697322AAD3C173856/AbsolutePath/@EntryValue">C:\path\to\my\repo\CodeStyle.DotSettings</s:String>
<s:String x:Key="/Default/Environment/InjectedLayers/FileInjectedLayer/=3BE2D8150433584697322AAD3C173856/RelativePath/@EntryValue">..\CodeStyle.DotSettings</s:String>
Checking in an absolute path to my local repository makes no sense, so I try to remove that line from X.DotSettings
, but it then no longer shows up in the "Settings Layers" dialogue. The relative path seems suspicious with its leading dots, so I try to remove ..\
from it, but it still does not show up in "Settings layers".
What am I doing wrong?
We are using ReSharper 8.2.3
By default, you can share ReSharper settings per solution using the 'Solution team shared' layer — the only thing you need to do is to put the *. dotSettings file under version control. If you want to share settings in other ways, you would need to learn how to create new setting layers, import and export them.
The . dotSettings contains project or solution specific settings that can be shared with the team, e.g. naming standards or braces layout. If you wish to share these amongst teams then the file should be included.
See the corresponding issue in JetBrains' tracker: RSRP-339002.
Don't remove anything: ReSharper tries to load the file from both paths, so you should be fine. I've been using a similar setup (a shared and versioned DotSettings between multiple solutions) for the past two years without problems.
You can't remove the absolute path: it's used as a key. You can still vote for the issue. I personally don't like having an absolute path in a source-controlled file, even if it does no harm in this case.
Regarding the extra leading ..\
, I observe the same behavior. I've no clue why; maybe the path is relative to the cache folder rather than the solution folder? Anyway, it's definitely needed.
R# keeps both absolute and relative paths to accommodate all scenarios for using the injected file layers. Relative path works for source-control-hosted solutions with injected layer file also checked in to the same source control. Absolute path works for injecting a file from an outside resource, like a global path on the machine, or a network share in case of a source-controlled solution.
Absolute path is currently mandatory. Mostly for historical reasons. This can probably be changed to "require either one".
The relative path is relative to the disk file of the host layer into which it's injected. In your case it's the .sln.DotSettings
file. Why, it should have been its folder instead, but I missed the .Parent
thing when implementing it! And it hadn't surfaced during testing or beta program. Like, it worked for relative paths, and nobody bothered to count the doubledots up until now %-)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With