Visual Studio has spent decades evolving into one of the best professional developer environments on the planet. But with Visual Studio 2026, something has gone wrong. Key code-quality and productivity tools have been removed, relocated, or broken — and the end result is an IDE that now makes writing clean, maintainable code harder, not easier.

Because I write extensively — both on this site and in my books — about code quality, I want to spend most of this article focusing on how far things have improved since the earliest days of Visual Studio, and how far we’re now slipping back. Over the years, the IDE has steadily added features that genuinely help developers write cleaner, safer, and more maintainable code.

However, with the release of Visual Studio 2026, that momentum has shifted in the wrong direction. Several features that previously helped developers write better code have either been weakened, hidden, or removed altogether. That’s deeply concerning.

I’m not entirely sure why this is happening. Perhaps there’s an assumption that Copilot will “solve everything.” It won’t — at least not yet. AI-assisted coding is a powerful tool, but it is not a replacement for strong, first-class code-quality features built directly into the IDE.

It also feels like this release was rushed. Making these changes available only through the Insiders edition a few months before release left little room for meaningful feedback or course correction. At that stage, it’s simply too late. Worse, the Insiders builds — especially the final few before release — were extremely buggy, which further limited their usefulness as a real feedback mechanism.

Another missed opportunity was the lack of early involvement from Microsoft MVPs. We should have been brought in before these decisions were finalized — not after. I certainly wasn’t notified, and I’ve been an MVP for 19 years. That’s disappointing.

MVPs work with Visual Studio almost every day on real-world production systems — often at scale, under pressure, and across many industries. Many engineers inside Microsoft simply don’t have that same day-to-day exposure. That’s not a criticism; it’s reality. And it’s precisely why MVP feedback matters. When engineers operate inside a bubble, blind spots are inevitable.

One of the main reasons I enjoy being an MVP is the opportunity to help influence Visual Studio and .NET in ways that genuinely improve the developer experience — for all developers.

With that said, let’s walk through the changes in Visual Studio 2026. I’ll close with concrete suggestions for the Visual Studio team. I sincerely hope they listen — because we all want the same thing:

to make Visual Studio the best IDE it can be.

Code Quality

I don’t know what’s going on with Visual Studio, but many of the features that help developers maintain code quality are missing, moved, or broken. Visual Studio has come a long way over the past 25 years, but with the 2026 release, it feels like we’re sliding backward instead of moving forward.

Let’s walk through what’s changed — and why it matters.

Analyze: The Biggest Casualty in Visual Studio 2026

The Analyze experience no longer behaves predictably. Violations appear inconsistently, disappear randomly, and sometimes only show when the Error List is set to Build Only — which destroys confidence in the results.

The Analyze feature has taken the biggest hit in Visual Studio 2026. Many long-standing capabilities are either gone, broken, or scattered across the IDE for no obvious reason.

These weren’t experimental features. These were mature, trusted tools that developers relied on daily — and removing or burying them directly harms code quality and workflow efficiency.

Frankly, I would have loved to be invited to the meetings where these decisions were made — because many of these features worked perfectly well for years. Why change what wasn’t broken?

A side-by-side comparison of the Analyze menu in Visual Studio 2022 versus 2026 tells the story clearly:

Only Analyze Solution for Code Clones remains in 2026.

So… what happened to everything else?

Removed or Relocated Features

• Concurrency Visualizer: Gone. Completely.
• Code Cleanup: Removed from the Analyze menu. Still available only via right-click on a project.
• Calculate Code Metrics: Removed from the Analyze menu.
  • Now buried under View → Other Windows → Code Metrics. You must manually click Calculate Code Metrics… inside that window. In 2022, you could analyze the entire solution
  • In 2026, you’re limited to one project at a time

Running Calculate Code Metrics on a large solution, such as the AWS SDK, does not calculate it for all 442 projects!

This is not progress. It’s regression.

Running Code Analysis: Why Is This So Confusing?

Manually running code analysis is no longer available from the Analyze menu in 2026. Instead, it has been moved to the Build menu.

Let that sink in.

Why is Analyze no longer under Analyze?

To make matters worse:

