The Modern .NET Show

S08E09 - Unpacking Visual Studio 2026: New Features, Bug Fixes, and What's Coming Next with Mads Kristensen

Sponsors

Support for this episode of The Modern .NET Show comes from the following sponsors. Please take a moment to learn more about their products and services:

Please also see the full sponsor message(s) in the episode transcription for more details of their products and services, and offers exclusive to listeners of The Modern .NET Show.

Thank you to the sponsors for supporting the show.

Embedded Player

S08E09 - Unpacking Visual Studio 2026: New Features, Bug Fixes, and What’s Coming Next with Mads Kristensen
The Modern .NET Show

S08E09 - Unpacking Visual Studio 2026: New Features, Bug Fixes, and What's Coming Next with Mads Kristensen

Supporting The Show

If this episode was interesting or useful to you, please consider supporting the show with one of the above options.

Episode Summary

Mads Kristensen discussed the upcoming release of Visual Studio 2026, which is currently available as a public preview. He highlighted some of the new features that can be expected in the final version, including improved profiling and debugging agents, which will enable developers to more effectively identify and resolve issues in their code.

Kristensen also emphasized the importance of treating bug reports with care, suggesting that they should be viewed as gifts rather than complaints. This approach encourages developers to take the time to thoroughly investigate and address each issue, ensuring that users receive high-quality support for Visual Studio. By framing bugs as opportunities for improvement, Kristensen believes that this mindset can lead to a better overall user experience.

In contrast to web development, which often involves working with external dependencies and frameworks, developing an IDE like Visual Studio is a more contained process. According to Kristensen, the primary focus of an IDE is on providing a comprehensive environment for writing, debugging, and testing code. As such, many of the features that are designed to address specific issues in web development may not be as relevant or useful for desktop applications.

Despite this, Kristensen noted that the team has made significant progress in addressing user concerns over the past year alone. The number of bugs and improvements is substantial, with much of it focused on improving the overall stability and performance of Visual Studio. By prioritizing bug fixes and feature enhancements, Kristensen believes that the team can deliver a high-quality product that meets the needs of developers.

Episode Transcription

And the first feature we have that take advantage of this deep integration is the Profiler Agent. And this is absolutely bonkers. So you can simply go to the chat window in Visual Studio and you can ask….

- Mads Kristensen

Hey everyone, and welcome back to The Modern .NET Show; the premier .NET podcast, focusing entirely on the knowledge, tools, and frameworks that all .NET developers should have in their toolbox. I’m your host Jamie Taylor, bringing you conversations with the brightest minds in the .NET ecosystem.

Today, we’re joined by Mads Kristensen to talk about all things IDEs, tooling, and the new functionality that Visual Studio 2026 (aka “Dev 18”) includes and how it has the chance of greatly impacting your development practice, in a fantastic way!

And we want to make sure that You know, we we do as many of those as we can. We want to remove those paper cuts, make you as happy as possible. And so if you look back at the last 12 months, we have of you know of all the bugs people have opened on us, we fixed almost 4500 user-reported bugs. That’s 18 bugs that we fixed every single work day.

- Mads Kristensen

Did you know that Mads was present for what many see as the inciting incident that lead to .NET being both open source and cross platform: when jQuery was bundled with ASP .NET Framework and Visual Studio.

We also took some time to talk about bug reports, the things that you and I can do to ensure that our bug reports are read, providing positive feedback, the Visual Studio teams’ velocity, and some of the amazing new features in Visual Studio 2026 like the … well, I’m getting ahead of myself. You’ll have to listen in to the episode to find out what those features are.

It’s also worth noting that I recorded this podcast with Mads back in late August 2025, which was way ahead of the public preview of Visual Studio 2026. Whilst we didn’t talk about anything that was super secret, things might have changed between recording the episode and you listening in.

Before we jump in, a quick reminder: if The Modern .NET Show has become part of your learning journey, please consider supporting us through Patreon or Buy Me A Coffee. Every contribution helps us continue bringing you these in-depth conversations with industry experts. You’ll find all the links in the show notes.

So let’s sit back, open up a terminal, type in dotnet new podcast and we’ll dive into the core of Modern .NET.

Jamie : So Mads, welcome to the show. It’s been, I mean I’ve been to MVP Summit like four times now. And I’ve sat and watched your talks that you’ve given in absolute awe of what’s happening with Visual Studio. So this is a real treat for me. So thank you very much.

Mads : Thanks for having me on. I’m excited for this.

Jamie : Oh my goodness, not as excited as I am, and it’s not a competition, so we’ll drop that.

I guess before we start. Let’s talk a little bit about Mads rather than jumping straight into Visual Studio. I always like to get to know the person a little bit if you’re happy to give us a bit of a quick bio, a little bit of an elevator pitch, who Mads is? Who’s this guy? Because not everyone in .NET may know of you.

Mads : Yeah, of course.

I’m, my name is Mads Kristensen, and I’m been a developer, you know, since I left school. I’ve always been tinkering with some sort of programming since the nineties. And I was, you know, software engineer up through my twenties in different startup companies. And you know, we used Visual Studio. I used to do VB .NET, and then because of a job change I had, so I started doing C# around 2005. you know, I’ve have done C# ever since, and absolutely love it.

But I’ve been a Visual Studio user since back twenty-five years, I guess. As a developer, as someone using Visual Studio all day, every day, and not just for like my work. But then, you know, I had all sorts of side projects. I built like some open source stuff back then. Some of your listeners might might know BlogEngine .NET, which was kind of the .NET blogging platform that was, like, I think it was the most popular at the time, like 2006/7/8, something like that.

And then 2010, Microsoft reached out and basically offers me a job in Redmond to work on the web tooling of Visual Studio for .NET in particular. And so I was already a web developer and a, you know, .NET developer for ten years using Visual Studio, and so this was a dream come true. And so this was 2010. I started in November 2010. I moved to Redmond, and I started working on the ASP .NET team; who was the one building the tooling for anything web related inside Visual Studio. So CSS, JavaScript, HTML, and of course, you know, WebForms. The Web Forms editor. and all the other features that are, you know, relevant to a .NET web developer. And so I did that for for many years.

I wrote a bunch of extensions for Visual Studio that made it even easier to be, or maybe more interesting and fun, to be a web developer. One of the the bigger ones was called Web Essentials. People might know that one. It came out like twelve years ago or something like that. You know, many versions of that, you know, it was just fun. I was a web developer myself, so like having all these features and and building all these features into Visual Studio was fantastic for me, of course, as a web developer. But you know, I could see that other people really liked it too. Like we got a lot of great feedback for it. We got a lot of usage on all that stuff. So that was fantastic a time of my life, really. I look back on that like really fondly.

