Code cleanup of Rider vs ReSharper


as far as I looked into it, In resharper you can set way more fine details about your cleanup. When I use the cleanup built in in Rider, It seems to have way less options. Or am I missing something?

I thought about writing code in Rider and cleaning it up in vs with resharper but that seems odd...



R# and Rider's code cleanup profiles and available options for change should be identical, as you can see in the corresponding Help section for both products:

I would appreciate you giving me an example of the difference you have noticed so I could check it and please let me know the versions of both products you are currently using. Thank you in advance!


Hey, i just stumbled upon this:

so it seems what I've been missing, which is mainly File Layout Settings, will soon be available with Rider, too (I know it is already, but I'd wait for the UI Version)
Or I'll check if I can export the XAML file from VS with Resharper and import it in Rider...!

Thanks for your answer!


I have tested clean-up with both Rider and ReSharper (latest versions) and have had much better results with ReSharper. Twice I have seen Rider clean-up actually make source code errors (corruptions) which break a build. It's also slow.

I share a clean-up profile between RIder and ReSharper using a dotSettings file ( and Rider always tries to add annoying "SettingsMigration/IsMigratorApplied" lines. This happens even when creating fresh new dotSettings files in Rider or ReSharper which suggests something is wrong and I'm reluctant to commit such additions. They are not required on ReSharper which is where I now do all my cleanup.



Note on above: I have noticed ReSharper creating same IsMigratorApplied lines now too (not sure when this started or if I somehow missed it before?). But main good thing is ReSharper (Windows) and Rider (macOS) are now doing the same thing so I have committed these lines. I will start to report this and other issues I find systematically to JetBrains to try to help make Rider/ReSharper better products. (I realise this particular issue may be design behaviour but I think should be checked as I would prefer not to have noise like this in files under revision control.)

NB: issue can be reproduced by setting "Place property/indexer/event attribute on the same line" to "Never" in ReSharper and saving setting update to shared DotSettings file. You will then end up with 

<wpf:ResourceDictionary xml:space="preserve" xmlns:x="" xmlns:s="clr-namespace:System;assembly=mscorlib" xmlns:ss="urn:shemas-jetbrains-com:settings-storage-xaml" xmlns:wpf=""> <s:String x:Key="/Default/CodeStyle/CodeFormatting/CSharpFormat/PLACE_ACCESSORHOLDER_ATTRIBUTE_ON_SAME_LINE_EX/@EntryValue">NEVER</s:String> <s:Boolean x:Key="/Default/Environment/SettingsMigration/IsMigratorApplied/=JetBrains_002EReSharper_002EPsi_002ECSharp_002ECodeStyle_002ECSharpKeepExistingMigration/@EntryIndexedValue">True</s:Boolean> <s:Boolean x:Key="/Default/Environment/SettingsMigration/IsMigratorApplied/=JetBrains_002EReSharper_002EPsi_002ECSharp_002ECodeStyle_002ECSharpPlaceEmbeddedOnSameLineMigration/@EntryIndexedValue">True</s:Boolean> <s:Boolean x:Key="/Default/Environment/SettingsMigration/IsMigratorApplied/=JetBrains_002EReSharper_002EPsi_002ECSharp_002ECodeStyle_002ECSharpUseContinuousIndentInsideBracesMigration/@EntryIndexedValue">True</s:Boolean> <s:Boolean x:Key="/Default/Environment/SettingsMigration/IsMigratorApplied/=JetBrains_002EReSharper_002EPsi_002ECSharp_002ECodeStyle_002ESettingsUpgrade_002EMigrateBlankLinesAroundFieldToBlankLinesAroundProperty/@EntryIndexedValue">True</s:Boolean></wpf:ResourceDictionary>




Hello Mark,

Thank you for your report. There is an existing record on our tracker dedicated to the behaviour described: RSPR-473323. We would appreciate it if you would upvote it in order to bring increased awareness to the issue. Also please click to Watch it for monitoring the status.


Thanks Olga, I've upvoted and commented on the issue you referenced.


Please sign in to leave a comment.