Support ReSharper 9.2

[stylecop]

Support ReSharper 9.2

[DevHim]

Great...
I hope this is still WIP.

[jimmymain]

me too, it would be really great to have my resharper support working again. It was working in 9.1.

[RaYell]

+1, having to run StyleCop separately from R# is a big inconvenience

[Jan-Olof]

I agree with you guys. It would be nice to have the StyleCop extension back.

[nunofilipecosta]

+1 I just miss stylecop , resharper it's not the same without it!

[citizenmatt]

I'm working on it! It's needing a little bit of love to get it good enough for 9.2. Here's the shopping list:

• Removing all of the old versions
• Removing old unused code
• Clean compile with 9.2
• Work without StyleCop installed as a VS extension, so it can be distributed on the ReSharper gallery. Also meant consolidating access to the StyleCop API to better reuse caches (still work to be done here - there are leaks of FileSystemWatcher classes)
• Rewrite options page to work with high DPI
• Use ReSharper's native extension mechanism for automatically importing settings from a settings file, rather than explicitly rewriting settings
• Update file layout settings to work with ReSharper 9's new file layout editor
• Rework code cleanup module. No more massive list of options here, mainly due to an API change in ReSharper, but also because they're just a bunch of checkboxes that mirror the Enabled setting in the settings files. Now there's just a single "Run StyleCop" option. This is the current bit of work in progress. Done, just needs testing.
• Default settings + custom dictionaries. These were pulled from the install directory.
• Add Visual Studio templates as ReSharper file templates
• Fix performance throttling, which currently leaves stale results. New implementation postpones StyleCop highlighting until 1 second after user finishes typing
• Fix leaking lots of FileSytemWatchers
• Fix multi-threaded usage of single threaded core runner API

I think that's it, but there could be more. Getting very close to releasing it to the gallery.

[sushiat]

Sounds all really good, just one question regarding the code cleanup module:
I typically disabled one or two of the options in there because they where conflicting with our code documentation style, is that possibility gone from now on or just configured somewhere else?

[citizenmatt]

It now looks at the settings.StyleCop file(s). This file is used when calculating the warnings, but was mostly ignored for the cleanup. It seems pointless to duplicate the settings into the code cleanup module - the code cleanup should just make the code look like what the warnings want to see (as best it can). So you can disable the rule in the settings file.

The downside to this is that there isn't an easy way to edit those settings right now. If you install StyleCop itself, you'll get a settings editor, so you can double-click the settings.StyleCop and get a bit of a UI that will update the XML file for you. Not ideal, and I'm not sure what to do here, so I think I'm pushing that out to a next release.

Out of interest, what was the setting you changed?

[sushiat]

I disabled the constructor/destructor documentation setting. We are using a "---------" separator line at the beginning and end of the documentation blocks which works fine for all other code elements, but on the constructors it wants the standard line:

Initializes a new instance of the <see cref="WhatEver"/> class.

But when using the separator line it doesn't seem happy and adds another one of those lines every time you clean up the code, I found files that had that line 5 times for each constructor :)

[adamralph]

Also, FWIW, StyleCop.MSBuild has become a very popular way of consuming StyleCop. For me it's the simplest way possible. You just install that package in your project and all of a sudden StyleCop analysis runs on every build. It's fully compatible with package restore which means StyleCop analysis gets carried with the source, but without the binaries, just like any other NuGet package.

It would be great if R# StyleCop support recognised this scenario as a first class citizen, bearing in mind (as usual I guess) that some people working on a codebase with StyleCop.MSBuild installed may have R# and others may not.

[adamralph]

Forgot the link - https://www.nuget.org/packages/StyleCop.MSBuild/

[jimmyheaddon]

Nice work @citizenmatt, looking forward to the release. Anything you need a hand with?

Also I'll echo @adamralph in that I always use the MSBuild NuGet package, and also the MSBuild Errors NuGet package (https://www.nuget.org/packages/StyleCop.Error.MSBuild/) which sets StyleCopTreatErrorsAsWarnings to false, but it would be nice if we didn't require this MSBuild node and the Settings.StyleCop option of 'Treat violations as errors' triggered this, not sure if that's possible?

[citizenmatt]

All, I've moved msbuild stuff to #11, so as not to derail ReSharper stuff. I'll respond over there :)

