How to get rid of Naming rule violation messages in Visual Studio?

Question

I just installed Visual Studio 2017. When I open an existing website, I get all sorts of warning messages such as this one:

IDE1006 Naming rule violation: These words must begin with upper case characters: swe_calc

In the code it is defined as:

[System.Runtime.InteropServices.DllImport("swedll32.dll")]
public static extern Int32 swe_calc(double tjd, int ipl, Int32 iflag, IntPtr xx, IntPtr serr);

This also occurs with my ASP.Net controls. As an example of a DropDownList:

IDE1006 Naming rule violation: These words must begin with upper case characters: ddlMonth_SelectedIndexChanged

How can I eliminate these type of warnings under Visual Studio?

Solution 1

Its a new configurable feature, if you go to

Tools → Options → Text Editor → Your language (I did C#) → Code Style → Naming

In there I went to Manage Styles add camel Case (its in there but you need to add it to your selectable): go to the "+" sign, then add your rule accordingly.

Important: Close your solution and re-open it for changes to take effect.

For example, I only use camel Case for private methods. So I choose Private Method and required Style the new one I created "camel Case" and set it to Severity Suggestion (I also promoted it to the top).

The built in are all "Suggestions" too so you can also just turn off Messages.

Solution 2

If you want to suppress it only in some files or areas you can use the following:

#pragma warning disable IDE1006

// the code with the warning

#pragma warning restore IDE1006

Solution 3

If you need to get rid of these messages you could also just suppress them.

Solution 4

You could rename the method and add the name to the attribute with the EntryPoint property.

[System.Runtime.InteropServices.DllImport("swedll32.dll", EntryPoint = "swe_calc")]
public static extern Int32 SweCalc(double tjd, int ipl, Int32 iflag, IntPtr xx, IntPtr serr);

Solution 5

This can be done using normal VS2017 & VS2019 using the .editorconfig settings file, using the naming rules: https://docs.microsoft.com/en-us/visualstudio/ide/editorconfig-code-style-settings-reference

The file can be created by hand, or in VS2019 you can get Visual Studio to create it for your from your preferences (i.e. after following configuring your prefs as in https://stackoverflow.com/a/41131563/131701 ), by hitting the generate editor config file from settings button.

For example, the following sets of rules will enable camelCase for all non public methods, and keep the other default naming rules that comes with VS.

#### Naming styles ####

# Naming rules

dotnet_naming_rule.interface_should_be_begins_with_i.severity = suggestion
dotnet_naming_rule.interface_should_be_begins_with_i.symbols = interface
dotnet_naming_rule.interface_should_be_begins_with_i.style = begins_with_i

dotnet_naming_rule.types_should_be_pascal_case.severity = suggestion
dotnet_naming_rule.types_should_be_pascal_case.symbols = types
dotnet_naming_rule.types_should_be_pascal_case.style = pascal_case

dotnet_naming_rule.private_method_should_be_camelcasestyle.severity = suggestion
dotnet_naming_rule.private_method_should_be_camelcasestyle.symbols = private_method
dotnet_naming_rule.private_method_should_be_camelcasestyle.style = camelcasestyle

dotnet_naming_rule.non_field_members_should_be_pascal_case.severity = suggestion
dotnet_naming_rule.non_field_members_should_be_pascal_case.symbols = non_field_members
dotnet_naming_rule.non_field_members_should_be_pascal_case.style = pascal_case

# Symbol specifications

dotnet_naming_symbols.interface.applicable_kinds = interface
dotnet_naming_symbols.interface.applicable_accessibilities = public, internal, private, protected, protected_internal
dotnet_naming_symbols.interface.required_modifiers = 

dotnet_naming_symbols.private_method.applicable_kinds = method
dotnet_naming_symbols.private_method.applicable_accessibilities = private, protected, internal, protected_internal
dotnet_naming_symbols.private_method.required_modifiers = 

dotnet_naming_symbols.types.applicable_kinds = class, struct, interface, enum
dotnet_naming_symbols.types.applicable_accessibilities = public, internal, private, protected, protected_internal
dotnet_naming_symbols.types.required_modifiers = 

dotnet_naming_symbols.non_field_members.applicable_kinds = property, event, method
dotnet_naming_symbols.non_field_members.applicable_accessibilities = public, internal, private, protected, protected_internal
dotnet_naming_symbols.non_field_members.required_modifiers = 

# Naming styles

dotnet_naming_style.pascal_case.required_prefix = 
dotnet_naming_style.pascal_case.required_suffix = 
dotnet_naming_style.pascal_case.word_separator = 
dotnet_naming_style.pascal_case.capitalization = pascal_case

dotnet_naming_style.begins_with_i.required_prefix = I
dotnet_naming_style.begins_with_i.required_suffix = 
dotnet_naming_style.begins_with_i.word_separator = 
dotnet_naming_style.begins_with_i.capitalization = pascal_case

dotnet_naming_style.camelcasestyle.required_prefix = 
dotnet_naming_style.camelcasestyle.required_suffix = 
dotnet_naming_style.camelcasestyle.word_separator = 
dotnet_naming_style.camelcasestyle.capitalization = camel_case

View more solutions

Comments

[user2507101]

Definitely file this feedback to VS. 2017 is a new version with new features, and sometimes these can start off too aggressive. Your feedback will help adjust the default behavior.

[TaW]

Sounds like a bug. This is not just about old projects but also about new ones, created in VS2017rc. VS creates the control names it then flags as offensive..

[paulsm4]

I encountered this 1006 error with an MSVS-generated button click handler,"btnList_Click()". In other words, MSVS2017 is complaining about a method it created itself! It's suddenly complaining about a naming convention that's been around since .Net 1.0! Sigh.. IDEAL SOLUTION: #pragma warning disable IDE1006. This has the benefit that, since it's in the source code, it's automatically project-wide (you don't have to synchronize any per-workstation MSVS settings).

[SteveFerg]

I also have a drop down box that gives the same error: 'ddlMonth_SelectedIndexChanged'. Do all my asp.net controls also have to be renamed?

[Daniel A. White]

@SteveFerg thats up to you - its just a warning.

[SteveFerg]

I figured as much. I was just wondering if there is an option somewhere to turn them off other than "unclicking" the Messages box in the Error List.

[Matthew Watson]

That's exactly the same naming convention that we use for private methods - thanks! Now I just need to work out how to enable this for everyone without people having to individually set this option....

[Daren]

A quick way to get to these options is to Click the "Quick Actions" light bulb, hover over "Fix Name Violation" and click the "Change Style Options" button.

[RosieC]

Yes, didn't think it had worked initially but close and re-open and it looks to have worked. We also use camel case for private methods.

[Thaoden]

Rebuilding the solution seems to be enough for the new rule to take effect.

[Paulustrious]

I just deleted the rules

[Christopher Bonitz]

In my case I wan't to actually follow this naming rule, but have data models that does not, and for simplicity and compatibility it makes sense not to fix them. So I have it to none instead of suggestion, as this is actually what I wan't to do, but can't be bothered to be prompted about... Just wish It could be set for the project, not for Visual Studio.

[kmote]

To share such setting/rules/styles with an entire team, refer to this: stackoverflow.com/questions/11684457/…

[jrh]

To emphasize what @kmote is saying with their comment, any changes you make in here will NOT go with the solution / project, if you set this then open the solution on a different computer you will get the "suggestions" back again, and other devs on your team will still see them, too (which could cause inconsistencies or unneeded changes in commits if somebody clicks "fix now" accidentally). I don't understand why Microsoft decided to add yet another configuration file. Couldn't they have put naming convention rules in the .ruleset file, or the csproj file?

[paulsm4]

This is probably the "ideal" solution! It resolves the problem for the entire team.

[TylerH]

What's the difference between Suppressing them 'In Source' vs 'In Suppression File'?

[MistaGoustan]

@TylerH "In Source" is the file in which the warning is being thrown. "In Suppression File" is a generated file to store all of your warnings.

[obe]

"Close your solution and re-open it for changes to take effect." - not knowing this wasted some minutes for me. Why on earth doesn't VS pop up some message to tell us that?? Especially since this is so inconsistent with how other option changes take effect...

[gpresland]

The entire Naming feature appears to be bugged and not functional in the Visual Studio 2019 release.

[qwlice]

42 is not the Answer anymore. This is the Answer!

[David Lechner]

In the future, this rule will be ignored for extern methods by default. github.com/dotnet/roslyn/pull/51728

[Dov Miller]

I did as you suggested and did not get results!

[diox8tony]

I believe this is bugged in VS 2017 community also. I have deleted all my naming conventions, restarted, rebuilt. nothing makes them go away. They were also set to "I"(suggestion) from the beginning(defaults) however they are showing up as errors. Even Alt+enter takes me to a blank rules set (the rules I deleted) however still shows me the error.

[Stefano Fenu]

See also this: stackoverflow.com/questions/11684457/…. Basically, you can add this file to source control so that any other developer in your team uses these settings seamlessly.