What is .DotSettings Housekeeping section?

Hello,
I see that R# automatically add following setting to my .DotSettings.user file.

<s:Boolean x:Key="/Default/Housekeeping/UnitTestingMru/UnitTestSessionPersistentData/=1B789A56F8E1454DB9FB34C4A974DC85/@KeyIndexDefined">True</s:Boolean>
<s:String x:Key="/Default/Housekeeping/UnitTestingMru/UnitTestSessionPersistentData/=1B789A56F8E1454DB9FB34C4A974DC85/Name/@EntryValue">All tests from Miscellaneous Files</s:String>
<s:String x:Key="/Default/Housekeeping/UnitTestingMru/UnitTestSessionPersistentData/=1B789A56F8E1454DB9FB34C4A974DC85/XmlSerializedElements/@EntryValue">&lt;Session&gt;&lt;Elements&gt;&lt;UnitTestElement Provider="MSTest" d="MsTest:...s:String>

It's hard to find any info about it.
As i understand every unit-testing session stores here.
Is it possible to store unit-tesing session not in .DotSettings.user file?
Thanks

11 comments
Comment actions Permalink

The contents of the .dotSettings.user file are not documented, but are used to store settings that are per-user, such as the current state of unit test sessions. It's not possible to store it anywhere else, but it can be disabled under ReSharper -> Options -> Unit Testing -> "Save and restore Unit Test Sessions".

Why do you want to store it somewhere else? If it's related to source control, the .dotSettings.user file isn't intended to be checked in, in the same way that Visual Studio's .csproj.user files shouldn't be checked in. I normally set up an ignore for *.user.

0
Comment actions Permalink

Thanks, Matt!
Now i know walkaround for my problem (switching off "Save and restore Unit Test Sessions").

I know that *.user files are per-user but we have an issue and we found only *.user files to help us.
Maybe you know any other solution...

We create nuget-package with cross-team DotSettings.
But working with Web UI projects with lots of external *.css and *.js (from nuget packages such jquery, knockout etc) files we had a great number of R# warnings in files we don't want to change cause it external code.
We tried to use hierarchical per-solution settings and exclude every external file with don't want R# to analyze but... there is a ApsolutePath param which makes it unusefull to use hierarchy per-solution.

Best Regards,
Agarev Denis

0
Comment actions Permalink

Source files (e.g. .js files) included from a nuget package should be ignored by ReSharper by default. ReSharper will check to see if each source file comes from a nuget package, e.g. jquery.js, and if so, it treats them as a non-user file, and doesn't analyse them. Also, when ignoring a file by adding it to the list of "generated files" (ReSharper -> Options -> Generated Code -> Add File), the filename is stored as a relative path, relative to the project location. The filename is stored in the .sln.dotSettings.user file by default (because it doesn't make sense to put it in the global options, and you should explicitly choose to make it a team-wide setting), but it's easy to save as team wide - just use the "Save To" button once you've added the file, and save it to the "team-shared" settings file. This will save it to the .sln.dotSettings file.

I'm not sure what you mean about the nuget package with cross team dotSettings - do you have a nuget package, added to the project containing a project.csproj.dotSettings.user file?

0
Comment actions Permalink

I'm not sure what you mean about the nuget package with cross team dotSettings - do you have a nuget package, added to the project containing a project.csproj.dotSettings.user file?

- no just *.DotSettings file. We were thinking to use *.dotsettings.user file to store file we need to exclude from R# analyze but you wrote:

Source files (e.g. .js files) included from a nuget package should be ignored by ReSharper by default. ReSharper will check to see if each source file comes from a nuget package, e.g. jquery.js, and if so, it treats them as a non-user file, and doesn't analyse them

- can it be changed? maybe we have this feature switched off and resharper analyze this files.

0
Comment actions Permalink

And also yhe main question:
Is it possible to add dependent .DotSettings file without AbsolutePath?

0
Comment actions Permalink

