I recently updated from an earlier version of VS 2019 (I don't remember which) to version 16.11.5 and now all my C# code is littered with little gray dots (see screenshot), which I think indicates Code Analysis violations. Is there a way to disable all Code Analysis rules for ALL solutions??? I've searched high and low and everything I've found suggests I can only do this on a per-solution or per-project basis, which is infeasible as I have hundreds of solutions.
Related
The diagnostic tools in Visual Studio 2019 Community have stopped working. It shows it's recording the CPU profile but whenever I pause the program to see the results, the tools say "There is no data in the current set of filters."
It was working at one point, and as far as I'm aware, I didn't change anything. And if I go into the Filter drop down menu it shows everything except "Hide native code" is selected.
How can I fix this?
A recent Windows update has apparently added a second problem to the original NVIDIA Display adapter issue.
See this ticket in Microsoft Developer Community: No Data in CPU Usage Tool, Windows Update related
Recently a Windows Update broke the CPU Usage tool in Visual Studio
where no data is collected. After analyzing the tool will report,
“There is no data in the current set of filters”. This is due to a bug
in the Windows ETW subsystem such that profiling events are not
emitted, we are working with the Windows ETW team to root cause the
issue and create a fix. As this affects ETW, the underlying system
which creates the profiling data, this will affect any ETW profiler:
Visual Studio, PerfView, WPA, XPerf, etc.
This is also discussed in the Microsoft Developer Community link in Andrey's answer, profiling CPU still states no user code was running. Scroll down to Mar 17, 2021.
It seems that there is now another underlying root cause besides the
original NVIDIA one which is breaking ETW profiling system wide. This
means any ETW profiler (Visual Studio, WPA, PerfView, etc) will be
affected since all of them rely on the same ETW system. Unfortunately
the EnableTraceEx2 system call returns success and we end up with no
profiling data in the resulting trace which is making debugging
difficult. I’m engaging with the Windows team that owns the ETW
subsystem and will most likely need additional diagnostics once we
figure out what our next steps are. In the meantime if anyone has paid
product support licenses feel free to engage with that as well,
hopefully working together we can uncover the root cause. Once I get
more information from the ETW team I’ll report back, until then stay
tuned.
Hi folks, just wanted to let everyone know that we have engaged with
the Windows ETW team on this and they are investigating. It seems like
a recent Windows Update may have caused this issue and they are
working with an internal customer in Xbox who has a repro. When I have
more info on the cause, workaround, and fix I will let everyone know.
In the mean time stay tuned.
I've found an answer here. For now, the only solution seems to be disabling NVIDIA Display Adapter in Device Manager and reboot.
In my case the other sampling profilers, e.g. AMD μProf didn't work well either with that driver.
I have been having this issue for months and no fixes have worked but using the Visual Studio Installer I ran repair on the IDE and now profiling works properly.
Edit: This didn't permanently fix the issue. But going to "Virus and threat-detection settings" and disabling "Real-time detection" allows it to collect data now too.
Edit2: My first appears to be the root cause for this and there is a MSFT solution here
Having just switched to VS2019 I’m exploring whether to use code analysis. In the project properties, “code analysis” tab, there are numerous built-in Microsoft rule sets, and I can see the editor squiggles when my code violates one of these rules. I can customise these rule sets and “save as” to create my own.
I have also seen code analyser NuGet packages such as “Roslynator” and “StyleCop.Analyzers”. What’s the difference between these and the built-in MS rules? Is it really just down to more comprehensive sets of rules/more choice?
If I wanted to stick with the built-in MS rules, are there any limitations? E.g. will they still get run and be reported on during a TFS/Azure DevOps build?
What's the difference between legacy FxCop and FxCop analyzers?
Legacy FxCop runs post-build analysis on a compiled assembly. It runs as a separate executable called FxCopCmd.exe. FxCopCmd.exe loads the compiled assembly, runs code analysis, and then reports the results (or diagnostics).
FxCop analyzers are based on the .NET Compiler Platform ("Roslyn"). You install them as a NuGet package that's referenced by the project or solution. FxCop analyzers run source-code based analysis during compiler execution. FxCop analyzers are hosted within the compiler process, either csc.exe or vbc.exe, and run analysis when the project is built. Analyzer results are reported along with compiler results.
Note
You can also install FxCop analyzers as a Visual Studio extension. In this case, the analyzers execute as you type in the code editor, but they don't execute at build time. If you want to run FxCop analyzers as part of continuous integration (CI), install them as a NuGet package instead.
https://learn.microsoft.com/en-us/visualstudio/code-quality/fxcop-analyzers-faq?view=vs-2019
So, the built-in legacy FxCop and NuGet analyzers only run at build time while the extension analyzers can run at the same time the JIT compiler does as you type. Also, you have to specifically say to run legacy code analysis on build, whereas the NuGet analyzers will run on build just because they are installed. And analyzers installed as NuGet or extensions won't run when you go to the menu option "Run Code Analysis".
At least, that's what I get out of that page.
There's a link near the bottom of that page that takes you to what code analysis rules have moved over to the new analyzers, including rules that are now deprecated.
https://learn.microsoft.com/en-us/visualstudio/code-quality/fxcop-rule-port-status?view=vs-2019
The different analyzers attempt to cover different coding styles and things Microsoft didn't cover when they built FxCop. With the little research I just did on this, there's a whole rabbit hole to follow, Alice, that would take more time than I have right now to devote to it. And it seems to be filled with lots of arcane knowledge and OCD style code nitpicks that make Wonderland seem normal. But that's just my opinion.
There's lots of personal and professional opinion about various rules in these and basic Microsoft rules, so there's plenty of room to use what you want and disable what you don't. For a beginner, I'd suggest turning on only a few rules at a time. That way you aren't inundated with more warnings and errors than lines of code you might have. Ok, so that might be a bit of an exaggeration, but there's so many rules that really are nitpicks, especially on legacy code, that they aren't really worth it to have enabled, since you likely won't have time to fix it all. You will also want to do basic research and use "common sense" when you decide what to enable. ("Do I really need to worry about variable capitalization coding style consistency on an app that's been ported into 4 different languages over 15+ years and has 10k files?") This is both personal and professional opinion here, so follow it or not.
And don't forget the rules that contradict each other. Those are fun to deal with.......
I'm interested in using Rubberduck primarily for it's Github source control feature. However, from looking at the Github site for the project I can see that in the most recent versions that feature is not so stable. My question is, what version should I use? For now all I really care about is to have the most stable source control feature. Should I go back as far as v1.4.3? Or is there another 2.X version that was more stable before things recently got worse?
EDIT: As per Vogel's comment
This answer is outdate since a few months: Source control has been
removed completely in the PR #3782 on Feb 26 2018
Even so...
I'd definitely recommend trying out Rubberduck; the unit testing, code inspection and other features are awesome... also the guys involved are generous with sharing their time and knowledge - but IMHO would shy away from using an old version to gain access to the Git features (it has been disabled for a reason).
You can enable it as an 'Experimental Feature' under the menu system > Rubberduck > Settings > General Settings (scroll down)
If you really need something ASAP perhaps look at VBAdiff (http://vbadiff.com/) or this project https://github.com/spences10/VBA-IDE-Code-Export
The bulk of the efforts of the past couple of months went to perfecting the parser and resolver, which impacts overall performance and all inspections and refactoring features; eliminating inspection false positives and making sure no quickfix or refactoring wrecked our users' code has been the top priority, leaving the borked source control panel under-loved - so much that we recently outright disabled it by default, until we git it under control.
Teams mean to grow, and a new contributor joined the project and started working on the source control panel issues.
A pull request was merged recently,
and since every merged PR gets a prerelease CI build published, v2.1.0.2257 is now available for download.
This fixes an IoC registration bug involving an abstract factory interface that the SC panel uses, and it just so happens to apparently fix the exceptions with GitHub authentication, so pushing should now work fine.
More fixes on the way, v2.1 "green release" will likely have a pretty much stable source control feature =)
this is really giving me headaches, ever since I installed the last update pack, visual studio[2012] keeps removing white space at the end of each line when I save a file.
it's fine if I'm working on personal projects, but not when working on team projects where code changes are reviewed that gives reviewers hard time for so many changes made turn out to be white spaces
I can't find any settings that turns this off, there're some posts online mentioning about injecting a piece of macro in the IDE to stop this from happening. Seriously? I can't believe Microsoft delivers such a bad feature that there's no way to turn it off...
can anyone here help me out please?
please note it's Visual studio 2012
Are there any support tools like coderush or resharper for F#?
Preview version of FSharpRefactor released in Visual Studio Gallery.
http://visualstudiogallery.msdn.microsoft.com/339cbae9-911d-4f99-9033-3c3564676f45
http://www.youtube.com/watch?v=T6-YjUULNCA/
F# Refactor open source project on CodePlex (Apache license).
Take a look at the open-source Visual F# Power Tools project. They've got a rename refactoring, some code generation stuff (eg. record stub generation), graying out of unused declarations, as well as some other things. They're moving pretty fast at the moment, with lots of new features getting added all the time.
There's an effort to support F# in ReSharper via an external plug-in (itself written in F#). You can find preliminary info here.
FSharpRefactor 0.1 (Preview version) Released on the Visual Studio Gallery.
http://visualstudiogallery.msdn.microsoft.com/339cbae9-911d-4f99-9033-3c3564676f45?SRC=Home
Not yet, as far as I know. I was also looking for something similar to no success. I suspect as soon as F# hits VS2010 as its integral part, or even a bit earlier, such tools will eventually emerge.
As far as ReSharper is concerned, you may want to drop JetBrains a quick email, it would be interesting to know whether these guys have any plans regarding F#.
Since the push in f# is towards light mode the reformatting possible is likely to be both limited, and hard to implement.
Normally reformatting takes the structural information and uses that to create the textual position. In the case of #light the textual position (of indenting at least) is the structure. As such any reformatting would be at best to sort inter symbol spacing, hardly onerous to do yourself.
I would therefore not expect a commercial product for it at least until the 'proper' integration with the IDE (I do not consider the current CTP proper in this regard since several outstanding bugs with it exist which will not be fixed in 2008)
CodeRush is working in F# editor. At least some code assistance and code templates. But code templates are not defined yet (you have to create your own).