Our team want to enforce styling rules in our C# project. I read somewhere some time that Microsoft said that ".editorconfig is the future" so we want to use this. NOTE: We don't want to use ReSharper.
C# has a lot of great rules that can be defined in editorconfig now, see Microsofts own editorconfig guide
We want to use this, and enforce that the rules set in the editor config is followed both when coding in Visual Studio and enforce that the code commited to git is following the rules.
When adding the .editorconfig rules, we get great linting on our files like this:
Running a fully enabled "Code Cleanup" in Visual Studio 2019 it completely formats our code as desired:
Question 1: How can we make the "Run Code Cleanup" run automatically on save/build? Even if we set certain rules as severity ":error" the compiler still don't complain about issues in C# files on build.
NOTE: I have tried the plugin for Visual Studio called Format document on Save but it does not follow all the rules set in the editorconfig (only a few, like fixing tabs/spaces and end of file newline)
We would also like to make sure that all commits to our git repository gets formated.
There is a tool called dotnet-format that is supposed to format the code according to the editorconfig rules.
We would like to add a pre-commit hook that runs the following 2 commands:
dotnet tool install -g dotnet-format
dotnet-format
This would work fine, but the issue is that dotnet-format also don't fix the issues in files with code giving severity ":error".
dotnet-format behaves the same way "Format document on Save" does, only fixing a few things like tabs/spaces and end of file newline.
EDIT: dotnet-format appearently only supports a few of the rules for now as per their Wiki
Question 2: How can we, from a command line, run a command behaving the same way as the "Code Cleanup" command in Visual Studio 2019 does?
I am able just to answer the your first question:
I have been looking for this and I found a extension called Code Cleanup on Save, you will just have to install it and configure it at Tool->Options->Code Clean up on Save, decide what of your profiles you want to set and that's all,
I hope it will help you!
Related
We have a VS solution, working with SVN as revision control. In our solution we use resharper rules to check code quality.
How can we know if the changes that we made create new violations of this rules? Do you know any automated way?
Do you have some Continuous Integration server like Jenkins or TFS? If not, set it up.
For ReSharper, there are CommandLine Tools available (you don't even need an extra license for them). You can call them with your automatic builds, e.g.
"C:\Program Files (x86)\JetBrains\CommandLineTools\InspectCode.exe" /o=Resharper.Result.xml /toolset=12.0 YourSolution.sln
and then publish its report.
Do not forget to check-in your .DotSettings file if you changed some rules!
I'm having trouble understanding a behaviour of Nuget. I've created a basic package that deploys a single Test.cs file into an "HtmlHelpers" folder in a project. I'm following the "convention based working directory" method described on the Nuget site.
The issue I'm having is Resharper file analysis isn't enabled for this file (the file doesn't compile currently, I've left off a semicolon):
But, if I rename the file from "Test.cs" to "Test2.cs" then Resharper analyses the file correctly showing the syntax error:
Has anyone got any idea what's happening here? Is there a list somewhere of Nuget-supplied source files that are then excluded from Resharper analysis? The file properties are the same as for any other C# file, set to Build Action "Compile" etc.
EDIT1
To answer questions from Stephen below, this is Resharper 8, I'm not currently on 9. I've tried closing and re-opening the solution and excluding and re-including the file, neither of which help.
Interestingly, with analysis working correctly on the renamed "Test2.cs", if I then rename it back to "Test.cs" the analysis switches off again :S
EDIT2
Just to add some more info to this, if you Nuget-deploy C# files using the .pp extension, Resharper analysis works correctly on the resulting .cs files. Go figure.
ReSharper excludes source code that has been delivered as part of a NuGet package from analysis - it treats it as third party code that you did not write and do not want to maintain. E.g. it won't show any inspection results for files such as jquery.js or angular.js - you don't own these, don't intend to maintain them as part of your project, and any changes you do make are likely to get overridden the next time you update the project. So, inspections are disabled for these files, but the files are still indexed to allow navigation.
Just in case anyone else has this issue it only happens if Nuget delivers a .cs file. If you get Nuget to deliver a .cs.pp file, Resharper correctly analyses the resulting .cs file in your solution.
I was new to Nuget when I started this work and it turns out I needed to make them .cs.pp files anyway in order to use the correct project namespace when importing. So the problem has gone away.
I have one solution file. When I running resharper code inspection in Visual Studio - there are no problems. When I run resharper code inspection with utility inspectcode.exe from command prompt on my local machine - everything is ok too. But when my build-machine copies files of my solution from tfs and runs resharper code analysis from command prompt - there are some problems: resharper doesn't look on some projects usages, and think that some properties can be made private - I get resharper inspection problems. How to understand why it happens?
By default, ReSharper Command Line Tools runs with SWEA (Solution Wide Error Analysis) enabled and "Property can be made private" suggestion is SWEA suggestion. You may disable SWEA on a build server by adding /no-swea key.
I am trying to work out if it is possible, when using a Custom Tool in Visual Studio, to have a change in the contents of one file, trigger the Custom Tool of another.
My scenario is this:
In a Visual Studio C# project, I have an "master.xsd" xml schema which includes several other other xsd files. I am using the Xsd2Code Visual Studio Custom Tool to generate a .cs from the schema. This works fine when the master.xsd itself changes, but I would like the custom tool to run on the file master.xsd when one of the other xsds changes.
Is there any way of one file triggering another's Custom Tool?
[EDIT - more detail on why I'm looking into using a custom tool for this]
At present we have a GenerateFiles.bat file that calls Xsd2Code from the command line to generate the code fiels from the schemas (as suggested by MattDavey below). This works, is just too slow.
The problem is that on every build Xsd2Code will, run but because lots of other projects depend on this project with the schemas, they will all recompile too even though probably nothing has changed. The practical upshot is that even a minor change to a unit test involves half the projects recompiling. This is why we've been looking at the custom tool approach to only generate the code files if the schema changes.
I use Xsd2Code a lot in this way, but my approach is to add a pre-build event which calls the Xsd2Code command line and regenerates the xml on each build..
My pre-build event looks like this:
$(ProjectDir)BuildTools\Xsd2Code.exe $(ProjectDir)Api\Schemas\MySchema.xsd MyProject.Api.Schemas $(ProjectDir)Api\Schemas\MySchema.cs /platform Net40 /collection Array /sc+ /ap+ /if- /xa+
In your case you could run this pre-build step only on the master xsd (which i'm guessing xsd:Imports the other schemas), or you could run the command on each of your schema files individually.
The advantage for this is that, if I change the XSD schema, I get very useful compile time errors :)
Hope that gives you some ideas!
EDIT
I spent some time thinking about the issue you highlighted regarding build time and modified the pre-build script like so:
$(ProjectDir)BuildTools\Xsd2Code.exe $(ProjectDir)Api\Schemas\MySchema.xsd MyProject.Api.Schemas $(ProjectDir)Api\Schemas\MySchema.cs.temp /platform Net40 /collection Array /sc+ /ap+ /if- /xa+
fc $(ProjectDir)Api\Schemas\MySchema.cs $(ProjectDir)Api\Schemas\MySchema.cs.temp
if errorlevel 1 copy $(ProjectDir)Api\Schemas\MySchema.cs.temp $(ProjectDir)Api\Schemas\MySchema.cs /Y
del $(ProjectDir)Api\Schemas\MySchema.cs.temp
So Xsd2Code is now generating the source code into a temporary file, which is only overwriting the existing .cs file if it is different. This should mean that if the .xsd hasn't changed at all, neither will the generated .cs :)
You're still taking the hit of running xsd2code, but you're not taking the hit of msbuild rebuilding an entire chain of projects if the generated source was the same..
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.