Roadmap for AI in Visual Studio (February)


After a busy January (catch up here), we’re shifting focus to reliability and refinement. This month is about tightening core workflows, improving agent stability, and building on the MCP foundations we’ve been laying.

These are active areas of work, not delivery commitments. Upvote the features that matter most to you.

Agent Mode & Coding Agents

Reliability is the priority this month. We’re raising the floor on agent-driven scenarios with:

Planning Agent

First steps toward a dedicated agent for multi-step task planning and execution.

Copilot SDK & Platform Integration (Experimental)

We’re also beginning early work to better integrate the Copilot CLI into Visual Studio Copilot.

Model Context Protocol (MCP)

MCP keeps external tools and services connected to VS in a governed, scalable way. February focus:

Models & Context Management

Under-the-hood work to keep Copilot fast as context grows:

Copilot experience in Editor

Smoother Copilot integration with existing editor behavior:

We’re excited for you to try these improvements as they roll out. As always, feedback is incredibly important—please upvote or comment on the linked Developer Community items so we know what matters most to you.

Thanks for continuing to build with us.

February 2026 Insiders (version 1.110)


VS Code Insiders banner

Last updated: February 5, 2026

These release notes cover the Insiders build of VS Code and continue to evolve as new features are added. To try the latest updates, download Insiders.
To read these release notes online, go to code.visualstudio.com/updates.

You can still track our progress in the Commit log and our list of Closed issues.

These release notes were generated using GitHub Copilot and might contain inaccuracies.

Happy Coding!


February 5, 2026

  • Add setting to control the scroll behavior in the Settings editor, offering continuous or paginated. Paginated will restrict the settings shown to only those in that category. #291391

February 4, 2026

  • Improved chat askQuestion carousel now has improved accessibility. ARIA labels have been added, keyboard focus can be moved to the container, and focus no longer automatically moves to the first response. A new command and keybinding is available to focus the first response in screen reader mode. #292917

  • Add support for the text blink attribute in the integrated terminal. #292550

  • Add support for color scheme reporting in the integrated terminal, allowing programs to query the terminal’s current color palette. #290919

  • Populate the Find control input in the integrated browser’s with the currently selected text on the page, matching standard browser behavior. #291378

  • Show download progress information when downloading a VS Code update. #277330

February 3, 2026

  • Terminal performance has been improved with updates to xterm.js, including optimizations for rendering and processing. #292572

  • Respect session list filters in the agent sessions Quick Pick and welcome page. If you have specific agent types filtered out from the session list, they will also be excluded from the Quick Pick when switching sessions. #291603

February 2, 2026

  • Improved screen reader accessibility for quick input dialogs. ARIA attributes are now dynamically set only when the list is active, preventing redundant announcements. The Go to Line dialog (Ctrl+G) now provides proper screen reader announcements for characters typed and list item navigation. #292353

  • Selecting Hidden terminal in the terminal dropdown now directly opens the terminal when there is only one hidden terminal, instead of showing a quick pick menu. #291884

  • Fixed an issue where the terminal output panel in chat would auto-collapse on command success even when manually expanded. The panel now respects the user’s manual expand state and remains expanded after successful command completion. #291120

January 30, 2026

  • The chat question carousel UI now uses a list-style selection interface similar to QuickPick instead of native radio buttons and checkboxes. This provides better visual consistency with other VS Code selection UIs across platforms. #291328

We really appreciate people trying our new features as soon as they are ready, so check back here often and learn what’s new.

visual studio – Generating C# Rest API Client from swagger.json