[citizenmatt]

@jimmyheaddon nothing at the minute, thanks. Testing once it's out would be brilliant, though. I'll see if I can get to a position for a pre-release version soon.

[JimBobSquarePants]

@citizenmatt Happy to test the crap out of this once you have something. If you need assistance in the interim please divvy out some tasks and I'll be happy to see what I can do.

[citizenmatt]

Hi all. I've just pushed the 9.2 package to the gallery. You should be able to download and install it now, from ReSharper → Extensions Manager.

You can find release notes here: https://github.com/StyleCop/StyleCop/releases/tag/resharper-4.7.0

Consider this a soft launch - please can you test this, and raise an issue for anything dodgy you find, please?

[meh-uk]

Installing now. It did seem to need an application restart - although I can't test that now to be 100% sure. But otherwise it seems to work well.

[jimmyheaddon]

Nice one @citizenmatt - installed and testing now.

For reference I also needed to restart Visual Studio 2013 after installing, as the StyleCop rules failed to show under 'Inspection Severity' for any ReSharper layer.

Am I right in saying that we still need to configure the rules in ReSharper to match those in Settings.StyleCop?

[jimmyheaddon]

One issue I've spotted - my Settings.StyleCop (alongside the .sln) is configured as 'en-GB', but I am seeing errors for XML comments being spelled incorrectly (it's expecting 'en-US'). I can't see an option to change this in the ReSharper layer configuration, should it be inferred from Settings.StyleCop?

[dfyx]

Same her with de-DE not being recognized.

[citizenmatt]

Yes, an application restart is required when you install any ReSharper extension.

And you can configure what severity a highlight shows up as in ReSharper, but the settings files should override that - if a rule is disabled in the settings, then it won't run, regardless of what's set in ReSharper.

Spelling should come from the settings files, I think. But I'd need to test it. I'll take a look as soon as I can.

[DevHim]

Using a custom settings file, the highlighting works fine.
I have a code cleanup profile where I have selected 'Apply StyleCop rules'. While performing the code cleanup it seems that default settings are used and not the custom one.

[andyste1]

Great stuff - I have missed the StyleCop editor squiggles since moving to R# 9.2 (VS2013).

As there is no longer a requirement to have StyleCop installed, does the extension still apply the exact same ruleset? We run StyleCop as part of our TFS builds, so I need to be sure that our developers (using this extension) won't miss any violations that will subsequently be picked up during a server build (using StyleCop) - assuming the same settings.stylecop file is in use on PCs and server of course.

Keep up the good work.

[jimmyheaddon]

A minor point @citizenmatt, when you run ReSharper 'Inspection Results', if you group by 'Issue Type and File', then all StyleCop errors are grouped under issue type "a", rather than "StyleCop".

[matteomigliore]

@citizenmatt sorry, I don't understand these things:

1. How to change the default Settings.StyleCop file, where to place it?
2. Is possible to use MSBuild Nuget package to apply StyleCop to the build? Where install the package, in which project?
3. I use StyleCop+ (https://stylecopplus.codeplex.com), is possibile to use it?
   Thanks a lot for your work.

[andyste1]

Since installing this extension, whenever I do a Refactor -> Rename, R# is putting "this." in front of the renamed variables, even though "Code Style -> Add/Remove 'this.' qualifier" and "StyleCop -> SA1101" are both set to "Do not show". Thoughts?

[citizenmatt]

@matteomigliore:

1. You need to add Settings.StyleCop to the root of the solution. As I understand it, you can also place a copy next to the file being analysed, and at any folder up to the root of the solution. There isn't a settings editor right now, so you pretty much need to know the XML format - more details are available on the original CodePlex site. You can still install the standard StyleCop distribution, which will set up a file association for the .StyleCop files and open them in a nice settings editor.
2. This project doesn't have an msbuild package. I believe @adamralph has a package of the last released set of rules - StyleCop.MSBuild, or if you're using Visual Studio 2015, you can use the new StyleCop.Analyzers package to install Roslyn analysers.
3. This project doesn't do anything to support StyleCop+, but looking at the site, it looks like most of the features are already available in ReSharper - you can configure ReSharper to set different naming conventions for different types of entity - classes, interfaces, fields, etc. However, doing so might conflict with existing StyleCop rules, in which case, disable the StyleCop rules in Settings.StyleCop.

[citizenmatt]

@jimmyheaddon I've logged a new issue for the "a" in Inspection Results - #16

[citizenmatt]

@markuskorbel I've added a new issue for the multiple separator lines - #17

[citizenmatt]

@andyste1 the ReSharper plugin hasn't changed the StyleCop engine, ruleset and settings files, so should be exactly the same (although there may be a couple of issues with settings files, there were definitely bugs to begin with - and I've probably introduced some more 😄)