Later on I moved over to the Visual Studio team, which is separate from the .NET team, but they’re very closely related, but they are organizationally different. On that team I worked on extensibility because at that point I’ve written so many Visual Studio extensions that I became kind of an expert in that. And so that was, I moved over to that team to be the Product Manager for extensibility. And I did that for several years. and I’ve been on the Visual Studio team ever since in different you know, aspects and capabilities and so on. So… or sorry, not capabilities, capacities. You know, I call myself "the junk drawer of Visual Studio," so I do a little bit of everything and absolutely enjoying it.

Nowadays I’m mostly focused on the users, making sure that the users, whatever they need, what they want, what they think about Visual Studio, that all that comes back into the product teams, come back into the engineering teams, and that we can act on it and do something new feature-wise and and you know remove paper cuts, add delighting features, make people happy, and make Visual Studio as as good as it can be.

Jamie : The Joker in me wants to say, "so it’s your fault that jQuery was bundled with ASP .NET back in the day then."

Mads : I was there at the time. So yeah, no that was that was a big effort that came in. It was, we keep joking about it. It keeps coming up every now and again because it was, like, one of those big things where Microsoft, all of a sudden, started shipping open source. So this was back then, but this was something that was really pushed hard on from Scott Hunter, Scott Hanselman, Damian Edwards, and others on the .NET team.

And we shipped it in Visual Studio. It was part of the project template. When you say "File > New > ASP .NET project," you know, jQuery would be there: jQuery.js. And we built that into NuGet as well. So you could share, you know, your JavaScript frameworks could be shared on NuGet as a transport mechanism. You know, that was, you know, Phil Haack did that back in the days. This is, I’m name-dropping here, but this is all the stuff that took place around the time, like 2010, 2012, somewhere in in in there. So it’s been a while. But you know, of course we’ve fully embraced open source and have done so ever since. Everything is open source these days, almost; at least what makes sense, right?

But that all started with that jQuery thing back then. And it was it was a huge deal because we were not ready for it. We didn’t know, like, is with the legal system and, like, what were we allowed to do and, you know, what would the lawyers allow us. There was a whole lot of new firsts that we had to basically break some new ground, and figure out how all this stuff worked, and how we could ship something open source with our all of our, the rest of our stuff; which is, at the the time, was not open source, right? And so how does all that work? And that was fascinating to be part of.

Jamie : Oh definitely. I mean, it’s a fascinating journey to go from, basically, including jQuery with ASP .NET to ASP .NET Core 10, right? That’s, essentially, the beginning of that journey, right.

Mads : Yeah, you could you could say that in many ways it was, yeah. It was a new way of looking at building software and thinking about software, yeah.

Jamie : So I’m wondering then, you said that you you joined the ASP .NET team as a web developer. And then there was a transition into Visual Studio, which is more, in my understanding, like dev tooling, right? Was that a bit of a huge difference in, like, just how that all works? Because obviously, you know, web dev we’re talking, you know, it’s stateless, usually with the REST, but you know, maybe you’re doing SOAP, something like that, right? Lots of different frameworks and libraries, you’ve got to worry about a browser, you’ve got to worry about transport. Whereas like dev tooling in one massive piece of IDE amazing tooling debugginess, is completely different to, you know,&quote; I’ve written a web form that can do a post or a postback or a pre-postback or a post-postback or a pre-post-post back," or you know.

Mads : Yeah, it was kind of a difference. But you know, I when I joined the ASP .NET team, I’d been a web developer professionally up until that point, working as a web developer and as a developer manager for a front end team in, like, one of these startups that I was part of. But when I got hired by Microsoft, it was actually as a Product Manager and not as a developer. But I was able to use my, you know 10 years of Visual Studio usage as a developer to help me basically build, you know. I had that instinct on what developers wanted. And so coming into that, yeah, it was you know, at the time, you know, with with ASP .NET, it was it was not stateless because of what you’re saying, like with the post backs and the web forms back in the day, it did have some of that.

But me also had MVC. MVC was out at that time, I think it was MVC 2 or 3, and so that you had that kind of stateless nature of web at that time on the .NET side. Of course, before all that when it was ASP classic, that’s how I started with web development, back in the 90s, I mean that was stateless. If we don’t include session variables and stuff like that, but it was stateless.

Yeah, and then when you come over, you you work on the ASP .NET team, but I worked on Visual Studio for the ASP .NET team; for the ASP .NET Developer features in Visual Studio, right? And of course, Visual Studio is a desktop app, and it’s probably one of the largest desktop apps in the world. We don’t really know how many lines of code there is, but an estimate is like around 200 million lines of code. It’s just a very different thing than building websites, that’s for sure, right? It’s a completely different world.

Jamie : Right, yeah. ‘Cause like, you know, as a, I guess, backend web dev, which is what I would describe myself as, you know, I don’t have to worry about, "how do I spin up the debugger," right? And, "how do I get the operating system level stuff to talk to the debugger to give me a handle do the memory, so that I can actually step through code," and things like that, right? I just worry about, "it runs, and if it breaks then, you know, the stuff that the folks at the the Visual Studio team can help me by throwing in a breakpoint and walking through the memory," right? I don’t have to think about, "how in the heck does this all work?"

Mads : Yeah. I think that’s really the power of of an IDE.

And you know, IDEs: before I started using Visual Studio heavily, I used various different editors and whatnot. And, you know, I think what really happened with Visual Studio was I fell in love with the concept of an IDE. Like the notion that you have, kind of, what you need and you have that, sort of, F5 experience: "just run your code. Set the breakpoint, debug through it." You have the IntelliSense, you have testing built in, you know, test explorer and all that. And it’s all kind of just there. And it all seamlessly, kind of, works together and you can be productive immediately.

That was like something for me that was a hugely empowering thing; because having all that power means that I can go from "idea in my brain" to like "a working prototype" in no time. And knowing that whatever I can dream of, I can also build. Granted, I might have to learn something. I might have to go look at documentation for various different libraries and frameworks or whatnot. But knowing that it’s something that’s within my reach and I can go ahead and do it if I want to, that’s a hugely empowering thing.

And I think IDE has a lot to do with it because it removes a lot of unknowns. Like if I’m not in an IDE, if I’m in a text editor, I have to set up my entire tool chain and, you know, build system and whatnot; like there’s a lot more to to set up. There’s a lot more like mechanical parts, you know, moving parts to the story. And I think not having to worry about that, and just kind of worry about, "hey, that’s the app I want to build, that’s the idea in my brain that I want to see in real life." It seems like the the the distance from idea to working prototype is much shorter. At least for me, that’s my experience. That’s why to this day, twenty-five years later, I’m still like loving Visual Studio. It’s my favourite thing to do is to start up Visual Studio and code something.

And I think that’s the power of the IDE.

Jamie : Yeah, definitely. Having all of those tools at your fingertips. And then even, like. tools you may not even know exist, right?

