I've seen answers showing how to suppress a warning for a specific line of code or for a specific project. I don't want that.
I want to suppress a specific warning for all of my projects.
(If it matters, the warning is IDE0044. And I'm using C#.)
A recent update to Visual Studio 2017 (15.7.1) has an option for this now. Under the Tools->Options menu, select the TextEditor->C#->Code Style->General tab. Under Field preferences, there is a Prefer readonly option. Set that to No.
There is also an editorconfig setting you can set if you want to check this preference in along side your code, so others who consume your code don't get the warning, but that has to be done on a per solution basis. The editorconfig value you would set would be:
dotnet_style_readonly_field = false:none
You can use the SuppressMessage attribute present under System.Diagnostics.CodeAnalysis namespace like
[SuppressMessage("Microsoft.Usage", "CA1801:ReviewUnusedParameters", MessageId = "args")]
Well as you have edited saying I want to suppress a specific warning for all of my projects
You can't do that for a entire project wise AFAIK. But check the linked post once if that helps
How to suppress code analysis messages for all type members?
To suppress warnings for all projects, you need to create a .editorconfig file in a top-level directory. For example, I have mine in trunk and I commit it to source control so that my colleagues share the same settings.
The settings in this file apply to all projects in trunk and subfolders, unless overridden by another .editorconfig file further down the folder tree e.g. you might you have a project specific EditorConfig file in a subfolder which has different settings. See File hierarchy and precedence for more details.
Creating an EditorConfig file
You can use a text editor for this if you just want to change one specific setting. However, Visual Studio can create a .editorconfig file with sensible defaults for .NET for you. From MSDN:
Create a new project
From the menu bar, choose Project > Add New Item; or press Ctrl+Shift+A
Select the editorconfig File (.NET) template to add an EditorConfig file prepopulated with default .NET code style, formatting, and naming conventions
Optionally delete the project - we don't really need it
Visual Studio 2019 - Creating an EditorConfig file from current settings
In Visual Studio 2019, you can instead create an EditorConfig file from your current settings. Just click the following button in the Options dialog under Text Editor > C# > Code Style > General:
If you're creating in a text editor you'll probably need this at the top of the file, adjusted as necessary:
# Remove the line below if you want to inherit .editorconfig settings from higher directories
root = true
# C# files
[*.cs]
Disabling IDE0044 in the editor config file
To disable IDE0044 specifically, add or change the following setting in the .editorconfig file:
dotnet_style_readonly_field = false:none
(In Visual Studio 2019, you can set the Prefer readonly option to No under TextEditor-> C# -> Code Style-> General in Options and then press the Generate .editorconfig file from settings button as detailed above).
You may try to use Directory.Build.props adding NoWarn property for specific warnings. I haven't verified it though.
And as it's said in another answer, it's better to fix the root cause instead of ignoring it.
I would like to add to Stephen's post that his solution with the .editorconfig file didn't work out for me without specifying the files I want to apply the rule to. For example, and given that I want to apply a rule to all the test files and that I follow a naming convention in which these end up with "Tests.cs", I have managed to ignore the CA1707 rule in those files by using the following rule:
[*Tests.cs]
dotnet_diagnostics.CA1707.severity = none
More information on my answer here
IDE0044 is "add readonly modifier" so why not just add the modifier?
Warnings are telling you that you're doing something wrong, but the app will compile.
It's best to have zero warnings in an ideal world.
Related
The Problem
I am trying to create an .editorconfig file using Rider. I want to be able to change all settings in the .editorconfig later on with Rider aswell. But it does not seem to be possible to edit the naming rules, after exporting them initially.
What I am trying to do
Initially, I configure the coding style how I want it to be.
And then export the coding style into a new .editorconfig file.
Creating and exporting the .editorconfig works fine. The exported .editorconfig also contains the configured naming rules.
But when I use Edit .editorconfig in Rider.
There is no Naming tab anymore.
Things I already tried
ReSharper
I tried editing the .editorconfig using ReSharper, where the Naming tab is missing aswell.
Re-exporting
I tried changing the coding style in Rider by just overwriting the .editorconfig that already exists, but doing so seems to be broken (or I am using something incorrectly, please tell me) as it creates "copies" of existing parts of the editorconfig. The picture shows the resulting .editorconfig after overwriting it. The new lines are "duplicates" of the lines above them. Overwriting multiple times creates more entries with increasing suffix numbers.
What I am asking for
I'd love to hear someone just tell me that I am using something incorrectly and Rider actually has a feature that allows changing the Naming Style of an .editorconfig after creating it.
Alernatively any suggestions for a tool that can create and edit C# naming conventions conveniently in an .editorconfig would be great.
Someone on our team installed StyleCop and since then all of the projects he loaded up and committed to source control refuse to load unless stylecop is installed.
I know I can manually edit the .csproj files to get rid of it, but is there an easy way to automatically remove these stylecop parts from the project files so they can be loaded and built on a non-stylecop-infected Visual Studio machine?
Why remove it?
In my opinion using StyleCop is a good thing.
Your only problem seems to be that your team member didn't set up StyleCop properly.
From your description, I guess that he wanted to set up StyleCop with MSBuild integration:
http://blogs.msdn.com/b/sourceanalysis/archive/2008/05/24/source-analysis-msbuild-integration.aspx
He apparently just left out the last paragraph "Team Development": copy the StyleCop files into your project and check them into source control, so you don't need to install StyleCop on every single developer machine. (see my link for a more detailed description)
If you do this, StyleCop should work on every machine, no matter if it's installed or not.
We are using StyleCop in this way as well, and I think it's the easiest way to use it.
I just had to insert two lines into each .csproj file and check a few files into source control once...and StyleCop just works, on every compile, on every machine (no matter if it's on a developer machine or the build server).
Stylecop hides real warnings. Its a vanity exercise and its evil.
Do not use it.
I find that stylecop generates many many trivial warnings that drown out the real warnings. By all means use these tools but don't force them to be on. Having no stylecop warnings is a meaningless metric.
I disabled StyleCop by adding the following GlobalSettings configuration to the file settings.stylecop in the solution root.
<StyleCopSettings Version="4.3">
<GlobalSettings>
<BooleanProperty Name="RulesEnabledByDefault">False</BooleanProperty>
</GlobalSettings>
...
</StyleCopSettings>
TEST DRIVEN DEVELOPMENT
Red -> Green -> Refactor
TEST DRIVEN DEVELOPMENT (WITH STYLECOP)
Red -> Red -> WTF? -> Red -> Red -> ...
Also, from here:
Bob: Using pattern matching, the software identifies ugly code
Charlie: —and fixes it!
Bob: No. It prints a message about each transgression.
Charlie: And then the user right-clicks to fix them all?
Bob: No. The message scolds them 'invalid spacing around the comma'.
Charlie: And then explains how the user can fix it?
Bob: No, that information is in a separate document.
Charlie: On Google?
Bob: No.
This is why don't use Stylecop.
I have a Silverlight project with a generated Reference.cs file where the service reference is in. The class is attributed with [GeneratedCode] and in the project configuration the code analysis on generated code is disabled (Release and Debug).
What have I done wrong?
Maybe you should try the solutions that work for StyleCop:
Put ".Designer.cs" to the end of the name of the file you don’t want StyleCop to check. Or call the the [sic] class, and the file containing it, "NativeMethods". Make sure you also uncheck "Analyze designer files" in StyleCop settings. In this case the whole file will be bypassed. You don’t have to do so for some types of Microsoft designer-generated code, like Windows Forms Designer, because they automatically fall under conditions of the following option:
Surround the undesired piece of code with a C# region containing "generated code" in its name. StyleCop does not check generated code by default (make sure the "Analyze generated files" setting is not checked, though). In this case you can still validate the names of the fields generated for the Windows Forms controls.
#region Windows Form Designer generated code
...
#endregion
To ignore the whole generated file, check whether your generator puts an "<auto-generated />" XML element into the StyleCop-conform file header, like the following:
// <auto-generated />
And finally, you can set to true the "ExcludeFromSourceAnalysis" property of the MSBuild Compile item that represents the file needed to be excluded from analysis. It only works if you use the provided "Microsoft.SourceAnalysis.Targets" targets file, otherwise you have to feed the StyleCop MSBuild task with desired source files on your own.
Source: https://shishkin.wordpress.com/2008/07/08/stylecop-how-to-ignore-generated-code/
I was wondering if there is a way to copy ALL my settings from ReSharper (including the StyleCop for ReSharper settings and the keyboard bindings I have set for ReSharper) from one PC to another?
Since the export option within Resharper is only for code styles, you'll need to be a bit craftier for all settings.
From Peter Ritchie's blog...
...the settings are stored in
"%userprofile%\application
data\jetbrains\resharper\v4.0\vs9.0".
There are a couple of xml files in
there that store your settings.
Before you upgrade to the latest
build, just copy those to another
directory.
It's very likely that the format of
these files has changed since the last
build so copying the backups over the
new version could possibly make
Resharper to blow-up. So, use with
caution.
I have Resharper 4.1 so instead of "...\v4.0\vs9.0" it's actually "...\v4.1\vs9.0" (obvious, I know, but worth mentioning).
I'm not sure about StyleCop settings, but this should work for most other settings (keyboard scheme, code completion settings, etc...).
There is a R# settings manager plugin for resharper that stores all of this I think, including stylecop settings
Open Visual Studio
Go to Resharper > Manage Options
Click on Import and Export
Click on Export to File
Tick all check box
Click on OK and save the file to your desired location
To import the settings to other computer, repeat steps 1-3 and then select Import from File. You are done.
Enjoy!
You can Export/Import your ReSharper Code Style or put it on the network and share between multiple computers. To do so:
From VS Menu select ReSharper -> Options then in Option dialog select Languages/Common/Code Style Sharing.
Not sure if it's exactly what you're looking for.
StyleCop settings are not stored in the resharper plugin. they are in the stylecop directory and in an xml file (Settings.StyleCop).
I have a solution that i am using!
Skydrive and junction link magic.
I create a junction in the filesystem that point the settings to a skydrive folder.
this way i have everywhere i use skydrive the same settings!!!
On the target pc i do the opposite.
Hope this helps.
Steve Dignan's answer is probably correct for 2009 version of Resharper.
In newer versions of Resharper global for PC Resharper settings are located in:
%userprofile%\Appdata\Roaming\JetBrains\Shared\vAny\GlobalSettingsStorage.DotSettings.
Solution team-shared settings are in the solution folder called {Solution Name}.sln.DotSettings.
Solution's personal settings are in {Solution Name}.sln.DotSettings.user.
Source: https://resharper-support.jetbrains.com/hc/en-us/articles/115001216530-Where-to-find-DotSettings-files-associated-with-settings-layers
So to transfer settings between 2 PCs, copy settings file(s) for the appropriate layer(s) you want to transfer and that's it. Usually just copying global is enough.
When building a C# application with Visual Studio 2008, is it possible to set a different output filename per configuration?
e.g.
MyApp_Debug.exe
MyApp_Release.exe
I tried a post-build step to rename the file by appending the current configuration, but that seems a scrappy approach. Plus it meant that Visual Studio could no longer find the file when pressing F5 to start debugging.
You can achieve this by editing your project file by hand. Locate the <AssemblyName> node and add a conditional attribute to it:
<AssemblyName Condition="'$(Configuration)'=='Debug'">MyApp_Debug.exe</AssemblyName>
<AssemblyName Condition="'$(Configuration)'=='Release'">MyApp_Release.exe</AssemblyName>
You'll have to duplicate it also to add another conditional attribute for the release version.
Whilst it is possible, it may cause problems. There is an AssemblyConfiguration attribute that can be applied to your assembly. In AssemblyInfo.cs, put:
#if DEBUG
[assembly: AssemblyConfiguration("Debug")]
#else
[assembly: AssemblyConfiguration("Release")]
#endif
This will add a property to your compiled assembly that will tell you which build configuration your application was built using.
As adrianbanks mentioned, you can edit your .csproj file by hand to accomplish this.
I would, however reccomend the simpler form of:
<AssemblyName>MyApp_$(Configuration).exe</AssemblyName>
If you ever edit the properties of this project however, this change will very likely be lost. It's something you will have to manually stay on top of, as it's not going to be a supported setup.
To manually edit your project definition, right click the project in Visual Studio, and select "Unload", then right click the unloaded project, and select "Edit" and it will open the XML definition for you.
I'm sure there is, however in my experience having different filenames for debug / release configurations is a bad idea as it can cause all sorts of problems (very much like the issue VS has when it tries to execute the renamed app)
Why not simply indicate whether or not its debug / release in the Assembly attributes (for example in the comments)