How to use an existing settings file?

[stylecop]

How to use an existing settings file?

[citizenmatt]

It should just pick it up automatically. What's the problem that you're seeing?

[sam-piper]

I currently have StyleCop 4.7.49 installed for Visual Studio 2013 / R# 10.0.2, with an overridden StyleCop.Settings file in the program files directory for StyleCop.

However in VS 2015 the rules that are suppressed in this settings file are not suppressed anymore, so the settings file definitely isn't being picked up automatically, I can't see any option to point to a settings file from ReSharper > Options > Tools > StyleCop either.

What I've tried as a workaround is to set Inspection option to None for each rule I want to suppress then save to a team-shared settings file for ReSharper, that actually works just as well for our purposes, although it also means hand-editing the ReSharper settings.

[citizenmatt]

Are you using "StyleCop by JetBrains" or "ReSharper.StyleCop"? There have been some bugs fixed in "StyleCop by JetBrains" that relate to loading settings files. If you are using the right one, could you get a small repro, so I can take a look, please?

[mvonballmo]

I've experienced the same behavior as sam-piper. When I read the JetBrains blog post that finally cleared up which extension we should be using, I uninstalled the ReSharper.StyleCop and installed StyleCop by JetBrains. It says that it's a fork, so I was surprised when the "Settings.StyleCop" files I have in my solution folder seemed to be ignored.

I noticed because I have the "require this." rule turned off, but my source was filled with warnings about missing "this".