One of my thing favourite things to do with any IDE is just click around in the menus and see what I can find, right? Because invariably there’s some tool somewhere that someone on the IDE team, say someone on the Visual Studio team has thought, "do you know what would be really good? If I could like deeply inspect the memory?" Or, you know, or I can do like a generate a GUID or something like that in the IDE; so then I don’t have to worry about loading up a page. Or like I can, you know, maybe I can just paste some JSON and have it automatically convert that to C# or whatever, right? It’s just like like you said, dealing with the paper cuts and adding… I forget the, was it the the phrase that you used was, "adding delight?"

And I think that’s the thing that a lot of devs who spend a lot of their time in Visual Studio kind of miss: that there is loads of stuff there that you can actually, "oh wow! It can do this! Oh did you know it can do that! Wait there’s a button for that, too!" Like there’s so much that you can explore and so much joy you can get just by clicking through menus and going, "what does that do? Oh, what’s that do? Why would I need to be able to do this? Wait, now that makes loads of sense." You know what I mean? There’s just so much there to sort of explore.

Mads : Yeah, and you can take that even further if you go through the settings, you’ll find a bunch of of stuff there, too. Visual Studio has so many features and some of them are a little bit hidden, you know. Or they’re not you know, they might not be enabled by default. And so going in and see what you can enable, what’s in the tools & options, is… it’s always a fascinating thing.

And if you’re on the preview version of Visual Studio, which I would recommend anyone to at least try out; you can have it installed side by side with the regular stable version if you wanted to. They don’t interfere with each other. I always just run the preview version. I don’t ever use the stable, I just always run the preview. But in there you got all these preview features where it’s, like, the team is, like, "we want to roll out a new feature but we’re not completely done yet. We want to get some more feedback, or test how people are using it, or something like tha. So we’re gonna just put it behind the feature flag." And so you can go in and you can enable those different features that are, kind of, it’s almost like, kind of, a labs type of thing: where you can get, like, even earlier preview of features by going and exploring what’s available and what you can turn on, what you can enable. And there’s some fantastic things in there. That’s always fun to look at.

Jamie : I have two questions about that, just off the bat. So I guess, how would someone go about getting access to the preview, right? Because we’ve chatted before we hit record, via email and things like that. So I know that there is a public preview. But like how do I get that? Is that just like, "I email Mads." Or do I lean out the window and yell? I mean how… what’s that look like?

Mads : Yeah, that’s a good question. No, it’s publicly available. So if you go to visualstudio.com, there’s a download button and you can select preview. And so that way you, kind of, you always get the features first. The preview is updated about monthly. You get a lot more, you know, earlier features than than you would otherwise. Like, nowadays that we shift it to a monthly update cadence for the regular stable version of Visual Studio, you’ll typically see that the preview version you’ll get the features like at least one or two months before they hit the stable version. So it’s a way for you to be on the latest and greatest. And yeah, I recommend that for people who, kind of, like that to be on the latest and greatest. If you’re like on your phone and your operating system, if you’re like on sort of any preview ring or something like that to get things even faster, then I would recommend you do that with Visual Studio too. It’s fun.

Jamie : And just because you mentioned something, real quick though, I’m not sure lots of devs who use Visual Studio realize that. Hey, um, if you open the installer, which is a separate item in your start menu, it will update everything. Right? So you don’t have to stay on a static version of Visual Studio, right? So like as a background there, when I started my .NET journey, it was back in 2004. So I was using, I guess it would have been Visual Studio 2005, right? To get the new version, you have to download the installer, and run the installer, and wait and do all that kind of stuff. We don’t have to do that now, right? I could just run that Visual Studio installer from my start menu because, "hey, I’ve got some updates. Do you want me to install them?" And you can manage the different versions you have installed there, right? Am I remembering that correctly?

Mads : Yeah, that’s absolutely right. And not only can you have like all these different versions, you can have like, you know, Visual Studio 2019, 2022, 2026-preview. You can have like Enterprise in one and Community in another or whatever. And they can all live side by side. Like most of the engineers on the team, they got like five or six different versions of Visual Studio installed at any given time. And you can update them all together or you can update them individually. It’s kind of a, it’s a nice little control panel to have to manage all your installations. Actually, if you’re using SQL Server Management Studio, since that latest version, version 21 of SSMS, that is now also being managed by the Visual Studio installer.

Jamie : Right. Yeah, I had to go through the process of manually installing everything for a machine for a client very recently and I was like, &quopt;I need SSMS, I’ll download the installer," and then it just pops up Visual Studio installer. I’m like, "what, what? What happened then?"

Mads : Yep. That’s new. So that’s coming out too. So you’ll see the the the SSMS 22-preview. you’ll see that as well. That’s something you can go and grab too. So you can have both Visual Studio 2026 and SSMS 22 installed. You can go do that today and you can get the manage it all through the installer, the the one Visual Studio installer.

Jamie : So that’s kind of nice. Yeah, it makes everything way simpler, right? One place to to manage it all, one sort of toolbox, dashboard, I’m not sure the correct word, but yeah, the one place to manage it all makes it so much simpler.

I guess with that then, does that mean that—and I’m not asking for any kind of secret source or whatever—but does that mean that managing the installer from y’alls perspective becomes more difficult to do, right? Because you’ve previously had lots of different products, lots of different installers. Now suddenly there’s, in effect, one installer to rule them all. And I guess you guys have to manage that too.

Mads : Yeah, we’re managing all that stuff, but the way that it’s set up is that it’s set up in these different channels. And so, you know, we can add, so you have a channel for Visual Studio 2022, and you got a channel for a preview channel. Then you got the different SKUs, like you got Community, Pro, Enterprise, and so on. And so that’s all set up in a way that’s kind of generic. So we can just we can add new channels, and new products, and it’s all kind of dynamic. and that’s not that big a deal.

Of course it’s, like, I make it sound like maybe it’s easy and all that. There’s definitely work involved, but it’s designed with that in mind. So it’s not that big a deal, let’s put it that way.

Jamie : Right, right.

So I have a I have a thought on… okay, first off, naming conventions. Naming stuff is hard. Right? And and we’re talking, like we originally got talking about the "Visual Studio 18 Public Preview." And there was 18, is Visual Studio 2026. Or is it 2022? And you know, like it would make sense if it was 26? But like I appreciate that there’s some legacy stuff there, but what’s with that naming convention?

Mads : Yeah. This is this always comes up because it is kind of, I don’t know.

You know, most of us that even work on the product, we’ve never always liked it, but there there are some reasons why we always have the year as the moniker on, you know, Visual Studio and then followed by a year. The obvious problem is that when that year has come and gone, it now seems like it’s old. Like, that we, today in the year 2025 ,talk about Visual Studio 2022, that now seems like a very old version. You know, Visual Studio 2022 came out in November of 2021. So it’s like four years old, right? But it’s not four years old. We update it all the time. It is an absolute modern developer experience that you’re going to have using Visual Studio 2022, but that name that has the 2022 moniker on it does not make you feel that that’s the case.

