I'm converting my project to .NET 6 and I want to use filescoped namespaces everywhere. But the conversion tool exists only in the editor.
Has anyone found out if there's a way to run this editor function across all files in solution at once? (Looks like Rider has that function)
Adding a rule to use file scoped namespaces in .editorconfig worked for me:
create an .editorconfig file in the solution directory
add following line/content below (docs, code - IDE0161)
Example .editorconfig file content:
[*.cs]
csharp_style_namespace_declarations = file_scoped:warning
After that the preview changes dialog had an option to apply the fix to the whole project/solution:
I always have problems finding files that are supposed to be updated (.editorconfig in this case). I don't even know if I should search for it in the project's, Visual Studio installation's or any folder on the PC. So I like the answer in the link below because it says where in the interface to change the setting.
Best answer in my opinion is here:
https://www.ilkayilknur.com/how-to-convert-block-scoped-namespacees-to-file-scoped-namespaces
It says that you can change the code-style preference (and enable the display of the option to apply this preference in a document / project / solution) by going to Tools => Options => Text Editor => C#=> Code Style and then changing the related preference.
EditorConfig syntax
csharp_style_namespace_declarations = file_scoped:error
dotnet_diagnostic.IDE0161.severity = error
Note
Syntax option = rule:severity will be deprecated, sooner or later.
I strongly recommend to read this article before you start build .editorconfig for your project.
After you have configured the .editorconfig, you can configure a 'Code Cleanup' setting to automatically convert all files to use file-scoped namespace. Go to Tools -> Options -> Text Editor -> Code Cleanup -> Configure Code Cleanup. Then add the 'Apply namespace preferences'. Then go to Analyze -> Code Cleanup (or just search for 'Code cleanup') and run the Code Cleanup to automatically change the namespaces to file-scoped.
Related
I am trying to create a single place for code-style and formatting rules for our solution.
We are currently using Resharper, which stores this info in the {slnName}.dotSettings file. However, some developers don't want to use Resharper due to its performance issues. So they don't get these rules and warnings.
EditorConfig seemed like a suitable replacement, but I wanted to translate the ReSharper rules (where possible) into editor config rules and also include all the ReSharper specific rules so that those who do use ReSharper get the extra rules too, and they are all stored in one place (One source of truth!).
Anyway, trying to grasp what the .dotSettings file is doing has been unfruitful, and I know that Resharper will read in editor config files, so I'd like it to export it too
With Resharper 2019.1 you can now 'Export settings to .editorconfig'. The option lives in Resharper -> Tools.
This will export the standard editor config options, the Visual Studio specific config options and the resharper specific configs. Very useful!
In Reshaper 2019.3, this option is found in "Resharper Options | Code Editing | General Formatter Style"
As described here -> https://blog.jetbrains.com/dotnet/2019/03/28/export-editorconfig-code-style-optimize-references-sdk-projects-resharper-2019-1-eap-updates/
Visual Studio 2017 shows a hint for unnecessary this qualifiers even when the inspection is disabled in the options.
This is how it looks:
(First line is the culprit, second line is how I want this to always look like.)
Hovering over the grayed out this and clicking on the light bulb shows this suggested fix:
I can't find a way of disabling this completely. Sometimes I want to have "unnecessary" this qualifiers and sometimes I don't, so I don't want VS to comment about this at all.
"None" is the least severe option yet it still shows this annoying, different color.
Is there any possibility of complete disabling this inspection?
You can use a ruleset file to disable any analysis if you know its diagnostic id (in this case 'IDE0003')
On the References node of you project right click on Analyzers and select Open Active Rule Set
Once the ruleset editor is open just search for IDE0003 and uncheck the checkbox. Then save the ruleset file. Then save the project.
The following XML will be added to you project file. You can add this ruleset file to any project where you want this rule disabled.
<CodeAnalysisRuleSet>ConsoleApp9.ruleset</CodeAnalysisRuleSet>
Looks like the current process is more complicated for .NET Core and .NET Standard projects.
From MS VS Docs:
If you have a .NET Core or .NET Standard project, the process is a little different because there's no Code Analysis property tab. Follow the steps to copy a predefined rule set to your project and set it as the active rule set. After you've copied over a rule set, you can edit it in the Visual Studio rule set editor by opening it from Solution Explorer. [emphasis mine]
Taking the first link in that quote will eventually take you, after a little sleuthing, to Code style rule options, that finally tells you how to add the file:
In Visual Studio, you can generate this file and save it to a project at Tools > Options > Text Editor > [C# or Basic] > Code Style > General. Then, click the Generate .editorconfig file from settings button.
NOTE: This produces a tiny warning just under your toolbars that an .editorconfig has been added to your solution. Select the "Yes" button to include it in your solution.
And now you can open and edit your new .editorconfig file.
Looks like this is the "offending" section:
# this. and Me. preferences
dotnet_style_qualification_for_event = false:suggestion
dotnet_style_qualification_for_field = false:silent
dotnet_style_qualification_for_method = true:suggestion
dotnet_style_qualification_for_property = false:suggestion
If that dotnet_style_qualification_for_property is changed to = true:suggestion (explanation here), I think you're golden [at least for properties, of course -- make edits as appropriate].
Seems ANTLR support C# language but I dont know how I can generate related class.
I searched and saw exists an Extention for Visual Studio but I does not support 2015
so How I can generate Lexer and Parser for C# with ANTLR manually ?
The VS extension mainly serves for syntax highlighting and editor niceties. It's quite useful but you can still live without it (IIRC a change in VS2015 prevents a compatible release).
What you should do is use the Antlr4 NuGet package, which will automate the generation of parsers. It will run ANTLR at compile-time.
If you do have the VS extension (in VS2013 for instance), just add a new ANTLR grammar file to your project and you're done.
But if you don't have the extension, you'll have to set up the project manually. Here are the steps to make it work:
Install the NuGet package:
Add a new text file to the project, name it with a .g4 extension
Save, and then unload the project from the project's context menu in the solution explorer:
Reload it:
Select your .g4 file in the solution explorer, go to the Properties window, and set the Build Action to Antlr4:
Edit your file, for instance:
grammar MyLanguage;
compileUnit: 'Hello' EOF;
Go to File -> Advanced Save Options and choose UTF8 without signature or the ISO-8859-1 encoding (ANTLR just doesn't handle UTF8 with BOM):
Build your project, your new classes will be available
You can now write some code:
var lexer = new MyLanguageLexer(new AntlrInputStream("Hello"));
No need for integration with visual studio.
Download the jar file here: http://www.antlr.org/download/antlr-runtime-4.5.1.jar
Save it to C:\Test
Add the jar to your classpath:
Using System Properties dialog > Environment variables > Create or append to CLASSPATH variable
In the variable, put C:\Test\antlr-runtime-4.5.1.jar If values already exist for this variable, insert a ; before your new entry
Copy in your grammar file to C:\Test
Go to the command line, navigate to C:\Test
Create your 'outputdirectory' folder, and run this (remember to replace {outputdirectory} and {input}:
java org.antlr.v4.Tool -o -visitor -no-listener -Werror -o {outputdirectory} -Dlanguage=CSharp {input}.g4
I am building a C# adding for Excel. In order to debug it, I need to launch Excel.exe with a command line argument containing the Debug or Release path to the addin.
For example:
Start External Program: C:\Program Files\Microsoft Office\Office15\EXCEL.EXE
Command line argument "C:\Dev\Project1\Project1\bin\Debug\Project1-AddIn64.xll"
However, I would like to replace "C:\Dev\Project1\Project1\bin\Debug" with an equivalent of $(SolutionDir) for C++ projects in VS. Is there a way to do this ? If it is not doable, is there a way to get around this ?
EDIT: please support me and get this added in VS by voting up the following idea: http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/6350738-support-for-macros-in-debugging-command-line-argum
Indeed, the macros cannot be used in the Start Options | Command line arguments
I see two solutions:
As the current folder is set to the $(TargetDir) when you Start an application you could refer to the solution folder like this: ..\..\..\ if the External program accepts a relative path. (I am not quite sure why you would ever want to refer to the solution folder, referring to the output/target folder makes more sense to me)
In the Post Build event (unregister) and register the component the way the component should be registered when deploying it (a proper setup). This way you only have to refer to Excel in the Start Action. This also immediately adds the benefit of testing a scenario that is more similar to production.
It's not exactly a fix, but this may help some people. If you create your project from the project template "Visual C#/.NET Core/Console App" instead of "Visual C#/Windows/Console App", this feature is supported. When I put "$(SolutionDir)" in the Application Arguments field on the Debug tab of the Project Properties window, it is expanded at run time. Note that you will need Visual Studio 2015 Update 3 or later.
I guess you could make use of post-build event to read in your file. #HansPassant explained it in VS2010 - Project Macro Variables in Start Options Command Line Arguments.
A short quote:
A possible workaround is a post-build event that writes a file that you read in your program. Like echo $(ProjectName) > "$(TargetDir)cmdargs.txt
You could substitute cmdargs.txt to appropriate file you want.
You CAN use the macros in the Command fields. I used procmon.exe to see what VS was looking for and indeed i could use $(SolutionDir)\..\Debug\thetoolname.exe as my solution was not in the root.
Im using VS2019 so AFAIK it is supported from this version but it most likely is supported in lower versions. Just use procmon to check the path that VS is attempting to resolve.
I have a C# solution with an Antlr3 grammar file, and I'm trying to upgrade to Anltr4. It turns out the grammar was the easy part (it became better, and one third the size!). Generating the parser turned out to be the tricky part.
In the old solution I merely ran AntlrWorks to update the lexer and parser .cs files when the grammar file changed. The lexer and parser were included directly in the same project as the grammar so the framework around the parser could make use of them directly.
With the Antlr4 targets for C# I noticed that (at least by default) the output path of the generated Parser C# classes is in the intermediate directory, e.g. obj\Debug. This means I can't use the parser directly in the same project. Am I supposed to change the output path if I want the generated source usable in my sln? Don't I want it in my sln?
I tried making a separate project for the parser generation, that is, a project containing only the grammar file. When this project is built using the Antlr4 targets, the resulting assembly can be referenced from projects needing the parser classes. However, if this project is included in the solution I still don't get any intellisense in visual studio since it bases its intellisense on source files for loaded projects, so it is still not quite usable. The only way I could get it working properly was to build then unload the parser project, and have other projects reference it as an assembly file rather than a project.
EDIT:
After looking on the antlr-interest list I found this thread indicating that the problem with intellisense may be Resharpers fault. If this is the case, then my question is rather how to keep using both Antlr4 and Resharper in my solution?
https://groups.google.com/forum/#!topic/antlr-discussion/QSuJXphaBDg
I found an extension for Resharper: ReSharper.ExternalCode.
Tip for Antlr: add obj\Debug in Resharper -> Code Inspection -> External Code and reload solution.
It's works for me.
There is an easy way to get the best of both Antlr 4 and Visual Studio. You are on the right track in having a separate grammar project and implementation project, but you are missing a couple steps.
Follow these steps to get the Intellisense working
In Visual Studio, go to Tools -> Extensions and Updates and search the Online section for "ANTLR Language Support" by Sam Harwell.
This does a few things:
Adds Templates for the combined grammars.
Adds Syntax Highlighting
Adds an MSBuild target for the grammar to generate the parser.
In your solution, set up your project structure like this:
Solution
Grammar Project
ANTLR 4 Combined Grammar
Implementation Project
Folder for Links to Generated files
Listener Implementation Class
Write and Compile your grammar.
In your folder for the Links to Generated Files, Right-Click the folder and click Add -> Existing Item
Browse to Grammar Project\obj\Debug and select all the generated parser files.
This next step is important. On the Add button there is a little drop-down arrow. Click the drop-down arrow and click "Add As Link".
This will add the generated files to the implementation project using a symbolic link instead of a direct copy.
This gives the added benefit of not having to remove and re-add the parser files if you have to change your grammar later.
Intellisense should work now for your generated parser classes, and you don't
even have to disable ReSharper.
You are encountering a known bug with ReSharper. The ANTLR 3 and ANTLR 4 C# build integration is reliable, and uses long-established patterns that Microsoft uses with other languages and code generation tasks. Your options are:
Stop using ReSharper
Get the ReSharper authors to address the lack of support for this feature, or
Modify the ANTLR 4 target to work around the limitation in ReSharper, which will introduce other problems into the build which may or may not be acceptable for your use.
Option 1 is certainly the least expensive, and most likely to provide reliable long-term support for your projects.