Per Project Settings or How to have different naming styles for my test project

One nitpick that I myself and many have had with ReSharper is not being able to have different naming styles for types based on different projects. In my code I normally name classes using CamelCase


and in my test project I use all_lowercase


Unless you add all_lowercase as a valid naming style, you’ll always end up with those squiggly lines under all your tests. And let’s admit it, it’s not a big deal but it’s annoying. #FirstWorldProblem

Say hello to my little layer

With ReSharper 6.1 we introduced the concepts of layers, which open up many new possibilities, including sharing settings on DropBox and or setting company wide standards. What you might not know is that it allows Per Project Settings too! No big deal if you didn’t know, since we currently do not support it via the User Interface so it would be hard to figure it out. However it’s pretty simple to do and I’m going to show you how.

Our goal here is to allow all_lowercase settings for classes in our test project (Tests) and not permit the same in other projects (Project). This is the sample project layout we’re going to be working with


To make this happen, we need to create specific settings for the Tests project and allow the possibility of classes being all_lowercase. That is, the Tests project needs its own DotSettings file.

Since there’s no specific button or option to add Per Project settings in the UI, this is where we need to kind of use a workaround. We need to have a Settings file for the project and then edit the options and save it to this file. There are many ways to create this new settings files. We can copy the solution one and rename it, we can export the current settings, we can mount a new layer and have ReSharper create it for us, etc.

We’re going to use this last method. Why? Because since ReSharper mounts it when it creates the file, it will allow us to edit the settings too.

1. With the Solution open, click on Manage Options under ReSharper

2. Under This Computer, click on the Add Layer icon (on the right) and select Create Settings File


3. Save the file to the Tests project folder, in our case that would be under SolutionDirTests and name it (and here’s the important part) Tests.csproj.DotSettings. That is, it should be named with the ProjectName, followed by csproj or vbproj based on the type of project and with the extension DotSettings.

4. Now that we have the settings file mounted, we need to change the required settings, which in our case is to allow classes to have all_lowercase (this obviously works for other settings too). As such, double-click the recently mounted file or right click and click on Edit


5. The Options dialog comes up. We want to edit the naming styles


Modify any other settings you wish at this point and once done, hit Save on the Options dialog.


At this point, we can remove the mounted settings as its not required for it to actually work. We can also leave it in order to easily access the settings for the project in the future. If you do leave it, make sure you uncheck the checkbox so that settings are not applied to the entire solution.

[Recommendation: If you decide to leave the settings mounted, mount these under Solution Shared or Solution Personal as opposed to This Computer so that you don’t end up with a long list of different settings files]

As soon as we hit Save, the new settings automatically are picked up by ReSharper and take effect. We can now see that the naming style no longer appears incorrect under the Tests project


and if we try and use the same style in the actual Project we do get the warning


The UI will come

Once you do this once, you can pretty much copy the same file over to your different projects and rename it to match the project name. In one of the next versions of ReSharper we will provide a more intuitive UI (or should we say we’ll provide an actual UI) for this. For now however, I think this minor hack will make a few people happy!

This entry was posted in How-To's and tagged , , , . Bookmark the permalink.