There’s a bunch of reasons for why we have it and I don’t understand them all to be quite honest, but it has to do with how the licensing works, how support works, and subscriptions. You can buy a license, for instance, there’s different types of licenses, and so there might be a license that said, "hey, you can you can, use Visual Studio 2022 and all of its updates forever. "It’s like, "oh okay, that means that we have to have a new version." Otherwise, you’re basically saying, "you can buy Visual Studio once and now you have Visual Studio for free for the rest of your life," let’s say, right? If we didn’t adopt kind of a version number change or something like that. And so there’s a bunch of like weird license stuff that like that that comes into the picture.

And I hope that we have something to share that’s gonna be kind of exciting on that front later on, but we’re not quite ready to to talk about that yet. We don’t have it ironed out. That’s, kind of, a little bit of the history of why we have the year and why the year lingers on for several years at a time.

Now the the question about the 18, the Visual Studio 18: Well that’s simply because that’s the internal version number of Visual Studio 2026 is 18, is the 18th version of Visual Studio. And internally we always refer to the different versions of Visual Studio as that number. So we call it, we don’t even call it &quopt;Visual Studio," actually. We call it "Dev." "Dev18." "Dev17." Dev 17 is Visual Studio 2022. Dev 18 is Visual Studio 2026. So 18 is just our internal version number that we use. It was one that we considered. "Oh maybe we should just make it 18." But we’re gonna it 2026, and I think that’s a better better name anyways.

Kind of what people expect a little bit and we have more reasoning around it coming out shortly.

Jamie : Cool. Whilst you did talk about licensing and purchasing, it’s important to note that Mad says, you know, he’s not a lawyer. He is not a Microsoft lawyer. Please go double check your own licensing stuff by going and reading the licensing and stuff on the Visual Studio website, right? I don’t want people to to think, "oh wow! I can get a really sweet deal because Mads said something on a podcast," and he gets him in trouble, you know.

Mads : Yeah, I guess that’s a that’s a good caveat. I’m definitely not a lawyer. but I know that there’s a bunch of intricacies around it that, kind of, has in the past dictated the naming that we’re using. So It’s all intertwined and that’s the kind of the point I wanted to get across.

Jamie : Are there some things you can… ‘cause I mean we got talking initially about the public preview of Visual Studio 18; so like can you talk about that? Because if it’s a public preview, then you must be able to be.

Mads : Yes. So when this airs, whenever you want to share this, it has to be after the public preview release of Dev 18 of Visual Studio 2026, the preview one. I think we we just t we can just talk about it as if it’s out right now because at the time that people will hear it, it will be out.

Jamie : Yeah, sure.

Mads : So that’s gonna be the beginning of September.

Jamie : So then what are some of the knockout things that folks should be looking at when they’re looking at Dev 18 Public Preview? What are some of like the top maybe top three things that you’re like, "you should definitely do this when you install the new version."

Mads : I can tell you what what excites me about it, because everybody’s gonna have their own kind of interpretation of what’s important to them, right? But I can also relay a little bit about what we’ve heard so far.

So one aspect is performance. And you know that we’ve always had like a lot of people have had issues with performance when they’re dealing with, like, large solutions in particular. But performance is always something that people are giving us feedback on, that they want to see improved. And we’ve spent a long time and a lot of effort in looking into performance for this particular release. Anything from like solution loads to startup time to typing delays, open documents and so on. Moving things off the UI thread. So oftentimes when you’ve done an, taken an action in Visual Studio, you’ll see that Visual Studio is kind of frozen. Sometimes just for a tiny little bit, sometimes for several seconds, and maybe sometimes even longer. And that’s because whatever operation you’re doing, whatever the process is running, is doing that on the UI thread, which means the UI thread is busy, it cannot do anything else. And so we’ve spent a lot of time moving things off of the UI threat onto background threads. And, you know, this is something we’ve been doing for many years. But this time around we finally got around to some of the big items like solution load and all that that’s like more complex, and we’re able to offload that off of the UI thread. So you’re gonna find it to be much more responsive, faster. It’s just more kind of a fluent experience. So I think performance and fluidity is is a key thing for this release that I’m very, very happy about. And I really enjoy using it and I feel it every day, that difference. So that’s nice. So that’s one thing.

Another thing that I really like is the new UI. So if you’ve been on the preview of Visual Studio 2022 and you’ve enabled that preview feature called the new UI, you’ve seen this before, and it might not be new to you, but if you haven’t, then you’re gonna see that the UI looks very different. It’s using the new fluid UI design principles. It’s much more modern. It is kind of cleaned up. The spacing between things have been optimized. It’s just such a pleasure to look at and when you’re sitting in it all day long, it like makes a huge difference. It’s like just more relaxing. I’m really in love with all the new color themes that are in there. So we ship, in addition to light and dark, we have 11 additional color themes that we ship with. So there’s something for everybody. There’s a bunch of light themes and a bunch of darker themes in all sorts of different colors and whatnot. I just really enjoy some of these themes, to be quite honest with you. The one I prefer the most is the one called "Cool Slate." It’s kind of a dark blue-black kind of thing, and I don’t know. It’s just it’s just yummy.

We got new icons. Yeah, the whole UI has just gotten a big overhaul. So it just feels like much more modern. It feels much more, doesn’t feel maybe as dated. And so that’s nice. It’s nice feeling to have that you’re not sitting in something that seems old, right? It’s this one seems new, it’s fast, it’s delightful. It’s beautiful, and that’s what we hear, both when it comes to performance and the new UI.

These are the two things that we hear the most from people that have tried it so far. Like they are absolutely loving those two aspects. And this is not something we go out and ask. We don’t ask people, "hey, what do you think of the performance? And what do you think of the UI?" This is stuff that people just out of nowhere come and say, "man, this is the most beautiful Visual Studio ever," or whatever. Or, "oh man, it it’s so fast, it’s such a delight to use." I’m not exaggerating. This is what people tell us. These two things. But this is like probably 80% of the feedback we get is that people love the performance and the new UI. And it also happens to be my two favourite things. I would say that those are those are huge.

Another one I could call out, you said three, so let me let me throw one more out there: Copilot. You know, I use AI more and more, not just in Visual Studio, but like, you know, for everything: whenever I write emails, whenever I do PowerPoints, whenever I do, even if I do like social media stuff I have for, you know, I used Copilot to kind of help me out like with my wording and my grammar and all that type of stuff. I use it for deeper research, you know, and then I use it for Visual Studio as well. And the way that it works in Visual Studio 2026 is at a much deeper level than it was kind of possible before. Think of Visual Studio 2026 as a, and part of it is like a platform update or an infrastructure update that makes it possible for AI to get much broader knowledge about what’s going on in the IDE. Because we can integrate the Copilot in Visual Studio much deeper into all the different features from the test explorer, and code coverage to the output window to you know it you know whatever it might be. Some of the Azure publishing and you know, we can go really deep. And so that infrastructure piece is kind of the beginning to what we can do going forward with Copilot. And the first feature we have that take advantage of this deep integration is the Profiler Agent. And this is absolutely bonkers.