[matteomigliore]

@citizenmatt yes, StyleCop+ is a StyleCop plugin, a .dll must be added, if I install StyleCop it goes in the installation folder. Where can I place it if the Settings.StyleCop goes at the root of the solution?
I can also install StyleCop e leave the settings in the installation folder?
I've to try the Roslyn analyzer.
Thank you!

[citizenmatt]

@andyste1 setting the severity of SA1101 won't affect what ReSharper does with the code cleanup - that just tells ReSharper how to display the highlights if the code doesn't conform (error, warning, suggestion, hint or hidden). If it's set to Do Not Show, StyleCop still considers it to be in violation, it's just not highlighted to the user. This is kind of awkward, but fits with running it at the command line or via msbuild - ReSharper settings have no effect. You'll need to disable this rule in a settings.stylecop file.

What's the exact setting for the Code Style "Use 'this.' qualifier for" option? This is what drives ReSharper to insert the this. qualifier. The default settings for StyleCop are to have "Field", "Property", "Event" and "Method" checked (the default shipped with ReSharper is "None").

[andyste1]

@citizenmatt I've found that checkbox list under Code Editing -> C# -> Code Style, unticked them all and it's okay now. The strange thing is they were unticked in my individual layers, and I only found them ticked when I went via the "Options" menu (rather than "Manage Options"). Curious to know what the difference is, and where the former saves the settings?
I've since noticed other issues similar to the "this." setting, which have started since installing the extension. E.g. many of my reformatting style settings that have been turned off/customised for years, but are now behaving as if they've reverted to default. Again they are still set correctly in the individual layers (via "Manage Options") but not when I go into "Options".

[citizenmatt]

@andyste1 The way the settings work is to ship the StyleCop settings in a settings file that is merged with ReSharper's defaults. In a clean install, this means StyleCop overrides ReSharper's default settings.

More technically, the StyleCop settings file is mounted as a layer, above the defaults, but below the global (and per-solution) levels. So, if you've already set any of these settings, your modifications take precedence (because they live in the higher priority global or per-solution layers).

You can reset the settings back to the StyleCop defaults by going to the StyleCop options page, and clicking Reset Settings. This removes any overriding settings from the global and per-solution layers.

The StyleCop settings shouldn't override any layers that you've already got mounted, as they're set to have a priority lower than globals, and anything you've changed will be saved to the global layer. However, ReSharper is "smart" when it comes to saving - roughly speaking, if the value you're setting is the same as in a lower layer, it simply removes it from the current layer. So, setting something to be the default value will not write the default value to globals, and ReSharper will just use the value from the defaults. But if the StyleCop settings override that setting, the new StyleCop values will win, because they have a higher priority than the defaults.

Hopefully, there's nothing in the StyleCop settings that shouldn't be there - it's mostly about formatting, and should be set up to give you the correct StyleCop format.

(You can also see what files are backing the layers by right clicking and selecting "Open Containing Folder")

[citizenmatt]

@matteomigliore ah, hadn't read the site properly. I've added an issue to get the resharper extension to load custom addins - #18.

[markvantilburg]

In the older version you could right-click in the current file and choose "stylecop" to check the current file and create warnings for it. Would it be possible to enable/add that context menu item?

[citizenmatt]

That's the Visual Studio addin, rather than the ReSharper addin. To get the warnings for a file in ReSharper, just open the file :)

The VS addin still works, pre 2015, and 2015 and up can use DotNetAnalyzers/StyleCopAnalyzers.

[citizenmatt]

@jimmyheaddon, @dfyx StyleCop's spell checker requires Office 2010 to be installed. It looks for the install location of 2010, and directly loads the appropriate spell checker .dll file, using P/Invoke to get at the API. If it can't find the .dll in the Office 2010 folder, it tries to load it from the location of the current AppDomain, or the location of the StyleCop assembly. If it can't load a specific dictionary, such as de-DE, it will fallback to the parent dictionary (de) and try again.

