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!
Related
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!
I have a C# application, a VS2017 solution with 7 projects.
Is it possible to lock a *.cs file or a project in order to avoid me to do undesired modification?
Your best bet is source control. Using systems like TFS, Git, or Subversion, you can track changes, see who has changed what, roll back to previous states, and in some cases, mark files as read-only. Without source control, marking a file in the file system as read-only is your only real option.
A server is not required for source control. While some solutions do require one, Git and SVN can be entirely local.
In a current project, I use lots of nuget packages for all kinds of purposes (Nancy, Unity, Razor..) and they all generate a lot of noise in the application output directory, even on release configuration. How can I prevent those from doing so?
*.pdb debug databases
*.xml documentation files
*.unnecessary locale resources (I have like 20 folders in my output directory for every goddarn langauge..)
Check configuration manager for your "release" build and see if all your projects are actually set to release. If they are, check each projects properties, on the build tab see what constants are defined (not sure if this would affect things or not), click the advanced button, see what the debug info is there.
If you really want to get rid of those things (after all, they are there for a reason) I'd suggest defining post build events in your project properties to have them deleted by Visual Studio once your project has been built successfully.
Make sure to use the appropriate macros to target the correct directories. Also, uncheck the creation of DEBUG and TRACE constants and XML documentation to suppress the creation of *.pdb and *.xml files for your own project.
MSDN on build events
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'm using TortoiseSVN and Visual Studio 2008.
Is there any way to update my project's assemblyinfo.cs with svn's version in every build?
For example, 1.0.0.[svn's version] -> 1.0.0.12
You could use the SubWCRev tool which comes with TortoiseSVN (also available separately).
Either run it from a command line or use the COM-Object it offers.
The SubWCRev command line tool replaces keywords inside a file with information from your svn working copy. An example is shown in the docs.
I do this in my build script:
<SvnInfo LocalPath=".">
<Output TaskParameter="Revision" PropertyName="BuildRev" />
</SvnInfo>
<FileUpdate Files="protobuf-net\Properties\AssemblyInfo.cs"
Regex='(\[\s*assembly:\s*AssemblyVersion\(\s*"[^\.]+\.[^\.]+)\.([^\.]+)(\.)([^\.]+)("\)\s*\])'
ReplacementText='$1.$2.$(BuildRev)$5' />
using the community build tasks. This essentially applies a regex to the AssemblyInfo.cs, replacing the current revision with the svn revision.
You could use the $Rev$ svn keyword but that will give you the last revision of the file, I think you want to get the HEAD revision number.
Give a look to this question:
How do I sync the SVN revision number with my ASP.NET web site?
How do you feel about a Visual Studio addin doing it?
Yes, you can add a pre-build event that calls a script which
calls svn info to extract the current revision number (if you do an update before, you can directly include the keyword $Revision$ in a file, check also this post);
modifes your Properties\AssemblyInfo.cs file accordingly.
What I usually do is transform a AssemblyInfo.cs template when the project is built. The script is necessary to adapt the form of $Revision$ to the syntax of this file, unfortunately.
The interesting properties are (where the template strings are between '$'):
[assembly: AssemblyVersion("$v$.$build$.$Last Changed Rev$")]
[assembly: AssemblyFileVersion("$v$.$build$.$Last Changed Rev$")]
Edit: svn info is part of the standard SVN client, not TortoiseSVN as pointed out in another post. Easy to install though. However, TortoiseSVN comes with SubWCRev.exe which transforms a file with keyword substitution, so it would do the trick if you update your local copy.
In Visual Studio 2008, you can define a pre-build event that can launch a script or small program. Within this script or program, you can use the svnversion command to get the repository revision, then parse your AssemblyInfo.cs and modify the version number to what you desire.
I'm not sure if TortoiseSVN comes with svnversion, but it does come with the Windows SVN build provided by CollabNet
I created an SVN version plug-in for the Build Version Increment project (which is named in popester's answer). This SVN plug-in will pull the latest change revision number from your working copy and allow you to use that in your version number, which should accomplish exactly what you're trying to do.