So you can simply go to the chat window in Visual Studio and you can ask. And by the way, this is, you know, you can use this for free if you have Copilot free. It doesn’t cost you a cent. You can say, "hey," you know, in the chat one, you can ask the profiler to optimize the performance of your app, your project. And it’s crazy. It will run profiling on your solution, on your executable. It will find out what the hot paths are, it will come up with recommendations to fix them. It will fix them and it will give you a new set of benchmarks to prove that it has a positive effect on the performance. It is absolutely crazy and I encourage you to go see some of the demos that Nate Karpinsky, who’s the lead engineering manager on on the Profiler Agent, that he’s been doing. It is so impressive. I use it all the time. I’ve been starting to use it on all my extensions for Visual Studio. And it’s a complete game changer because I don’t know a bunch of these techniques for how to properly, let’s say. optimize LINQ queries or how to do all these kind of, you know, if I figure out that there’s a hot path somewhere in my code that, "you hit this too many times," or whatever, or "do you you know you allocate too much memory in this, you know, string something, something?" Well, what is the correct course of action? How do I actually fix this? All right. And then also, how do I verify that the fix made a difference?

If you’ve never done profiling before, if this is new to you, if you don’t know the lower level of like how .NET works, let’s say, like what’s the difference between a let’s say a dictionary and a hash set. And what are the different variations of each that are more optimized for certain things, right? Those are things that the Profiler Agent will know and will tell you and and will help you implement. So I’m super excited for that, just simply because it opens up the door for something that to me I’ve never been able to utilize fully before. I’m now able to do something that I’ve always wanted to do but I’ve haven’t had the skills to do properly. If you know what I mean? It’s like there’s a difference between something like this and then, "hey, this is faster and more convenient,and I like using it the product better every day. I get a smile on my face." That’s one category of things. This is a category of thing where I can become a better software developer because this exists. Like it opens a door that wasn’t open to me before. I didn’t have time to look into it, I didn’t, you know, or time to like get to learn these techniques. And now I have it presented for me in a very easy way. So this is one of those very, very empowering things.

And you know, again, this is what I said in the beginning: this is the reason I do what I do is that feeling empowered. And so these is these are the two key aspects, right? I want to feel empowered. I want to be able to build fantastic software. And I want to do it with a smile on my face every day. And I think that is what Visual Studio 2026 is. That is what it is to me, and I think it will be to anyone listening to this as well.

Jamie : So if I can just double-check my understanding then: there is a feature in Dev 18, which we said was a Visual Studio (2026), that’s in the public preview, that is the Profiling Agent. I have found, maybe, I’ve found some code that I think is not very well optimized. I can say to the profiling agent, "hey, help me to optimize this" And because I’m using perhaps GitHub Copilot, and I’m maybe even using the free tier, it will go away and think about it and produce more optimized version of the code that I’ve just shown it, right? Is that… just to make sure I’ve understood, right?

Mads : Yep. That’s right.

Jamie : Wow.

Mads : Yeah. And it’s not, like, it’s not because it’s using its knowledge of like certain things about .NET and so it made educated guesses. No, no, no. It measures, it benchmarks, it fixes. It runs the benchmarks again. It will make some changes based on if it thinks it can do even more. And then, you know, it run the benchmarks again and so on. And so this is a kind of a scientific approach to improve the performance. It is not just because you could this is what you can do today, and I’ve done this very successfully as well. I’ve told Copilot, "hey can you, based on your knowledge, can you optimize the my code for any potential performance issues that it might have?" And it will go and do that and it’ll actually have pretty good results. But not for all projects. Sometimes you have to steer it more to what you want it to do. But it’s more like a general approach where it’s like, "hey, you know, you’re using LINQ here, maybe a for loop would have been better or a while loop or something." You know, and that’s helpful. That’s that’s super helpful. But it’s not the same as that scientific thing where we actually run it, figure out what the hot paths are, and then, you know, run benchmarks to figure out whether or not the the fix actually works instead of just estimating. And so that’s the true power here.

Jamie : Yeah. That, like in my head, that is something that I’m gonna… and maybe if I’m doing it manually, I’m going to write some code. I’m going to use one of the official .NET benchmarking things to benchmark that class, that method, that block of code, that unit of something. I’m then gonna sit and come up with a whole bunch of different ways that I could maybe change the code. And every time I change it, I’m gonna re-run those benchmarks myself manually. Whereas it sounds like, and I may be putting words in your mouth here, Mads, please stop me if I am. I can say the words to the effect of, "hey profiling agent, please optimize this block of code," provide it a little better context. Walk away and get a coffee. Then come back with my cup of coffee. And most of the optimization work is done and the science behind, and the measuring behind why that is more optimal is presented to me, right?

Mads : Yeah. I think it’s a little bit more, but it will ask for clarification if it needs to to kind of be more precise, too. And so yeah, you can walk away for a while and come back, you know, five minutes later or something like that. But sometimes it could also ask you, "hey, can you clarify was it this thing over here or that thing over there you were concerned about?" Or you know, there could be a little bit back and forth. Because sometimes we, you know, we’re gonna help steer it a little bit to do the right thing. But this has actually been so successful that what we’re starting to do now is that we’re starting to send pull requests to the big NuGet packages, the big .NET. libraries that people use; like, if you take a top hundred over NuGet packages, we’re starting to look at, "hey, how can we contribute back to the community by running the Profiler Agent on some of this?" And so Nick has been doing that and he’s gonna continue to do that.

First of all, it helps us make the feature better, the agent better at identifying things. But if we can help speed up libraries that are used by thousands, if not millions of apps and websites and APIs and whatnot out there, then like that would be a huge win for everybody, right? So we’re doing that. And then we’re also pointing it inward toward Visual Studio as well to have it go and explore the code base and come up with some some nice performance gains there as well. And so this is all very exciting stuff. And yeah that’s my number three of exciting things about Visual Studio 2026. But I got a lot more.

Jamie : Wow. And and that makes perfect sense for turning it around and pointing it at the Visual Studio code base, right? Because you said earlier on that there’s an that as a finger in the air estimate, there are around 200 million lines of code in Visual Studio. There is no way anyone can hold all of that context in their head. You know what agents are really good at? Tackling stuff like that. Alright, their context window isn’t big enough to handle all of it at once, but it can tackle that while you go do something else. That’s a genius idea.