• Analyze was also removed from the project right-click menu
• There is no clear or logical path anymore

This makes absolutely no sense.

I’m Not Convinced Analyze Is Even Working

When I run Analyze on my Spargine solution, I get zero violations. None.

That’s not realistic.

I already have code analysis configured to run on every build—yet:

• I don’t see violations
• I don’t see analysis running in the status bar
• I don’t get feedback I can trust

Analyze has always had performance issues—even back in 2022. Violations take so long to appear that it often feels broken. For example, I intentionally introduced a violation, and it took around 10 seconds after analysis completed for it to show up in the Error Window.

That delay alone destroys confidence.

Wait a Minute… I See the Problem

Here’s how I usually configure my Error Window:

• Build + IntelliSense

When I run Analyze or Build, nothing appears.

But when I switch the Error Window to Build Only—suddenly the violations show up.

What?!

I saw this exact issue in Visual Studio 2022 that was fixed, but it’s back in 2026.

If Analyze doesn’t run a build, why do violations only appear under Build Only?

This behavior strongly suggests Analyze is not wired correctly—and it absolutely does not inspire confidence.

Unfortunately, this problem also hits the Task List. I can only see all tasks if I close every open file — and even then, it’s unreliable. Some tasks simply refuse to appear unless I reopen the file they’re in. Come on, Visual Studio… make up your mind! When I wrote this, I had a total of 14 TODO: tags in Spargine, but only 11 show up in the Task List.

Old Issues Still Exist (And They’re Still Infuriating)

Here’s a long-standing issue that still exists in 2026:

• Clicking a violation takes me to the code…
• And the violation disappears from the Error Window

So, was it real? A false positive? Who knows.

Another example:

• I get a violation telling me to add sealed to an interface
• That’s not even allowed
• Clicking the violation makes it disappear

Again, what’s going on here?

You Still Can’t Manage Violations Properly

This problem goes back to Visual Studio 2022 and still hasn’t been fixed.

You cannot suppress or manage violations directly from the Error Window anymore. Instead, you must:

• Navigate to each method
• Handle suppressions one by one

On large codebases, this is a massive productivity killer.

This functionality needs to be added back.

Updates

April 2, 2026

The Visual Studio 18.4.3 release has made Analyze even more unreliable. For some inexplicable reason, it now reports hundreds of code violations that are not violations at all. Click on one, let Visual Studio navigate to the method, and suddenly the warnings disappear—because they were never legitimate issues in the first place.

As a result, developers are forced to waste time sorting through what appears to be roughly 90% false positives instead of working on actual code problems. That is not just frustrating; it is a serious productivity drain.

This release also seems to introduce additional bugs beyond Analyze. At this point, my recommendation is clear: avoid installing Visual Studio 18.4.3 until these issues are addressed.

Default EditorConfig: Still Not Good Enough

EditorConfig should be treated as infrastructure — as essential to a project as a csproj file or a solution file.

There are two major problems here.

1. No EditorConfig by Default

When you create a new project in Visual Studio, no .editorconfig file is added by default—even though code analysis depends on it.

That’s a huge, missed opportunity.

2. The Default EditorConfig Is Barely Useful

If you do add one, Visual Studio’s default .editorconfig is only 261 lines long. That’s nowhere near sufficient for modern applications.

That’s why I provide my own dotNetDave EditorConfig, which includes:

• Over 3,000 lines of carefully curated rules
• Frequent updates
• Real-world defaults that actually enforce quality

You can find it here: https://bit.ly/dotNetDaveEditorConfig

Advice to the Visual Studio Team

Every project should include an EditorConfig by default, tailored to the project type.

It’s no wonder that most consulting projects I encounter have no EditorConfig at all—which means no real code analysis. And that leaves me spending far too much time fixing avoidable quality issues.

Visual Studio should be helping developers write better code—not getting in the way.

Right now, with Visual Studio 2026, it’s doing the latter.

And that’s a problem.

Unit Tests

For reasons that are completely unclear, I can no longer run unit tests on classes or individual methods directly from the code editor.