29 Responses to Per Project Settings or How to have different naming styles for my test project

  1. Bill Sorensen says:

    It’s not that our company wants per-project settings, it’s that we want per-project-type settings. Unit test projects have one convention, client application projects another, and web projects a third. This is a step in the right direction.

  2. Tim Herby says:

    Does this apply to solutions? Do you automatically read and apply a “.sln.DotSettings” if there is one?

  3. Hadi Hariri says:


    That’s how it works by default now. When you save settings for solution, it saves them as a .sln.DotSettings file. That part is supported in the UI.

  4. Tony Hunt says:

    That’s a useful feature Hariri, thanks for that.

    I’ve just come across an alternative method that targets tests:

    I just wish there was a naming style of SomeTitleCase_MoreTitleCase or even SomeTitleCase_MoreTitleCase_MoreTitleCase.

  5. Hadi Hariri says:


    Yep. That works too!

  6. Tony Hunt says:

    @Hadi, apologies for addressing you by your last name.

  7. Tim Herby says:

    Thanks. Actually I mis-spoke. I’m actually looking for multi-solution settings. It sounds like solution-level is automatic as you described, but what about this hierarchy:


    If I want to apply settings to both, I’d like be able to place a *.DotSettings file in either /Root or even the directory above it, and have it apply to both solutions. Is this possible? Can it be hooked automatically like this is for csproj files?


  8. Serg says:

    Is it possible to set such rule as Tony suggested: SomeTitleCase_MoreTitleCase or SomeTitleCase_MoreTitleCase_MoreTitleCase?

  9. Hadi Hariri says:


    Out of the box this functionality as far as I’m aware is not currently supported. I will check though and get back to you if it is.

  10. Joe White says:

    @TonyHunt, +1 for the suggestion of SomeTitleCase_MoreTitleCase_MoreTitleCase. We use that in our tests — “ThisMethod_InTheseCircumstances_ShouldDoThis”. Currently we just tell ReSharper not to check method names at all, but that’s not a great workaround.

    Have you written a YouTrack ticket for adding a TitleCase_WithUnderscores option? If so, post a link here and I’d be happy to vote for it. If you haven’t written a ticket, perhaps I should. (Heck, for all I know, maybe I already have…)

  11. Hadi Hariri says:

    @Joe, Tony, Serg,

    Log it please, give me the ID and I’ll see if we can try and get it scheduled.

  12. Tim Herby says:

    @Hadi, an alternative I just thought of: Can a .sln.DotSettings file just reference a team settings file by relative path? This would solve the problem by avoiding each developer having to add a top-layer UNC path team settings file, while still allowing shared settings accross solutions.

  13. Lars Tabro says:

    We are in the exact same situation as Tim describes, with the need of a settings layer which loads applies for several solutions.

    The idea of automatically searching for dotSettings files from the solution-folder and backwards would enable us to store such a settings-file in version-control, thereby making it load automatically for all developers on the team.

    Is this feature logged as a feature request yet, or should i log one?

  14. Hadi Hariri says:

    @Tim, Lars,

    Will give feedback to team to see if viable somehow.


  15. hypersw says:

    Tim: a .sln.DotSettings file indeed references an injected settings file by a relative path. If both file are on source control, they should work together to whichever folder they’re checked out.

  16. hypersw says:

    Tim, Lars: I’ve put together a proof-of-concept R# plugin for settings files autodiscovery in solution’s parent folders.

    Have a look here:

    Though it might not be as interesting since relative paths in injected layers under solution-shared should also work.

    If the plugin appears to be of any use, similar functionality might be added into the core. Need more real-life input though, on which files to look for, which folders to consider, wouldn’t it be too slow, and so on. This feature was on the list of initially considered functionality, but we couldn’t decide on the behavior, and supposedly injected layers should be doing basically the same thing.

    Another feature was about getting company-wide (or AD-group-wide) defaults from Active Directory or Group Policy (or DNS records, or whatever). Any practical considerations here?

  17. Iain says:

    Having trouble getting this to work in R# 7.1.2 and am wondering if this is just me. Does anyone else have this working in later versions?

  18. Hadi Hariri says:

    @ Iain

    Can you please ping support with the issue? We can try and help via there.

  19. DaveBarrows says:

    Another thought along these lines; suppose your company or team or client has one set of naming conventions (e.g., private fields should be named with an underscore prefix (_somePrivateField is valid, but somePrivateField causes the blue squiggly line), and/or properties should be named camel case (e.g. ProductId is valid, but ProductID causes the blue squiggly line). But suppose you’re doing some programming exercise out of some book, which uses some different convention; as noted at the very top of this blog, the blue squiggly lines are annoying. Ideally you want some easy way (like right-clicking on the field or property with the blue squiggly line) to get some option to simply say, “for this solution ONLY, I want this to stop showing me the blue squiggly line, but I don’t want it to affect any other project or solution on my machine, because that would affect the behavior I want on actual production code that I’m working on, for some other solution.” Thanks for your consideration.

  20. Anthony Biagioli says:

    I have a project named AJB.Claim.Web.Mvc, so I followed these instructions to create a file AJB.Claim.Web.Mvc.csproj.DotSettings, but the new settings are not taking effect. (The project file is named AJB.Claim.Web.Mvc.csproj and is in the same folder.) Any suggestions as to what is going wrong?

  21. Bruno Juchli says:

    Hi Hadi
    It’s great that ReSharper features this. However, us too, we’re one of the bunch that want “per project type” settings. To get this working, i’ve been trying a few things. The most promising so far i could come up with was:
    -> Have the build script determine what type the project is of and then ensure that there the correct foo.csproj.DotSettings file is present

    To get this working in a usable manner, i still have some issues, questions. I thought you might be able to help me with this:

    -> When i change the *.csproj.DotSettings while VisualStudio is open, will ReSharper detect the change and apply it?
    —> When i add the *.csproj.DotSettings file while VisualStudio is open, will ReSharper detect the change and apply it?

    -> Is there some way of using “layering” for “linking” inside a *.csproj.DotSettings file?
    –> This way the project specific settings file could consist solely of a single “import” like “UnitTests.DotSettings” or “SpecificationTests.DotSettings”.
    –> I’ve created Solution layers with the resharper UI and then took the relevant parts from the sln.DotSettings file and moved them to a csproj.DotSettings file, but it didn’t seem to work (however there was error or exception message, too). But maybe i just did something wrong. I mean the format is not really intended to be edited manually… so it’s not unlikely.

    Thank you!
    Best Regards

    • Matt Ellis says:

      Hi Bruno. Any changes to a .dotSettings file are picked up when the file is changed, so any already open instances of ReSharper will be get the new settings immediately. Also, ReSharper will automatically pick up any new .csproj.dotSettings files when they’re added.

      While you can link to other .dotSettings files from .sln.dotSettings files (via the Add Layer right click option in the Manage Options dialog), adding linked files/layers isn’t supported for “hidden” files, such as per-project. I think you’ve pointed out a useful use-case for allowing this, so I’ve added a feature request, which you can vote for and track:

      Agreed – the file format isn’t really very user friendly. It’s not really intended to be edited directly. However, it helps to think of it as an XML file made up of a series of name/value pairs. The XML format only ever goes one level below the root element. The keys can look scary, because they’re hierarchical in nature, but are persisted as paths. This makes them long, and often difficult to read, especially when GUID based indexes are involved. But it’s still a single XML element, and the value is usually a simple text string. As long as you copy the whole element, you should be able to copy and paste from a sln.dotSettings file to a .csproj.dotSettings file just fine.

  22. Allon Guralnek says:

    This doesn’t appear to work at all in ReSharper 10.0.2.

  23. Tamas Molnar says:

    Is this going to be supported in the future? Would be a great and useful feature.

  24. Same here. It is not working in Resharper 10.0.2 :( Is there a way to overcome this? We really need different naming schema on tests and on production code.

  25. Mario De Schaepmeester says:

    “The UI will come”

    Well, seven years later, it hasn’t, and people are even complaining that the feature doesn’t work anymore altogether.

    Even more strikingly, the official documentation for the current version of R# links to this very blogpost.

    So how about it JetBrains :) ?

  26. Tom Auger says:

    Appears to be working in Resharper 2018.1.1.
    In addition to steps in the article I had to enable the following setting to make it work:
    Resharper > Options > Code Inspection > Settings
    Under ‘General’ check ‘Read settings from editorconfig and project settings’

Leave a Reply

Your email address will not be published. Required fields are marked *