Mads : Yeah. So we have very high expectations for that and that’s just kind of the first one that we’re looking into when it comes to that kind of deeper integration, but you can expect to see more. So what I mentioned was like this is the big infrastructure work that goes into here the first release of Visual Studio 2026. But then, you know, these monthly updates that are coming out, they’re gonna have these features that are then built on top of where the Profiler Agent is the first one of those features, but you’re gonna see more. It’s just it’s setting us up for a future that has all these capabilities that that that opens the door for all this tough stuff. So so that’s very exciting.

Jamie : That is crazy. Like look looking into the future which is the present when people are listening because time stuff is difficult. Like Hacktoberfest this year must have been amazing. If everyone’s using Visual Studio (2026) and using the profiling agent, the the the pull requests we would have seen. Which is in the future for you and I, Mads, but in the past for the listener, must have been amazing, right? It’s no longer, "just add your name to this readme and get a t-shirt." It’s, like, increase the efficiency of a whole bunch of different repos, right.

Mads : Yeah. Yeah, so I think one aspect of all this agentic AI within like the developer space is partly, it’s like you do things that you didn’t have bandwidth to do before. So it could be, "hey, you know, you have an issue tracker with a thousand items in it, right? Okay, there’s you can’t get to all thousands and so you have to prioritize. Well, you know, maybe for some of the simpler ones, you can simply just set off the agent to kind of do that and it’s not very costly in terms of code reviews." So I think there’s definitely like a story for that.

You know, I run a bunch of open source stuff and I get a bunch of, you know, I have over two hundred extensions for Visual Studio. And I get, you know, issues and pull requests and stuff all the time. Feature requests, so many of them. I, you know, I can’t handle all that. But I’ve been starting to just a assign some of these simpler things to the coding agent because it, you know, that’s the way I can scale myself and it’s easier for me. But I will say it depends. Like sometimes if there’s a certain complexity to it, then the code review itself can take as long time as implementing the feature myself. But you know, as I’m getting better at understanding some of these feature requests and how AI works, I’m also better at assigning it things that I know it can do kind of on its own. And so I think that’s one aspect. Like scale yourself, to a degree, so you become more efficient, you have higher velocity, let’s say.

Another aspect of it is: things that help you improve your skills. So I think the Profiler Agent is one of those areas where you don’t know how to do something, and now all of a sudden you do. Your capabilities grow. We hear this all the time. Like people really love the debugger in Visual Studio. It’s super powerful. But you also know that sometimes you run into some debug thing where you simply can’t figure out how to debug a certain scenario. It’s complex and whatnot. And there’s always that colleague that’s the go-to person when it comes to debugging, that understands all the low-level stuff that can get into WinDBG and and work from there, and see things that you simply can’t see because it’s like too low level, maybe. What if that could be you? Right? What if you no longer had to go to that colleague that debugger rock star, let’s say, right? What if that could now be you? And so by taking advantage of some of these you, kind of, start learning about, "oh, why is it that a while loop is faster than a like a certain type of LINQ query?" or whatever it might be. You start understanding how these things work. And you become a better developer from it. So profiling is one aspect, debugging is another, unit testing. You know, the list goes on and on. It could be any type of thing. And so I think those are the two aspects that are to me I think something that I use today, but I can see myself using more and more as they also become more capable and that we have more scenarios covered. So that has me very excited, those two aspects.

Jamie : Again, to your point about being empowered, right? I can, and I haven’t seen this part of the Visual Studio (2026) preview, so I’m just going on your description and a bit of my imagination, right? I can ask the Profiling Agent, I can ask the debugging agent, "why is this?" And it can probably tell, give me a little bit of information, right? It can say, "oh yeah, well, this is because, like you said, maybe this kind of loop is faster than that kind of loop, because…" and then, like you’ve literally just said, it then makes me a better developer because I then understand how the language is working, and maybe I understand how the CPU is working, or the the CLR or whatever. I understand how it all works in a slightly better way, right? And then I understand, "oh cool. This kind of thing is better than that kind of thing. In this instance because of these reasons." And then I have that more context knowledge. I have the more knowledge on how it all works. It’s yeah, it is. It’s that empowering. I I love it, Mads. I love it.

Mads : Yeah, that that’s exactly it to me, right? So there is that that kind of empowering thing.

Then AI it’s, of course I think we often think about it as a category on its own, but I feel it’s kind of just an extension of of what’s already there, of what an IDE is and what we expect from it. It’s kind of just the next wave of of that. So I don’t see it as a separate thing. But anyway, that AI, I think, is a is an important factor. You know, we’re also very, very keen on making sure that the fundamentals are as good as they can be. So we talked about performance already. We consider that a fundamental. But another fundamental is, you know, the paper cuts, features you expect from an IDE.

So let’s say if other IDEs out there, the competitors or whatnot, if they have certain features that you expect. "Oh, you know, it has existed for years." You expect all modern IDEs to have the same feature. Well, Visual Studio, we want to make sure that we have it in Visual Studio as well. It could be keyboard shortcuts, like adopting industry standard shortcuts. And, you know, there’s a whole bunch of things that we want to make sure that we get right. And so a lot of it comes from all the feedback that we get from people, you know, we get a lot of feature requests, we get a lot of bug reports. And we wanna make sure that, you know, we do as many of those as we can. We want to remove those paper cuts, make you as happy as possible. And so if you look back at the last twelve months, of all the bugs people have opened on us, we fixed almost 45,000 user reported bugs. That’s eighteen bugs that we fixed every single workday. And a lot of those are going into 18, going into 2026.

And when it comes to feature requests in the past twelve months, and this, by the way, these numbers are counting. They’re getting higher, right? The trend we have when it comes to user reported feedback is that the rate of which we are implementing them, are they going we’re trending upwards. So these numbers are only gonna go up. When it comes to feature requests, we’ve done 290 in the past year. So that’s 1.2 requested features that we’ve implemented every single workday in the past year. So some of it is small stuff. You know, things where you’re thinking, "hey, how can this… why is this relevant?" Some people might think that, right? And and we do get that, but everybody wants different things and people see different things.

So I have an example that I, kind of, like to use because it illustrates this pretty well. In 2026, we now have the line number margin over on the left side of your screen in the editor used to be pretty wide. Let’s say you only have three numbers in there because you didn’t have more than 999 lines in your file. The line number margin would still be wider. It would still be like it would have room for like five digits instead of just three. So why waste that space? So in the new world, it that line number margin is as small as it can be. So if you only have, you know, two digits, then it’s gonna be the width of two digits of numbers. So a lot of people they just shake their heads, like, "okay, who cares?" And then you have a bunch of people that are absolutely up in arms. They will say something like, "I had no idea I wanted this till I saw it." And and this is about these details. Some details matter to people, to some people, some details matter to other people. What they all share is that some details matter to everybody. We all have our pet peeves, we all have our paper cuts, we all have our things that we encounter that is unoptimized for our workflow or just our liking. And so when we get those feedbacks coming in, when we get those tickets opened up, these are the type of things we want to make sure that we fix as fast as possible, make everyone happy.