As shown below, Debug Tests is disabled. Even worse, selecting Run Tests does absolutely nothing. I get the following in the output window:

No unit test provider that supports the selected project(s) is found.

The only way I can reliably run unit tests now is through the Test Explorer.

That might sound acceptable on paper—but in practice, it’s a major productivity hit. When I’m working on a single method or a brand-new class, I should be able to run its tests immediately from the editor. I should not have to hunt through the Test Explorer just to execute a test I was just looking at in code.

This workflow regression actively slows development.

An Old Issue That’s Still Broken

When I open the Test Explorer and select Run All Tests in View, some tests always fail in my Spargine solution. Every single time.

However:

• If I navigate to one of the failing tests in the Test Explorer
• Right-click it
• Select Run

…it passes.

So why does it fail when run in bulk but succeed when run individually?

This also causes issues with Live Unit Testing. This raises serious concerns about reliability and determinism in the test runner.

CI/CD Implications (This Is a Big Deal)

In CI/CD environments, determinism matters. A test should pass or fail for the same reason every time. When bulk runs fail, but individual runs succeed, test results become unreliable — and unreliable tests are worse than no tests at all.

This behavior makes it extremely difficult to trust test execution in automated environments like GitHub Actions or other CI pipelines.

If tests fail when run as a group—but pass when run individually—how exactly am I supposed to rely on them during builds?

Because of this instability, I previously relied on TestRunner from CodeRush to get consistent results. Unfortunately, in Visual Studio 2026, that option is gone as well—it no longer works.

So now we’re left with:

• Broken editor-based test execution
• Unreliable bulk test runs
• Fewer third-party alternatives

That’s not just frustrating—it’s dangerous. Unit tests are foundational to modern development, and Visual Studio should be making them easier and more reliable to use, not harder.

Right now, Visual Studio 2026 is failing that responsibility.

Live Unit Testing in Visual Studio 2026: Confusing Changes and Frustrating Reality

For years, I couldn’t get Live Unit Testing working in my Spargine solution. The error messages made no sense, and nothing I found online explained what was going on. For this article, I was determined to finally make it work so I could report on it — and I eventually had to bring in ChatGPT for backup.

Here’s one of the errors I kept seeing:

C:\Users\david\source\lut\dotNetTips.Spargine.10\v2\0\b\source\dotNetTips.Spargine.10\IO\DirectoryHelper.cs(25,27): 
error CS0234: The type or namespace name 'Win32' does not exist in the namespace 'DotNetTips.Spargine' (are you missing an assembly reference?)

After a lot of back-and-forth debugging, I finally discovered the real issue: Visual Studio Live Unit Testing now builds your code using a separate LUT engine, and that build process does not behave the same way as a normal build. In my case, the fix was to switch my Spargine project to net10.0-windows — which actually made sense since the library is Windows-only anyway.

But the surprises didn’t stop there.

In Visual Studio 2026, Live Unit Testing also switched to a completely opt-in model:

• You must explicitly include tests or projects for LUT to run them.
• It no longer runs everything by default.

In other words: something that “just worked” in Visual Studio 2022 suddenly required manual configuration — and I only learned this by asking ChatGPT.

To make matters worse, Live Unit Testing is still flaky in 2026. When I add new tests, LUT doesn’t always discover and execute them — even though it’s running. Sometimes the only way to kick it into action is to toggle Live Unit Testing off and back on… and occasionally I have to repeat that two or three times.

Another frustrating issue is that even when all unit tests pass successfully, the Live Unit Testing window still shows many of them with a status of “Not Run.”

What makes this especially confusing is that there is no explanation or error reported in the Live Unit Testing output. No warnings. No failures. No diagnostics. Just silence.

This creates a serious disconnect between what Test Explorer is telling you (“everything passed”) and what Live Unit Testing is showing (“many tests were never executed”). When two tools inside the same IDE contradict each other without any visibility into why, it undermines trust in the testing workflow and turns what should be a confidence-building feature into a source of doubt and frustration.