I am attempting to create a Rest API Client from the Swagger json file generated by Ambari. Unfortunately the json uses # in item names:

  "get": {
    "tags": [ "Actions" ],
    "summary": "Get all action definitions",
    "description": "",
    "operationId": "ActionService#getActionDefinitions",       <<<<<
    "produces": [ "text/plain" ],

I have tried AutoRest, Nswag, Swagger and Open API Rest API Client Generators.
Nswag is the only one that does not crash and burn.
However it’s output is unusable because the ‘#’ characters end up in the c# names.

I end up with lines like…unusable:

System.Threading.Tasks.Task<System.Collections.Generic.ICollection<ActionResponseSwagger>> ActionService#getActionDefinitionsAsync(string fields, string sortBy, int? page_size, string from, string to);

Is there a work around to this issue ?

c++ – VisualStudio – Address Sanitizer – ASAN – not warning about memory leak


I am having trouble getting Asan to pick up on heap memory not being freed.


int main() {

    int* arr = new int[10];
    // arr[10] = 5; // Asan will warn me about this invalid access

    // Asan says nothing about the arr I did NOT free
}

I have configured Asan for Visual Studio 2022 as described here: https://learn.microsoft.com/en-us/cpp/sanitizers/asan?view=msvc-170#ide-msbuild

I have tried both the Visual Studio UI version of running Asan by running the debugger and the command line version of build the executable and then running it. Neither mention the memory not being freed.


Is it not possible ot get Asan to warn about a memory leak like this?

Performance improvements to MEF-based editor productivity extensions


If you use editor productivity extensions for Visual Studio 2026, there’s good news—they can now load faster! Extension developers with existing MEF-based editor productivity extensions should read this blog to learn about recent changes and how they might be affected. 

We introduced VisualStudio.Extensibility to simplify the creation of Visual Studio extensions for developers. Previously, handling threads in VSSDK-based extensions was often difficult, requiring knowledge of thread affinity and even the ins and outs of COM just to avoid freezing Visual Studio. The new extensibility model abstracts these technical details away seamlessly. 

Despite this advancement, we recognize most Visual Studio extensions still use VSSDK, so we’re striving to make targeted improvements there as well – especially regarding performance. For Visual Studio 2026, we’ve added the ability to load MEF-based editor extensions on a background thread, which significantly speeds up startup times for users. A major highlight of Visual Studio 2026 is its improved performance, and the proposed change we’re making to MEF is just one of many enhancements planned to make it even faster. We hope you’ll be pleased with the results. 

What changed? 

Visual Studio editor components use the Managed Extensibility Framework (MEF), which requires that objects be constructed in a free-threaded manner. Despite official MEF guidelines, we’ve often loaded components on the UI thread, resulting in many extensions relying on this behavior and limiting our ability to enhance startup performance. 

With Visual Studio 2026, we’re shifting to a free-threaded model, loading MEF components on background threads. This means extensions with UI thread dependencies might fail to load. We’ve been rigorously testing this approach in recent Visual Studio 2022 updates, and we are aware that some extensions that expect to load on the UI thread will fail to load with this optimization. To support extension developers through this transition, we’ve provided a setting and an analyzer that allows you to experiment with background loading and detect if your extension could be impacted by this change before we push it out more broadly. This initiative reflects our commitment to reducing disruptive changes and help extenders adapt when updates are necessary for the overall improvement of the product. 

Does it impact my extension? 

To help extension developers better detect if this change impacts you, we created an analyzer to identify potential issues. We hope that this will give you the opportunity to bring your extension in compliance with MEF rules, so that your extension can also get a startup performance boost like the rest of Visual Studio 2026. 

The example below shows the analyzer running and reporting access to the Microsoft.VisualStudio.Shell.ThreadHelper  and DTE2.StatusBar require UI thread. 

Picture1 image 

 To use the analyzer, add a reference to the latest version of the Microsoft.VisualStudio.SDK.Analyzers package: 

<PackageReference Include="Microsoft.VisualStudio.SDK.Analyzers" Version="17.7.98" PrivateAssets="all" />

To validate your extension can adapt to this change, enable the Preview Feature flag “Initialize editor parts asynchronously during solution load”. 

Picture2 image

When debugging, you may set a breakpoint in MEF part constructors and evaluate System.Threading.Thread.CurrentThread.ManagedThreadId. If it’s different than 1, then your code executes on the background thread.  

Picture3 image

Call to action 

Loading MEF parts on a background thread is essential for improving Visual Studio’s performance, and we have gradually enabled this change in Visual Studio 2026. We recognize that code changes can be inconvenient, so we’ve made it straightforward to spot and resolve any issues. To see examples of removing UI thread affinity, please see our documentation or a sample PR on how we made this change ourselves.  

We want to hear from you! 

Thank you for sharing your issues and suggestions with us, and we hope you’ll keep providing feedback about what you like and what we can improve in Visual Studio. For those new and experienced to extending Visual Studio, we invite you to visit our documentation to learn more, or watch the video series on Visual Studio Toolbox where Visual Studio engineers take you through how to build extensions using our samples on GitHub. Feel free to share feedback with us via Developer Community: report any bugs or issues via report a problem and share your suggestions for new features or improvements to existing ones. If you want a closer engagement with other partners in the ecosystem, please visit our GitHub repo to report issues as well. 

Stay connected with the Visual Studio team by following us on YouTube, Twitter, LinkedIn, Twitch and on Microsoft Learn. 



c# – Custom WPF Window ignoring specific keystrokes


I’m working on a Visual Studio Extension that creates a popup WPF Window, the window does have a TextBox in which can be input text.

The problem I’m facing is: Whenever I have the TextBox focused and send Backspace/Ctrl + A or Esc to it, the keystrokes goes to whatever document window I had active before instead of the TextBox.

In the gif: I have the TextBox focused it recognize normal keystrokes like a-z, but when i send Ctrl+A to it, it goes to the document window in the background, same thing for Backspace, it erases things in the document instead of the TextBox which is active.

I have created a minimal reproducible example, the code can be found here:
https://github.com/jinjiere/VSExtension

A similar issue related to these keystrokes:
https://developercommunity.visualstudio.com/t/Issue-where-backspace-ctrlz-and-other/11023655?ref=native&refTime=1769989905247&refUserId=67e5f4a0-c9fb-6b2b-9ad6-7f2145a23b45

I’m not sure if its a VS bug, I have also report it here: https://developercommunity.visualstudio.com/t/Custom-WPF-Window-ignore-specific-keystr/11037258

visual studio – “Add” button disabed when creating a view


I want to generate a view or partial view from actionby clicking “Add
View” button. But as you can see the button is disabled and I cannot
generete anything.

Actually, your Add button is disabled because you have either removed model class /templete value or haven’t selected anything which causing the issue.

Most importantly, While selecting view you should take either you should select context model or if there is not relevant model class it should select to Empty or without model from the dropdown, other than, your Add button would be disabled.

I have reproduced your issue accordingly as you can see down below:

enter image description here

How to resolve:

You can follow below steps to include your view:

enter image description here

Output:

enter image description here

Note: Please refer to this official document if you would like to know more details.

.net – Using a common library which contains MEF exports in multiple Visual Studio extensions


I am building a Visual Studio extension which uses a 3rd-party library (MonoDevelop.Xml to be specific). The library contains some MEF components intended to be used together with my custom components. So I have added the library into my VSIX manifest:

<PackageManifest Version="2.0.0" xmlns="http://schemas.microsoft.com/developer/vsx-schema/2011" xmlns:d="http://schemas.microsoft.com/developer/vsx-schema-design/2011">
    <!-- ... -->
    <Assets>
        <!-- ... -->
        <Asset Type="Microsoft.VisualStudio.MefComponent" d:Source="Project" d:ProjectName="%CurrentProject%.Xml.Editor" Path="|UnityModStudio.RimWorld.Xml.Editor|" />
        <Asset Type="Microsoft.VisualStudio.MefComponent" d:Source="Project" d:ProjectName="MonoDevelop.Xml.Editor" Path="|MonoDevelop.Xml.Editor|" />
    </Assets>
</PackageManifest>

So far, so good. I implemented a custom IAsyncCompletionSourceProvider in the UnityModStudio.RimWorld.Xml.Editor project and got my custom completions working as intended.

Then I decided to install the MonoDevelop.MSBuildEditor extension which also uses MonoDevelop.Xml into the experimental instance to see how some features should work and found that both extensions are not working. I found that I can make both extensions work together by removing the

<Asset Type="Microsoft.VisualStudio.MefComponent" d:Source="Project" d:ProjectName="MonoDevelop.Xml.Editor" Path="|MonoDevelop.Xml.Editor|" />

line from my VSIX manifest, but then my extension stops working when MonoDevelop.MSBuildEditor is disabled.

What can I do on my end to make both extensions work together, but independently?

c# – Creating RDLC report in ASP.NET Core Web API


Thought it might save people a lot of trouble if they knew a bad solution to avoid. I follow up with something that seems to be working.

VS2022. .netCore 8.0. Already had a WebAPI project to which I wanted to add an rdlc report.

Had the same issue, and worse. Not sure how, someone at work claimed he was able to create a new rdlc but the steps he gave never worked on anyone elses’ machine. So we just copy pasted the rdlc file he created and tried working on it from there.

The DataSet/DataSource dropdowns wouldn’t work consistently. Wouldn’t work at all unless our classes had primitive data types only and they were changed to interfaces with implementations. If you edited a class associated with a dataset that had been working, it would stop working.

I started a .netcore windows form app, and all the usual rdlc functionality started working. Much the same seems true for a standalone reporting project. I wrapped up teh classes I needed from my api into a Class LIbrary and imporfted into the reports project. So far so good. I wrap up my Data Access Layer and should be able to use that to generate the report. Then import that as a Project Reference

Not sure if this is is related, but Microsoft Reporting Services doesn’t seem to be compatible with .net 8.0. Was thinking of sorting that out, but since I have something workable, I’m avoiding it.

asp.net core – Cannot start debug session in Visual Studio due to SSL cert missing or being out of date


I have an ASP.NET web application that has been working fine when pressing F5 to start a debug session in Visual Studio. Last Friday (January 23) I started getting this exception:

System.InvalidOperationException: ‘Unable to configure HTTPS endpoint. No server certificate was specified, and the default developer certificate could not be found or is out of date.
To generate a developer certificate run ‘dotnet dev-certs https’. To trust the certificate (Windows and macOS only) run ‘dotnet dev-certs https –trust’.
For more information on configuring HTTPS see https://go.microsoft.com/fwlink/?linkid=848054.’

It references app.Run(); in Program.cs. Starting a debug session by opening the “Debug” menu and choosing “Start Debugging” results in the same error (not that I expected any different).

  1. I opened a PowerShell window as an administrator, and went with the Nuclear Option:

    Get-ChildItem -Path Cert:\CurrentUser -recurse | where { $_.Issuer -match 'localhost' } | remove-item
    

    Just get rid of all localhost SSL certificates.

  2. Closed Visual Studio, and ran git clean -fdx in the root folder for my Visual Studio solution.

  3. Reopened Visual Studio, and pressed F5 again.

  4. It prompted me to create and install 2 SSL certificates, and mark them trusted, which I did.

  5. The application died again at app.Run() with the same exact error.

  6. Next, I restarted the computer, and then repeated steps 1-5. Got the same error.

Just now I repeated steps 1-5 (a week later) and get the same error. I ran the following PowerShell command to list the expiration dates for all localhost SSL certificates:

> Get-ChildItem -Path Cert:\CurrentUser -recurse | where { $_.Issuer -match 'localhost' } | select NotBefore,NotAfter

NotBefore            NotAfter
---------            --------
1/30/2026 4:37:58 PM 1/30/2027 4:37:58 PM
8/26/2025 8:58:28 AM 8/25/2030 8:00:00 PM
1/30/2026 4:37:58 PM 1/30/2027 4:37:58 PM

I ran these commands after 4:40 PM EST, so the certs should be valid. Just listing the localhost certs provided this:

> Get-ChildItem -Path Cert:\CurrentUser -recurse | where { $_.Issuer -match 'localhost' }


   PSParentPath: Microsoft.PowerShell.Security\Certificate::CurrentUser\Root

Thumbprint                                Subject
----------                                -------
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX  CN=localhost
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX  CN=localhost


   PSParentPath: Microsoft.PowerShell.Security\Certificate::CurrentUser\My

Thumbprint                                Subject
----------                                -------
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX  CN=localhost

Program.cs

(after removing all our application-specific stuff and I’m still able to replicate the error)

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddControllersWithViews();
builder.WebHost.UseStaticWebAssets();

builder.Services.AddMvc(options => options.SuppressImplicitRequiredAttributeForNonNullableReferenceTypes = true)
    .AddRazorOptions(options 
        => options.ViewLocationFormats.Add("/Views/Emails/{0}.cshtml"));

var app = builder.Build();

app.UseDeveloperExceptionPage();
app.UseHttpsRedirection();
app.UseStaticFiles();
app.MapStaticAssets();
app.UseRouting();
app.MapStaticAssets();

app.MapControllerRoute("default", "{controller=Home}/{action=Index}/{id?}")
    .WithStaticAssets();

app.Run();

launchsettings.json

{
  "$schema": "https://json.schemastore.org/launchsettings.json",
  "profiles": {
    "http": {
      "commandName": "Project",
      "dotnetRunMessages": true,
      "launchBrowser": true,
      "applicationUrl": "http://localhost:5063",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Local"
      }
    },
    "https": {
      "commandName": "Project",
      "dotnetRunMessages": true,
      "launchBrowser": true,
      "applicationUrl": "https://localhost:7072;http://localhost:5063",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Local"
      }
    }
  }
}