This is about what we call making Visual Studio as lovable as possible. So this is a tall order, of course, and like how do you make something lovable that has a you know, Visual Studio has a bunch of problems, like all software, but just the size of Visual Studio and the, you know, the category of app that it is: it’s for developers and developers are very particular, right? You know, we get a lot of, let’s say, negative sentiment about, "hey why is it slow?" or "why doesn’t this work or that work?" We want to make sure that, whenever we do something, we do it in the most lovable way. And we want people to have a smile on their face. We want people to wake up in the morning and be excited to get to work, open Visual Studio, and use, you know, C# or C++ to solve the problems of their business using Visual Studio and love what they do.

And that’s the goal of Visual Studio 2026. It’s the it’s the to create the most lovable developer experience. And I think we are as close that as we’ve ever have been to that And I can only see the business getting better and better with every preview we’re shipping, with every new feature we’re building, we’re getting closer to this. And I think the feedback tells that same story. So yeah, I’m very, very excited.

Jamie : Just just pausing for a second to talk about those numbers. One point two features per work day. That’s a heck of a clip. That’s very fast. That’s you know, you can talk about Agile, that’s agility.

Mads : Yeah. Yeah. It’s a pretty pretty great number.

You know that moment when a technical concept finally clicks? That's what we're all about here at The Modern .NET Show.

We can stay independent thanks to listeners like you. If you've learned something valuable from the show, please consider joining our Patreon or BuyMeACoffee. You'll find links in the show notes.

We're a listener supported and (at times) ad supported production. So every bit of support that you can give makes a difference.

Thank you.

Jamie : So speaking real quick on the on the feedback then: obviously when someone is using Visual Studio, there’s a feedback button. Inside of Windows, there’s a shortcut—if you don’t know it’s Windows and F—to submit some feedback, right? I believe the Windows and F button is just for Windows, but you can hit the, I believe it’s like an emoji-looking button in the top right hand corner. It’s been a while since I’ve had to do it, so it’s not something that’s top of mind, but you can always submit feedback.

So first off, folks who are listening in, you want to submit some feedback for the Visual Studio team, hit that button. It’ll take you through a wizard on how to do that. But then conscious that we’re all A) running low on time, but also B) I don’t want to give away any secret source that you have over there. Earlier in the season, we talked to Safia over on the ASP .NET team, and one of the things that we brought up was like giving and taking feedback from the user base, from the customers of yourselves, right? So like as part of the Visual Studio team, developers are your customers, right? Or are your users, whatever phrase you want to use.

So I’d be interested to know the experience, I guess, of separating the constructive from the less constructive, shall we say, feedback from developers. You know, you said, you didn’t use these words but you said like developers can be quite opinionated on what they expect and what they will see. You know, I have a feeling, and please correct me if I’m wrong, I have a feeling that by by default, in normal feedback terms, you’re probably gonna get more negative feedback than positive, right? "I expected this to work and it didn’t work. I am now sad." Versus, "this is awesome! Please go tell the developer that implemented this feature that they need a raise because this feature is amazing."

Like, yeah, is there a huge difference between the positive and negative feedback? And how do you, as a team, figure out constructive from non-constructive feedback? Because I feel like that’s some advice that all developers can take, not just to submitting their own feedback, but obviously dealing with bug reports and messages from users, right.

Mads : This is a fantastic question. Thank you for asking that. Yeah, that’s a really good one.

So yeah, most feedback is by nature negative. Not negative as in: it’s not like personal and they’re calling you names or anything like that, even though that happens. But it’s just, it’s more natural. People say, "hey, something is wrong or unexpected." We have recently, in the last three years or so, we’ve started to get feedback that is just positive. Like, "hey, thank you and the team for doing this," and, "thanks for like this is such a great thing." Or, "wow, Visual Studio." We never really got positive feedback out of the blue before unless we asked for it, like unless it was a part of a survey or something where people could type in, like a verbatim, you know, text, whatever. But we’ve started to see that. And I think that’s that’s part of this whole lovable software that, it situating that lovable software has a lot to do with listening really carefully to the users, treating everyone with respect, doing everything you can to accommodate what the users need and what they want. Like that’s two different things.

Anyway, so we see a lot of that positive feedback coming in for the kind of for the first time in the past few years. The negative feedback, the way we deal with it, because, you know, when you file a bug, it’s never like a happy experience or a happy moment that make you file a bug, right? It’s usually because something negative happened. But the way that we look at it, at least the way we want to look at it, is that every piece of feedback you give is a present. It means you care enough. If you didn’t care about Visual Studio, you wouldn’t write us. You wouldn’t fill out a form saying that, "hey, that, you know, there’s an issue with the intelligence in this particular situation," whatever it might be. It’s only if you really care that you do that. And so the realization that people that open bugs actually do you a favour changes a lot of how you see and value that, let’s say, quote unquote negative feedback. Because it’s not negative feedback, it’s a gift that the bug exists whether you know about it or not. So we we’d rather know about it. And thank you for telling us. And so that’s kind of the mental model I think that you need to have. when it comes to having like an open issue tracker and you let people fill it up and vote for other issues and feature requests and whatnot.

Now the way we kind of prioritize around those bugs, we use various different things to prioritize like what what makes us fix a bug that you’ve opened? Well one is: does it have a lot of votes? That’s something we look at. Of course, something that has a lot more votes is probably has a higher impact. Like it affects more people. And that’s something we always look at, like the size of the impact, like the amount of people that is affected. But then also the severity. How severe is this? Is it just a nuisance? Is there a workaround or is it, you know, is it blocking? Can you no longer do your job because of this bug? So impact and severity are so. And so so when we try to figure out, "well, what is the impact, what is the severity?" So one is like votes. Another one could be paying customers versus version the customers that use it for free. How many of those votes, and comments, and interactions on each of these tickets do we see? I think everybody would expect that, "hey, if you pay for software, you also have a different expectation to any bugs that you find being fixed," right? I think that’s, like most people would would think so. And so with Visual Studio is that’s absolutely true. Like if you pay for Visual Studio, you actually get priority bug fixing and feature request considerations.

So anyway, so that’s that’s one way we look at it. We also look at are there anything that we’re doing in this area anyway? Are we opening that part of the code? We might as well fix the bug when we are in there anyway. So even though it’s a small bug with little you know little impact, let’s say, "hey, we’re we’re doing some work over here anyway. Let’s just fix this." That could be another consideration. There’s not like one clear answer. Every team is a little bit different in how they look at it. But roughly it’s an assessment of impact and severity that we’re looking at.