Ah - .dotSettings files added as layers are listed with both a relative AND absolute file path. So the absolute filepath is tried first, and then the relative one is used if it can't be found. Best of both worlds.

The check for nuget files is built-in and can't be changed. What version of ReSharper + Visual Studio are you using?

0
Comment actions Permalink

Visual Studio 2013 Update3 with Resharper 8.2.2.

Anyway many thanks Matt!
Now many issues are clear to me.
I'll check adding new files.
Maybe it was with some old version of resharper or it can be also cause of StyleCop, i'll check all cases,

0
Comment actions Permalink

By the way is their an algorithm to ckeck is file from nuget package or internal code file?
Maybe i just need to fix smt in *.csproj file.

0
Comment actions Permalink

It's a simple check - ReSharper maintains a cache of all files in Contents folders in all referenced packages. Any files in the project that have the same filepath as one of these files are marked as non-user files. So, look in your nuget packages (and they must be referenced in packages.config), look for any Contents folders, and see if any files from those contents folders are in the same location in the project. E.g. if a package has a file Contents\scripts\foo.js, then the project file scripts\foo.js will be marked as non-user.

0
Comment actions Permalink

Ok now I gave up using *.DotSettings.user file as a team shared and source control stored settings and looking how to use layers to solve my case.
You wrote:

So the absolute filepath is tried first, and then the relative one is used if it can't be found

Thats sounds great but....
When i add a layer i see this new keys in parent *.DotSettings file.

<s:Boolean x:Key="/Default/Environment/InjectedLayers/FileInjectedLayer/=7498433E4CCC3F4CB44D85518E434B30/@KeyIndexDefined">True</s:Boolean>
 
<s:String x:Key="/Default/Environment/InjectedLayers/FileInjectedLayer/=7498433E4CCC3F4CB44D85518E434B30/AbsolutePath/@EntryValue">C:\Projects\Sources\Project.sln.DotSettingsfile://\\_Projects\Integration</s:String>
 
<s:String x:Key="/Default/Environment/InjectedLayers/FileInjectedLayer/=7498433E4CCC3F4CB44D85518E434B30/RelativePath/@EntryValue">..\TeamShared.sln.DotSettings</s:String>
 
<s:Boolean x:Key="/Default/Environment/InjectedLayers/InjectedLayerCustomization/=File7498433E4CCC3F4CB44D85518E434B30/@KeyIndexDefined">True</s:Boolean>
 
<s:Double x:Key="/Default/Environment/InjectedLayers/InjectedLayerCustomization/=File7498433E4CCC3F4CB44D85518E434B30/RelativePriority/@EntryValue">1</s:Double>

And if i change even a letter in "Default/Environment/InjectedLayers/FileInjectedLayer/=7498433E4CCC3F4CB44D85518E434B30/AbsolutePath/@EntryValue" key, layer relation ship breaks after VS restart.
Hot to use only RelativePath? cause i need to use lauyr as a teamshared relationship

0
Comment actions Permalink

So, looking at the code to load settings, ReSharper will check the absolute path is set, and is an absolute path (that is, it must look like a valid path, even if the file doesn't exist). It then checks the relative path. If it's set, it tries to use it, by combining it with the path of the hosting layer (e.g. the .sln.dotSettings file). If this path is null, it falls back to the absolute path.

Which means I got it wrong! It uses the relative path first, then falls back to the absolute path. BUT, the absolute path must still be set, and must at least look like a real path, even if it doesn't exist.

The best thing to do, is to add a layer to a file that is already in the location within the project structure that you want it to be. It will be added with the right relative path, relative to the hosting layer (.sln.dotSettings) and with a valid absolute path that is correct for your machine. When someone else checks out these changes in a different location, the abosulte path will be a real path, but not pointing to a real file. The relative path will still be correct, because it's relative to the .sln.dotSettings file. This way, you don't need to worry about editing the .sln.dotSettings file manually.

(I suspect the settings you pasted in don't work because the absolute path value isn't a valid path definition)

0

Please sign in to leave a comment.