A couple of sample settings files are attached. Is this style of settings no longer supported? (Extension changes from "StyleCop" to "txt" to satisfy GitHub's upload restrictions.) How are we supposed to configure this extension?

project-specific.txt
all-projects.txt

[sam-piper]

This isn't really a problem for us anymore - because all the warnings are just normal ReSharper inspections, we just turn them off as desired and save the settings to a team-shared ReSharper solution settings file which is checked into source control.
This has ended up being much easier to use than the old settings file.
Maybe this just needs to be made a little clearer in the release notes for the extension?

Date: Fri, 29 Jan 2016 08:03:48 -0800
From: [email protected]
To: [email protected]
CC: [email protected]
Subject: Re: [StyleCop] How to use an existing settings file? (#36)

I've experienced the same behavior as sam-piper. When I read the JetBrains blog post that finally cleared up which extension we should be using, I uninstalled the ReSharper.StyleCop and installed StyleCop by JetBrains. It says that it's a fork, so I was surprised when the "Settings.StyleCop" files I have in my solution folder seemed to be ignored.

I noticed because I have the "require this." rule turned off, but my source was filled with warnings about missing "this".

A couple of sample settings files are attached. Is this style of settings no longer supported? (Extension changes from "StyleCop" to "txt" to satisfy GitHub's upload restrictions.) How are we supposed to configure this extension?

project-specific.txt

all-projects.txt

—
Reply to this email directly or view it on GitHub.

[mvonballmo]

If it's the case that the DotSettings files are no longer honored, then that should be mentioned in the release notes for users migrating from the other extension.

I would like confirmation from someone working on this project (e.g. @citizenmatt) before I change everything, though.

For background, I'm part of a team of developers for which the installed set of tools has diverged considerably. I'm in charge of redefining the baseline and I'd like to include this extension instead of the "old and busted" one.

I saw that the "true" recommendation from JetBrains is to use the StyleCopAnalyzers, which has its own configuration-file format. They seem to have thought it through really well, but using it also means I have to convert all of our configuration files.

If I have to change configuration anyway, what would you recommend? Using this extension or using StyleCopAnalyzers? Thanks in advance for any advice.

[sam-piper]

I evaluated the analyzers recently along with the JetBrains extension for StyleCop, and decided that the analyzers aren't quite ready for prime-time - for starters, there is no current ReSharper integration so the development experience is quite different, you don't get any help from ReSharper, which I found a little jarring after using StyleCop / ReSharper integration for nearly 5 years.
Also, I found the analyzers a bit buggy and slow to use in comparison to the ReSharper extension, and the default setup for the analyzers is to analyze on build, which is not desirable for us either so I would have had to do a lot of MSBuild customization to ALL our projects to switch this off, which I wasn't keen on doing.
Overall we decided to keep using the JetBrains extension because the ReSharper support in the IDE was the most important experience to maintain, and we solved the common settings problem through a shared DotSettings file in source control, and I'm quite happy with this approach, it is much easier to maintain and works as expected and there is no dependency at all on the 'old' StyleCop.
The biggest drawback of the JetBrains extension is that it is frozen for C# 5.0 so no new rules based on C#6+ will ever come out, however as of this moment it's not a big deal for us.
Ideally in future we will get a hybrid solution that combines the Roslyn analyzers with a ReSharper extension for the best of both worlds - ReSharper development experience, Roslyn-based analyzers, easy to switch on or off in builds, easy management of shared settings, C# 6 rules, etc.

Date: Fri, 29 Jan 2016 23:30:36 -0800
From: [email protected]
To: [email protected]
CC: [email protected]
Subject: Re: [StyleCop] How to use an existing settings file? (#36)

If it's the case that the DotSettings files are no longer honored, then that should be mentioned in the release notes for users migrating from the other extension.

I would like confirmation from someone working on this project (e.g. @citizenmatt) before I change everything, though.

For background, I'm part of a team of developers for which the installed set of tools has diverged considerably. I'm in charge of redefining the baseline and I'd like to include this extension instead of the "old and busted" one.

I saw that the "true" recommendation from JetBrains is to use the StyleCopAnalyzers, which has its own configuration-file format. They seem to have thought it through really well, but using it also means I have to convert all of our configuration files.

If I have to change configuration anyway, what would you recommend? Using this extension or using StyleCopAnalyzers? Thanks in advance for any advice.

—
Reply to this email directly or view it on GitHub.

[mvonballmo]

Thanks for your help, @sam-piper. I've now done the same for my main solution and will extend to others after a few days of testing. Everything seems to be working as expected.

One final question: With the old extension, I had a separate file to turn off the documentation requirement for public elements imposed by StyleCop for all of my tests. I noticed that this extension seems to do this automatically but couldn't determine where this is configured. I'm happy that it seems to be working as I'd like, but a little worried that this is a purely temporary coincidence.

[GuidoLeibbrand]

Sorry i am little bit confused over this dialog. I only have very simple questions to this topic:

After the update from VS2010 to VS2015 i updated R# to Version 10.0.2.. I see the problems with the stylecop integration. Installed the ReSharper Extensions called "StyleCop by JetBrains 4.8.0"

Now my questions:

• Can i use my old Settings.StyleCop file 1:1?
  Settings.StyleCop.txt
• Where is the correct destination path for the Settings.StyleCop i need this configuration global?
• I can only config my rule over the old C:\Program Files (x86)\StyleCop 4.7\StyleCopSettingsEditor.exe, right?
• How can i disable all style checks from R#?

Thanks,
Guido

[mvonballmo]

Most of your questions are the same as the ones I had and that @sam-piper answered in his comment from 31. January.

Can i use my old Settings.StyleCop file 1:1? Settings.StyleCop.txt

No. This extension uses the R# options (.DotSettings) rather than a separate StyleCop-specific files (.StyleCop)

Where is the correct destination path for the Settings.StyleCop i need this configuration global?

Global configuration (machine-level configuration) is in your %AppData% folder, as with all other R# settings.

I can only config my rule over the old C:\Program Files (x86)\StyleCop 4.7\StyleCopSettingsEditor.exe, right?

That editor only works with *.StyleCop files. Changes made with it will have no effect on this plugin's behavior.

How can i disable all style checks from R#?

The same way as you would for any other R# setting: by turning off the severity in the R# options dialog.

I did the following to convert from the original plugin to this one from JetBrains:

• Open *StyleCop file
• Collect list of StyleCop codes (e.g. SA1633 - "File must have header")
• Open R# settings
• Find the same code in the R# options and set the severity
• Save those options to solution-level options/shared with team so that everyone who opens that solution gets exactly the settings needed for that solution (we work on projects for different customers, each with slightly different StyleCop requirements, so this works for us. If you always use the same style, you may just want to save to machine-level).

Hope that helps.

[GuidoLeibbrand]

Thank you @mvonballmo for this short summery. Now i understand 👍

[citizenmatt]

This extension should be using the standard Settings.StyleCop files, loading them as normal (looking in the current folder and all parent folders).

ReSharper uses a dotSetyings file to store your settings, but this should be mostly invisible - the main file lives in your AppData folder, and shouldn't need to be hand edited. The plugin doesn't write to any other file (although it does ship the defaults as a standalone dotSettings file)

Do you have an example where it's not working?

[citizenmatt]

OK, I've just stepped through the code, and verified that the ReSharper plugin is definitely reading Settings.StyleCop files, so I'm not sure what's going wrong - can someone post an example of it not working, and I can look further.

[citizenmatt]

Going to close this as can't repro. If you have an example repro you can put onto DropBox on something, please reopen, and I'll take a look.

[JGCreator]

I'm still not seeing the same behavior I had in resharper 8...

Please help.

Thanks,
small repo

[citizenmatt]

I've had a look at the repo, and I don't see any problems. I get warnings, as expected, and alt+enter fixes them up. I don't see anything unexpected happening.

Could you provide a step by step list of what you're doing, what you're seeing and what you expect to see, please?

[mahara]

@citizenmatt

This extension should be using the standard Settings.StyleCop files, loading them as normal (looking in the current folder and all parent folders).
... I've just stepped through the code, and verified that the ReSharper plugin is definitely reading Settings.StyleCop files ...

Matt, I don't really understand how this settings file propagation actually works. How do you mean by reading Settings.StyleCop files? Does it also change related StyleCop setting in R# Options, in Inspection Severity for example?

In my case, I have the following settings disabled in Settings.StyleCop in the root folder of my solution.

• SA1513 / Closing Curly Bracket Must Be Followed by Blank Line
• SA1515 / Single Line Comment Must Be Preceded by Blank Line

However:

• R# Inspection Severity of two options above still showing as Warning instead of Do not show.
  Is this by design? If so, is there any way to automate this setting propagation between Settings.StyleCop and R# Inspection Severity Options?
• Using Code Cleanup, with Fix StyleCop violations enabled/checked, causing the following code:

            var a = true;
            if (a)
            {
                var b = 0;
                // Comments
                var c = false;
                if (c)
                {
                    var d = 1;
                }
                // Comments
            }
            var e = 1;

to be formatted into this:

            var a = true;
            if (a)
            {
                var b = 0;

                // Comments
                var c = false;
                if (c)
                {
                    var d = 1;
                }

                // Comments
            }
            var e = 1;

that a new blank line is being incorrectly added before each single line comment. It seems there is a bug in R# StyleCop extensions regarding SA1515, although SA1513 seems to be working just fine.
Note that this doesn't happen when disabling/unchecking Fix StyleCop violations with the same unchanged Settings.StyleCop file; the example code above is being left intact.

Thanks.

[citizenmatt]

There's a default settings.StyleCop file that is installed by the extension, and it sets various defaults for the rules, etc. This is always loaded and read. But you can also have a settings.StyleCop file in your solution or project root. These are read and merged with the defaults, so you can disable specific rules per-project/per-solution. (You can actually have a settings file live in any source folder - whenever any C# files in that folder are analysed, those settings are also merged.)

The settings files only control StyleCop settings - usually whether a rule is enabled or disabled. This is completely separate from the ReSharper severity settings. The severity is only used to choose how to display a violation, not whether the rule is actually processed. So if a rule is disabled in the settings file, it will never be displayed in the editor, because the rule doesn't run as part of analysis. Similarly, if a rule is enabled, but the severity is set to "Do not show", then the rule is still run, but the violation is hidden.

This is because StyleCop owns the settings, not ReSharper. Because StyleCop can also be run as a command line tool, or even a Visual Studio plugin, the settings should be stored in settings.StyleCop, and not a ReSharper specific format or you will get different results in different tools. So, it would require some kind of sync between the ReSharper settings and the StyleCop settings, e.g. when disabling a rule in settings.StyleCop, it would need to also set the ReSharper inspection to "Do not show". This is fairly easy, but it's harder in the other direction - when changing the ReSharper inspection severity, that should disable/enable the rule in the settings.StyleCop, which means rewriting the settings file. And due to the folder/project/solution hierarchy, there would need to be a policy of where this data gets saved, which isn't easy to formulate, and wouldn't be reflected in the ReSharper options UI.

[citizenmatt]

Could you open a new issue for the code cleanup bug, please? If you could add the settings file as well as the repro, it would be a big help, too. Thanks.