I'm introduce stylecop functionality with custom rule set in massive application that contain more than 100 projects. Roslyn compiler show errors and warnings in existing code and VS offers common fixes (quick actions). You press Ctrl+. and see fixes. It's so tedious and time-consuming operation select error, press shortcut and applying rule, when you have 100+ project.
I want to automatic apply the rules that in the list. Maybe some script that goes through error list, check that error id exist in list and apply that rule on project.
I hear about Visual Studio Extensions, can they help me? Can someone advise me how can I solve this problem?
The Visual Studio Code Cleanup (find it in the Analyze menu) has a Code Cleanup option. You can configure a profile with the Fixers you want to run and the have it blast through a complete solution.
Save the profile with the fixers you want, then choose Run Code Cleanup (Profile) on Solution.
Related
I am building my .editorconfig for my project. I see both "Suggestion" and "Refactoring Only" for several of the options. What is the difference between these?
From the documentation
Violations of a Suggestion appear as build messages and as suggestions in the Visual Studio IDE; see the Messages section in the Error list.
The description for Silent applies to Refactoring only, as it will be saved as such in .editorconfig, e.g.:
dotnet_naming_rule.interface_should_be_begins_with_i.severity = silent
Violations of a Refactoring Only/silent rule aren't visible to the user, but the Quick Actions and Refactorings... menu shows an entry to resolve the violation (similarly as for Suggestion violations).
A closed issue on the Microsoft Visual Studio documentation on GitHub says:
Do not show anything to the user when this rule is violated. Code
generation features generate code in this style, however. Rules with
silent severity participate in cleanup and appear in the Quick Actions
and Refactorings menu.
How can I make my code build to fail when ReSharper detects an "Error" after code inspection?
I am using C# in Visual Studio 2017 along with ReSharper. I have set the inspection severity of Possible 'System.NullReferenceException' to show as "Error". This setting only shows a red underline for erroneous code, however the VS build still succeeds if I just ignore it. I want to make the build to fail if developer ignores such errors detected by ReSharper inspection.
I'm afraid Resharper seems to not support this option for now.
1.In my opinion, the error level in C#\Potential Code Quality Issues is something like showing a red underline to indicate where there maybe has a risk to help improve your code. And red to indicate this issue deserves attention. Actually,it's something controlled by us, we determine to make them error(red line) or warning(blue line?).
But such a potential code issue can't be recognized by msbuild (build system in vs). So the build will ignore these potential issues and succeeds.
2.For build settings in Resharper, I tried msbuild settings and compiler settings like below:
I set every element in the Potential Code Quality Issues to error. Also, i set null reference related settings like below:
After that I create a simple null reference but the build ignores that and succeeds. Same result when I use Resharper build.(Resharper options=>Tools=>Build=>Build engine) So maybe it's a negative answer :(
This isn't an ideal solution, but JetBrains provide a command line tool called InspectCode which runs their code inspections on your solution and outputs the results in XML or other formats. You could add a custom MSBuild step which runs InspectCode.exe MySolution.sln -o=output.xml, examines output.xml for errors, and fails the build if any are found.
Unfortunately InspectCode is slow and even though the analyses seem to be cached across runs it still takes a significant amount of time. For example, on my solution of 700k lines of code the tool takes 60 seconds on the second run, i.e. with a warm cache. So I don't think this is a viable solution to run on developer machines on every build. It might be acceptable in an automated build system.
I found a similar question here, but of no help.
I have a solution with nearly 10 projects in it. I am able to edit the code while debugging the solution, but for 1 particular project (say "Defect.csproj"), I am not able to. I am receiving the error as
I have compared the properties of this "Defect.csproj" project ith other project properties and everything is found to be same. In Debug and Build tab in properties, Configuration is Debug. Optimize code is off. Can anyone suggest me whats the problem with my solution?
Are you using any special references on this project?
Using office references or delta lambda expressions can silently break the edit and continue functionality.
Also using some third party component winform items can really play havoc with edit and continue.
Also keep in mind that using linq breaks edit and continue fairly often and editing inside a try catch block on the active function is bad.
I have a VS solution containing several projects. While debugging a particular project all the source files are locked by VS. I would like to unlock sources that the debugee doesn't have dependency on. Is there any way to do this within one solution?
UPDATE:
I'm using Win XP SP3 32bit. Visual Studio 2010, C#. Edit and Continue is enabled. The solution contains 6 projects (number in not important actually), 5 of them depend on the data access layer project which uses Entity Framework. None of the 5 have any mutual dependencies. They are WinForms and Console applications. I would like to be able to run one of the projects and make changes to others without stopping the first. The problem is starting and stopping the project take considerable amount of time.
The Edit and Continue feature is preventing you from editing files if the debugger hasn't stopped the program. The simple workaround is Debug + Break All, you should then be able to edit the files, your changes will be immediately effective provided your changes do not violate the restrictions imposed by E+C. This is the most efficient work flow.
The heavy-handed approach is to disable Edit and Continue. Tools + Options, Debugger, Edit and Continue, uncheck the Enable check box.
I don't think that there is a way to avoid that. While debugging Visual Studio lock all files to prevent any change on them, including those on other projects.
You can try to open the project which you are interested on with another Visual Studio instance to make changes to your files or open files singularly with another editor.
This doesn't quite answer the OP's question per se, but for anyone who has stumbled upon this page in the same (very frustrated) boat as I am, this might help.
The solution: start without debugging.
It was driving me absolutely crazy that Visual Studio would not let me edit files while the app was running. My typical workflow is:
Make some changes
Run the app to see the effects of those changes
Based on the results, make more changes, etc. etc.
The problem is Visual Studio was preventing me from step 3. It demands that you STOP running the app before you can even make any changes (including to a XAML file or adding a file to the project), which also means that you can't go back to the app to double-check something while you are actually programming it at the same time (which is how I work, bro).
Thank god I finally discovered if I run without debugging it doesn't impose this ridiculous limitation. It's still a pain in the butt if you actually need to debug something you have to re-run the app in debug mode, but it sure beats having to kill the app before it will even let you edit a file.
I'm actually working on a tool that need some configuration before it can be used. To save some time a hard coded some values into the text boxes of the configuration tab, so I don't have to renter them every time I do some testing or debugging.
As we're using TFS to manage our solutions I'm wondering if there is a way to mark those hard coded elements in some way so that TFS or Visual Studio 2008 will remind me to remove/replace them before I do a check in.
UPDATE:
The todo comments won't be a real solution as we're already using it to mark code segments which have to be reworked. We use it as a reminder for longterm tasks. And we have plenty of them so this might become a little bit unclear.
Some options:
write a custom checkin policy
use the existing FxCop checkin policy and write a custom rule (if you're marking TODOs with something that gets actually compiled, like an Attribute)
ditto, but via the StyleCop checkin policy (if your TODOs are source comments)
Probably not the perfect solution, but Visual Studio let's you add TODO comments that may work well enough for you.
You could write a unit test that fails when the hardcoded stuff is found. Obviously, you won't get a reminder before checking in but you do get a build failure afterwards.