The exception message gives a command to trust the certificates, which I ran:

> dotnet dev-certs https --trust
Trusting the HTTPS development certificate was requested. A confirmation prompt will be displayed if the certificate was not previously trusted. Click yes on the prompt to trust the certificate.
Successfully trusted the existing HTTPS certificate.

But I continue getting the same error.

Here is the full log in the terminal as the debug session starts:

dbug: Microsoft.AspNetCore.Watch.BrowserRefresh.BlazorWasmHotReloadMiddleware[0]
      Middleware loaded
dbug: Microsoft.AspNetCore.Watch.BrowserRefresh.BrowserScriptMiddleware[0]
      Middleware loaded. Script /_framework/aspnetcore-browser-refresh.js (16491 B).
dbug: Microsoft.AspNetCore.Watch.BrowserRefresh.BrowserScriptMiddleware[0]
      Middleware loaded. Script /_framework/blazor-hotreload.js (799 B).
dbug: Microsoft.AspNetCore.Watch.BrowserRefresh.BrowserRefreshMiddleware[0]
      Middleware loaded: DOTNET_MODIFIABLE_ASSEMBLIES=debug, __ASPNETCORE_BROWSER_TOOLS=true
fail: Microsoft.Extensions.Hosting.Internal.Host[11]
      Hosting failed to start
      System.InvalidOperationException: Unable to configure HTTPS endpoint. No server certificate was specified, and the default developer certificate could not be found or is out of date.
      To generate a developer certificate run 'dotnet dev-certs https'. To trust the certificate (Windows and macOS only) run 'dotnet dev-certs https --trust'.
      For more information on configuring HTTPS see https://go.microsoft.com/fwlink/?linkid=848054.
         at Microsoft.AspNetCore.Hosting.ListenOptionsHttpsExtensions.UseHttps(ListenOptions listenOptions, Action`1 configureOptions)
         at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.AddressesStrategy.BindAsync(AddressBindContext context, CancellationToken cancellationToken)
         at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServerImpl.BindAsync(CancellationToken cancellationToken)
         at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServerImpl.StartAsync[TContext](IHttpApplication`1 application, CancellationToken cancellationToken)
         at Microsoft.AspNetCore.Hosting.GenericWebHostService.StartAsync(CancellationToken cancellationToken)
         at Microsoft.Extensions.Hosting.Internal.Host.<StartAsync>b__14_1(IHostedService service, CancellationToken token)
         at Microsoft.Extensions.Hosting.Internal.Host.ForeachService[T](IEnumerable`1 services, CancellationToken token, Boolean concurrent, Boolean abortOnFirstException, List`1 exceptions, Func`3 operation)

I’m stumped. This was all working for a long time, and the Visual Studio workflow that creates and trusts the developer certificates the first time you start a debug session isn’t working either.

I can start the application fine using HTTP, so I have a workaround. Regardless, how can I fix this so starting a debug session in Visual Studio successfully spins up my application using Kestrel running on HTTPS?


As a backdrop to this, the day I noticed this start happening is also the same day some Windows updates were installed, and now I cannot power my machine down – KB5074754, KB5074753, and KB5073455. Today I installed KB5078132, which should include the patches to this shutdown problem from KB5077744 and KB5077797, however my machine still does not power down properly; it just restarts. I’m not sure if my SSL issue in Visual Studio has anything to do with this, but just in case it does, this is also going on at the moment.