And then what can be hard sometimes is that people will talk up a big game. They will say, "hey, this is the you know the the biggest issue ever. I can’t do anything. I’m totally blocked." And then you realize it’s such a niche scenario that pretty much only affects this one person. But it could take you a long time to find out that, "hey this might not be as severe as this person makes it out to seem." And we we have people, sometimes, that are absolutely relentless that, you know, they have an issue that affects them and and other people too, but there is a workaround. You’re not blocked. It’s an inconvenience. It’s extremely expensive for us to fix it. And just the investigation alone could mean that it would be other teams. It might be in Windows, might be in, you know, Edge or, you know, some other part of Microsoft, let’s say, and and it just becomes this, it balloons into this huge thing. And it doesn’t seem like that when you’re on the outside. And so you get frustrated and you keep like hammering on social media and commenting and so on. And so how do you then see kind of that kind of false impact or false severity out of the you know. That’s a hard thing and it’s you know, experience helps with that. But there is no clear answer that this is how we always do it in this in this situation. So I would say that’s the kind of subjective. Each team is different, each ticket is different, and that that’s the name of the game.

Jamie : I wonder if you could, I mean it feels I feel like this goes to all development everywhere, but if I’m in Visual Studio, I hit a problem. And I hit the feedback, and I wanna submit something that helps you all to repro the problem I’ve just had, to make it easier for you to figure out to triage to do whatever process. What are some of the things that I should maybe be making sure that I include in those bug reports? Like, do I want to include repro steps? Can I give you a code sample? You know, things like that, right? Or is Visual Studio doing some stuff behind the scenes to try and capture that information when I hit the feedback button, right? Like, if you could give one piece of advice to users of Visual Studio for when they report a bug, what’s that piece of advice? Like how do they make sure that you can repro that and have "the best time ever" with figuring out what that bug is.

Mads : Yeah, that’s a great question.

So the there really is no difference between how you yourself would get a bug report from your users, right? Or your testing team or whatever it is, if you’re a software developer. Like it’s the same for us. So when you do the you go into Visual Studio, go to the help menu and send feedback from there, we do collect logs and traces and stuff. But sometimes that doesn’t give us the entire picture. And so to improve the chances of a fast bug fix is that you have, you know, repro steps. If you can have a code sample or if you can do like a minimal reproducible project, for instance. Like can you isolate the issue into like, "hey, here’s a code file," or "here’s a simple ZIP file with a simple project inside," that if you open a Visual Studio and you, you know, you follow your repro steps, you will see this issue. That is so much easier to deal with because if we cannot reproduce the issue and you don’t really give us anything. Then we’ll have to reply back. We’ll have to kind of send the bug back to you and say, "hey, we need more information. Can you do this and that?" And now, you know, we’ve already used some time here. So that might be a week later, and then maybe it takes you a week to follow up, and then we still can’t reproduce it, and the dance go back and forth, and then it sometimes it fizzles out. And so the best chance of this is to have as strong of a repro step that guarantees that we can reproduce the issue.

Like if we can’t reproduce it, we can’t fix it. Just like in your software world, right, when you get a bug, it’s the exact same thing. That’s the key

Jamie : Right. Okay. And and obviously remember to hit that feedback button to to give both positive experiences and not so positive experiences, right.

Mads : Well, you know, that feedback is is we cannot just have it there for sending like issues and suggesting features. If you have anything positive to say, feel free to do that too. It’s always nice to hear. Or on Twitter, on our blog post, like YouTube. We have so many ways you can give feedback if you want. But yeah, we of course we always, everybody likes to hear when they do something well.

I actually do every now and again, whenever I see some nice comment or something, I take a note of it. And then every now and again I send out an email to the team with like all these different tweets and YouTube comments and whatever that have been positive. as kind of a morale boost or kind of like a, "hey look what people say. They’re happy about Visual Studio," and I sent that out and you know the team really, really loves that. And and I’m guessing like, hey, if you’re listening to this, that might be something you want to consider for your team as well. This is something people really like. Like one thing is that when you tell your colleagues that you really appreciate the feature they’ve been building or whatever. It’s different when it’s the external customers, the users that say it. It kind of weighs differently. It feels different. So I can recommend doing that.

Jamie : Awesome. That’s a fantastic bit of advice.

So somebody’s listening in and going, "right, remind me again how do I get this preview and what that kind of stuff. I just go to visualstudio.com and push the preview button?"

Mads : Yeah, visualstudio.com, hit the download button. Preview is among the options there. And so grab the Visual Studio 2026 preview. That’s it.

Jamie : Awesome.

What about, you know, you said earlier on you like to capture positive sentiment on Twitter, on YouTube, and on the blogs. So is it just literally a case of have a look for Mads or the Visual Studio team, on Twitter and just say, "hey, @mads, this is awesome. And I did this amazing thing, and look at how cool it is. Can’t believe it." Send. Like is that the kind of thing you’re after.

Mads : Yeah, or @visualstudio or yeah, yeah. Yep. Absolutely. That always feels good. The team absolutely loved that. So if if you have genuine praise to give, we’re all ears. But also in the other end, like if you have negative things, like if you have things you want us to improve on, like we really want to hear that too. So any feedback, we welcome it.

Jamie : Amazing. Amazing. Well, Mads, I have had an absolute blast chatting with you today, learning about some of the new features coming in the next version of Visual Studio, like the profiling agent and the debugging agent and all that kind of stuff. AI stuff and oh it’s so good. But also your wonderful advice about treating bug reports as a present, as a gift. That, just, it’s opened up a whole new way of thinking about my own daily software development practice stuff. What I thank you for that, I really appreciate you sharing that. It been amazing chatting with you. Thank you ever so much.

Mads : Thank you. Thank you so much for having me on. And I feel like we just scratched the surface. We didn’t get to talk about C# 14 or .NET 10 or anything like that. So we’ll have to save that for another time. I hope that your listeners enjoyed the show and and will enjoy Visual Studio 2026.

Wrapping Up

Thank you for listening to this episode of The Modern .NET Show with me, Jamie Taylor. I’d like to thank this episode’s guest for graciously sharing their time, expertise, and knowledge.

Be sure to check out the show notes for a bunch of links to some of the stuff that we covered, and full transcription of the interview. The show notes, as always, can be found at the podcast's website, and there will be a link directly to them in your podcatcher.

And don’t forget to spread the word, leave a rating or review on your podcatcher of choice—head over to dotnetcore.show/review for ways to do that—reach out via our contact page, or join our discord server at dotnetcore.show/discord—all of which are linked in the show notes.

But above all, I hope you have a fantastic rest of your day, and I hope that I’ll see you again, next time for more .NET goodness.

I will see you again real soon. See you later folks.

Follow the show

You can find the show on any of these places