Another frustrating issue is that Live Unit Testing sometimes reports no tests or missing test coverage even when comprehensive unit tests are in place, and every code path is fully exercised. This creates a false narrative of inadequate test coverage, undermining confidence in both the tooling and the test suite itself. When a system claims tests do not exist while they are clearly executing and passing, it raises serious questions about the reliability and accuracy of the reporting mechanism.

And finally, the part that really bothers me:

The coverage results shown by Live Unit Testing do not match Test → Analyze Code Coverage for All Tests.

They should match — but they don’t. And that makes it hard to trust either tool when accuracy matters.

Issues with Code Coverage Report

I’m extremely frustrated with code coverage reporting in Visual Studio. Even when using a CodeCoverage.runsettings file, generated code such as [GeneratedRegex] still appears in the results.

According to Copilot, Visual Studio’s legacy code coverage engine cannot exclude regex source-generated IL. To me, that sounds like a Visual Studio bug, not expected behavior.

What makes this even more frustrating is that I could not find a solution in either the Copilot app or the Copilot Agent in Visual Studio. Neither one was able to resolve the issue.

Ongoing Issues with Copilot: Why It Feels Harder to Use Than Ever

AI should augment strong tooling — not replace it. Right now, it feels like Visual Studio is weakening the foundation while leaning harder on AI.

I’ve written before about how Copilot has actually become harder to use since its initial release. Beyond the constant stream of bad code suggestions — many of which don’t even compile — there are several ongoing issues that continue to frustrate me.

Here are a few of the biggest ones:

• I can’t directly target a method using # anymore.
  I now have to manually select the method instead of jumping there instantly — a clear step backward in usability.
• Copilot-generated unit tests often miss code paths.
  Sometimes it completely ignores parts of the cyclomatic complexity, leaving sections of logic totally untested.
• It writes unit tests that don’t even work in .NET 10.
  With the framework changes, you’d expect Copilot to adapt. It hasn’t — and I routinely have to fix or rewrite what it generates.
• It keeps pushing Agent Mode — even when I repeatedly say no.
  I feel like I have to keep reminding it that I don’t want to use Agent Mode. That shouldn’t be necessary.
• The Copy code block icon is in the wrong place.
  It used to be at the bottom of the code window, where it was easy to access. At some point last year, it was moved to the top. For large code blocks, this forces unnecessary scrolling just to copy code. Yes, Select All + Ctrl-C works—but it shouldn’t be required. Copying code is a core developer action, not an edge case. Simple fix: place the Copy button at both the top and bottom of the code window.

Overall, Copilot is supposed to save time — but far too often, I find myself spending extra time correcting or disabling it instead of getting work done.

Visual Studio Struggles with Extension Members in .NET 10

Since extension members were introduced in .NET 10, Visual Studio has had several problems working with them — and even tools like Copilot get tripped up. Some of these issues have been fixed over time, but others still remain.

For example, when I inspect a normal method, Visual Studio shows all the helpful metadata I expect — references, history, changes, and so on.

But when I look at an extension member, those features simply… don’t appear. No references. No change tracking. Nothing.

That makes extension members feel like second-class citizens in the IDE, even though they’re now a first-class language feature.

In addition, every time I ask Copilot to document code like below, it generates incorrect XML!

extension<T>([DisallowNull] ICollection<T> collection)

One unexpected friction point when working with these extension classes is tooling support. Visual Studio does not correctly sort extension members in Class View, often presenting methods out of logical or alphabetical order, which hurts discoverability and slows development—especially in large, method-heavy libraries. Unfortunately, CodeRush has the same issue, failing to properly sort extension methods as well. When both the IDE and productivity tools misrepresent method organization, developers are forced to hunt through source code for functionality they know exists. This isn’t a flaw in the extensions themselves, but a tooling gap that becomes painfully obvious at scale, making clear documentation and disciplined naming even more critical.

Other Missing Features

• Architecture menu: Gone!
• Class Diagram Editor: broken, still! Making it very difficult to create diagrams.
• Project Menu: Many features are gone!

Color Scheme

What Happened to the Classic Blue Theme?

With the 2026 release, the familiar Blue color theme has disappeared—replaced by novelty palettes like Juicy Plum, Bubble Gum, Silky Pink, and more. Fun names aside… was this really the best use of the team’s time? Many of us prefer a clean, professional look — and Blue delivered exactly that.

