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

image

and in my test project I use all_lowercase

image

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

image

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

image

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

image

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

image

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

image

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

image

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

image

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 ReSharper Tips&Tricks and tagged , , , . Bookmark the permalink.

20 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:

    @Tim,

    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:

    http://atombrenner.blogspot.com/2010/07/how-to-change-resharper-naming-style.html

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

  5. Hadi Hariri says:

    @Tony

    Yep. That works too!

  6. Tony Hunt says:

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

  7. Tim Herby says:

    @Hadi,
    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:

    /Root
    /Root/Solution1/Solution1.sln
    /Root/Solution2/Solution2.sln

    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?

    Thanks!

  8. Serg says:

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

  9. Hadi Hariri says:

    @Tim,

    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.

    @Hadi
    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.

    Thanks.

  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: http://reshsettingsdiscover.codeplex.com/

    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?

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>