But, StyleCop itself only ships with the en dictionary, which I think is actually en-US.

So, @jimmyheaddon, in your situation, I'd guess that you don't have Office 2010 installed, and so it doesn't load the en-GB dictionary. It tries to fall back to the parent dictionary, which is en, and it finds that installed alongside the main StyleCop.dll assembly, so loads it.

@dfyx, I presume your situation is very similar - no Office 2010, so it can't find de-DE, but also can't find de. There are no more fall backs, so it doesn't load anything, and doesn't catch spelling errors.

You might want to try ReSpeller, a spell checker implemented as a ReSharper plugin - marks typos in the editor and provides alt+enter quick fixes to rename things appropriately.

[jimmyheaddon]

@citizenmatt interesting, thanks for the update. I have Office 2013 installed for reference. I'm using ReSpeller Free already and it works great, it's just the StyleCop warns me that I'm using en-GB instead of en-US :(

[citizenmatt]

Hmm. Easiest thing to do is to disable the spell check rules in the settings.stylecop file. Since StyleCop itself requires Office 2010 installed, this check will never work in your situation, whether you're running the ReSharper extension, the VS extension, MSBuild task, etc.

But "don't use it" isn't really the best solution. Do you have any better ideas for a solution? Should the ReSharper extension automatically hide warnings if the language isn't available? Even though that doesn't help with the other ways of running StyleCop?

(A better fix would be to use an Open Source spell checker, but if StyleCop is being retired in favour of StyleCopAnalyzers, it's not worth the investment, and frankly, ReSpeller provides a better experience for ReSharper users.)

[jimmyheaddon]

Good question, @citizenmatt. It would be nice if StyleCop checked for Office 2013 and fell back to 2010? I'm not sure how much effort this change requires, and given that Office 2016 was announced today it might be worthwhile supporting the latest 2-3 editions out-of-the-box?

[meh-uk]

I'd agree that we should support Office 2016 and Office 2013, although beyond security updates and official Microsoft support I can't see any justification as a developer to move to a newer version of Office so we should continue to support Office 2010.

I'd extend that justification to Office 2007, but we don't support it already so I see no reason to support it now when it's only got two years of extended support to go.

[philippdolder]

@citizenmatt I think it's completely ok for the StyleCop plugin to propose the usage of ReSpeller. StyleCop shouldn't be tied to any office installation anyways.

[RichardReeves]

@philippdolder Maybe I'm missing something; but remember that Stylecop is a tool that works on its own. People don't need R# to use Stylecop, so beware introducing a dependency on a R# plugin, when there is currently no requirement to have R# to use Stylecop.

[philippdolder]

@RichardReeves I'm just relating to the R# plugin for StyleCop. As things look now, the future are Roslyn Analyzers. That's why I think it's ok to not invest a lot in supporting a Feature in the R# plugin when there's another R# plugin that does about the same job. That was my first point.

The other is, agreeing with @citizenmatt, that the best would be to use an open source spell checker instead of relying on an office version. But if StyleCop is about to die sooner or later it's really not worth to put a lot of effort into new things.

[jimmyheaddon]

@citizenmatt - There is a beta of Proofing Tools that apparently doesn't work with 2007, 2010 or 2013, so that might be for Office 2016. It appears the Proofing Tools 2010 installer requires Office, Project or Visio 2010 installed, so you'll have to install the Proofing Tools for your particular Office version if you've performed a 'Custom' install and deselected it, as I had 😒

[jimmyheaddon]

@citizenmatt I've sent a pull request to add support for Proofing Tools from Office XP through to 2013, on both 32 and 64bit machines.

[EDIT] I've squashed the below commits in to a single one for the PR

[schlumpfmarkus]

Hi guys, two months no action on this ticket!? Do you know when it will be available?

Thanx for your hard work,
Markus

[citizenmatt]

Oops. Should have closed this - it's available on the Extension Manager right now. Search for "StyleCop by JetBrains" (there are two versions right now, sadly. The other version is buggy and closed source, and the author isn't responding to contact. Hopefully we can merge in the future).