Please bring the Blue theme back. Choice matters.

One Last Thing

There’s one more missed opportunity I have to call out — the discontinuation of the Visual Studio Multilingual App Toolkit. In October 2025, the Visual Studio team officially killed this incredibly valuable tool. I didn’t just use this toolkit — I wrote an article about it, included it in one of the chapters of my coding-standards book, and even taught a workshop at BuildStuff centered around it.

This toolkit made it shockingly easy to globalize applications for different spoken languages. It leveraged Azure translation services, worked reliably, and delivered huge value — especially for small teams and companies that don’t have the budget for large-scale localization tools. It lowered the barrier to entry for building truly global software.

So… why was it killed?

Why abandon something that empowers developers?
Why not open-source it?
Why not hand it off to the community?
Heck — why not hand it to me? (Assuming it’s written in .NET, of course!)

I’ve seen this pattern over and over again with Visual Studio tools… but this one really stings. It didn’t just remove functionality — it removed opportunity.

And honestly?

Shame on them for letting this one die.

Summary

Visual Studio has always been at its best when it empowers developers to write cleaner, safer, higher-quality code. But in Visual Studio 2026, too many of those core capabilities have been removed, relocated, or broken. Features like Analyze, Code Metrics, unit testing, Live Unit Testing, and even fundamental UI elements now feel unreliable, harder to discover, or simply missing.

Instead of improving the developer experience, these changes introduce confusion, erode trust, and slow down real-world workflows — especially in professional, large-scale codebases. What’s even more concerning is that these changes shipped with minimal MVP involvement and limited opportunity for meaningful early feedback.

AI tools like Copilot can be powerful — but they are not a substitute for stable, first-class productivity and code-quality tooling inside the IDE. Developers need reliability, predictability, and clarity — not disruption for its own sake.

Visual Studio 2026 still has the potential to be the best IDE on the planet. But to get there, Microsoft needs to listen carefully to the developer community, restore and stabilize the features that professionals rely on every day, and treat code-quality tooling as essential infrastructure — not optional extras.

Suggestions for the Visual Studio Team

Here are my suggestions for the Visual Studio team about the issues I have discussed in this article.

1. Bring MVPs back into the loop early.
   Involve MVPs when these changes are being discussed, not after they have already been made. In the past, MVPs have helped the team with this, but I feel they aren’t doing this anymore. I never received a single communication from the program about a change being made to 2026. This is what we are here for — use us. I can’t remember the last time I even received an email from the program other than administrative.
2. Stop moving long-standing features without a clear benefit.
   Don’t change or move around features that have been there for a long time. This confuses developers, frustrates them, and forces them to re-learn how to use these features — for no real gain.
3. Take testing and regression quality seriously.
   Testing Visual Studio before any release needs to be a lot better, including regression testing. Nothing is more frustrating than updating Visual Studio and discovering that things are broken and directly affecting developer productivity. I tried to get someone on the team to come talk about this on my podcast, but I could not find anyone willing to do so.
4. Explain the “why,” not just the “what.”
   If substantial changes like this are made to an updated version of Visual Studio, make a video — or a .NET Conf session — not only outlining the changes but also explaining why they were made and how they benefit developers. If you’re going to move or remove features, help us understand the rationale.
5. Stop Killing Valuable Features
   Stop killing genuinely useful features — like the Multilingual App Toolkit, Windows Workflow, Sync Framework, and others — without providing a real replacement. Developers like myself relied on these tools in production. Removing them doesn’t simplify our lives — it creates friction, breaks workflows, and forces teams to reinvent solutions that already worked. If a feature has to be retired, hand it to the community or open-source it. Don’t just bury it.

If you want me to help you with these items, you know how to reach me!

Pick up any books by David McCarter by going to Amazon.com: http://bit.ly/RockYourCodeBooks

If you liked this article, please buy David a cup of Coffee by going here: https://www.buymeacoffee.com/dotnetdave

© The information in this article is copywritten and cannot be reproduced in any way without express permission from David McCarter.