A Tour of Visual Studio 2026: Workloads, .slnx, Solution Explorer and Code Search

Version note: The commands in this post were run with .NET 10 SDK (Software Development Kit) 10.0.402 and, for comparison, .NET 8 SDK 8.0.419. Visual Studio 2026 (18.11) runs only on Windows, so this IDE (Integrated Development Environment) was not run on this machine (macOS); the Installer, Solution Explorer, Code Search and 18.11 features are described from the Microsoft Learn documentation and the official release notes. All .slnx and .slnf output comes from real dotnet runs.

Guess First

The Bookstore.sln in the Bookstore repo is 71 lines long, full of project-type and per-project GUIDs (Globally Unique Identifier) plus separate Debug/Release mappings for every project. Someone on the team converts it to .slnx in Visual Studio 2026 and commits it. The next morning two things happen: a CI (Continuous Integration) agent that builds an old release branch and only has the .NET 8 SDK installed turns red, and on one developer's machine dotnet build fails before it even starts. Do you think both failures have the same cause? And do you need Visual Studio to move to .slnx?

In this post we tour Visual Studio 2026 through the eyes of a .NET + Angular developer: what to install in the Installer, what the new update model means, how .slnx and solution filter files work, how to get more out of Solution Explorer and Code Search, and what arrived in 18.11.

The Installer: Workloads, Components and .vsconfig

The Visual Studio Installer installs through workloads and individual components. A workload is a ready-made bundle of the components a scenario needs. For a .NET + Angular team a single workload is usually enough: "ASP.NET and web development" (Microsoft.VisualStudio.Workload.NetWeb). According to its description it brings ASP.NET Core, HTML (HyperText Markup Language), JavaScript and container tooling including Docker. If you build WPF (Windows Presentation Foundation) or WinForms you add ".NET desktop development" (Microsoft.VisualStudio.Workload.ManagedDesktop); if you deploy to Azure, "Azure development" (Microsoft.VisualStudio.Workload.Azure). In 18.4 the JSON (JavaScript Object Notation) editor moved into the Core Editor; you no longer need the web workload just to edit JSON.

The way to end "that template doesn't show up for me" conversations on a team is to put the installation into a file. In the Installer, More > Export configuration on the product card writes the installed workloads and components to a .vsconfig file. You can also write it by hand:

{
  "version": "1.0",
  "components": [
    "Microsoft.VisualStudio.Workload.CoreEditor",
    "Microsoft.VisualStudio.Workload.NetWeb"
  ]
}

If you put this file in the solution's root folder, Visual Studio detects missing components when it opens the solution and offers to install them. On a new machine you use it with the edition's bootstrapper; the command in the docs looks like vs_professional.exe --config "C:\myconfig.vsconfig" --passive --wait. To add components to an existing installation you need the modify command, not update; update only updates what is already installed. Extensions can be listed in the file too, but only extensions published on the Visual Studio Marketplace trigger the automatic "missing" detection.

Side by Side with VS 2022 and the New Update Model

Visual Studio 2026 can be installed side by side with Visual Studio 2022 on the same machine; each installation needs a unique combination of major version, edition and update channel. By the same logic you can install the Insiders channel next to the Stable one. The docs' warning matters: extensions are not migrated automatically, because not all of them are compatible.

The real change in the update model has two parts. First, the Stable channel gets a feature update every month; the version number has the form 18.<Minor>.<Servicing> and the minor goes up by one each month (18.0 in November 2025, 18.11 in October 2026). Second, Microsoft decoupled the IDE from the build tools: several versions of toolsets such as the .NET SDK and the MSVC (Microsoft Visual C++) compiler can sit side by side in an installation, and while you update the IDE every month you move your project's compiler or SDK forward on your own schedule. According to Microsoft's plan, annual releases arrive every November with the new .NET and update the previous year's installation in place, not as a new side-by-side product as with Visual Studio 2022.

On the .NET side, the practical counterpart of this decoupling is the global.json we saw in the previous post: even if the IDE updates monthly, the repo itself says which SDK to build with.

.slnx: The New Solution Format

In the .NET 10 SDK, dotnet new sln produces .slnx by default; Microsoft Learn documents this as a breaking behavioral change. If you want the old format you write dotnet new sln --format sln. To see the difference, we first added the same three projects to an old-format solution:

$ dotnet new sln -n Legacy --format sln
The template "Solution File" was created successfully.
$ dotnet sln Legacy.sln add src/Bookstore.Api src/Bookstore.Core tests/Bookstore.Tests
Project `src/Bookstore.Api/Bookstore.Api.csproj` added to the solution.
Project `src/Bookstore.Core/Bookstore.Core.csproj` added to the solution.
Solution ./Legacy.sln already contains project src/Bookstore.Core/Bookstore.Core.csproj.
Project `tests/Bookstore.Tests/Bookstore.Tests.csproj` added to the solution.
$ wc -l Legacy.sln
      71 Legacy.sln
$ sed -n "6,8p" Legacy.sln
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "src", "src", "{827E0CD3-B72D-47B6-A68D-7590B98EB39B}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Bookstore.Api", "src\Bookstore.Api\Bookstore.Api.csproj", "{1B832D7C-ADC7-4A7F-8717-A4C6EAFBC371}"

The warning on the third line is informative too: because the API (Application Programming Interface) project references Bookstore.Core, the CLI (Command Line Interface) had already added it along with the API project. Then we converted it without Visual Studio, using only the CLI:

$ dotnet sln Legacy.sln migrate
.slnx file ./Legacy.slnx generated.
$ wc -l Legacy.slnx
      14 Legacy.slnx
$ cat Legacy.slnx
<Solution>
  <Configurations>
    <Platform Name="Any CPU" />
    <Platform Name="x64" />
    <Platform Name="x86" />
  </Configurations>
  <Folder Name="/src/">
    <Project Path="src/Bookstore.Api/Bookstore.Api.csproj" />
    <Project Path="src/Bookstore.Core/Bookstore.Core.csproj" />
  </Folder>
  <Folder Name="/tests/">
    <Project Path="tests/Bookstore.Tests/Bookstore.Tests.csproj" />
  </Folder>
</Solution>

We went from 71 lines to 14 and no data was lost: everything that is a default in the new format (the project type GUID, the Debug/Release mapping for each project) is simply not written. The practical win is in merges: when two people added a project to the solution at the same time, the interleaved GlobalSection blocks of the old format used to conflict; now you usually get two separate <Project> lines. A solution created directly with .NET 10 doesn't even contain the Configurations block; its empty form is just the <Solution> and </Solution> lines.

In Visual Studio you do the same thing by right-clicking the solution in Solution Explorer and choosing .slnx with Save As; this feature became stable in Visual Studio 2022 17.14.

Compatibility with Older Tools

We reproduced the first failure from Guess First: we opened the same .slnx in a folder pinned to the .NET 8 SDK with global.json.

$ dotnet --version
8.0.419
$ dotnet sln Bookstore.slnx list
Invalid solution `Bookstore.slnx`. Expected file header not found.
$ dotnet build Bookstore.slnx
./old8/Bookstore.slnx(1,1): error MSB4068: The element <Solution> is unrecognized, or not supported in this context.

Build FAILED.

The .NET CLI has understood .slnx since the 9.0.200 SDK; the .NET 8 SDK assumes the file is an old-format solution, and when it can't find the header it tries to read it as an MSBuild project file. You either upgrade the agents that build old release branches to 9.0.200 or later, or keep the .sln on those branches. On the IDE side, .slnx opens in Visual Studio 2022 17.14 and in Rider since 2024.2.

The second failure is something else. dotnet sln migrate doesn't delete the old file; when both .sln and .slnx stay in the folder, commands run without a file name can't tell which one to use:

$ dotnet build
MSBUILD : error MSB1011: Specify which project or solution file to use because this folder contains more than one project or solution file.

Do the migration in a single commit: add the .slnx, delete the .sln, and update the file names in your CI scripts.

Solution Explorer: Filters and Solution Filter Files

Solution Explorer's toolbar holds small but useful things. Pending Changes Filter (Ctrl+[, P) shows only the files you changed, and the same button's drop-down shows only open files; it is the fastest answer to "what did I touch" before a commit. Sync with Active Document (Ctrl+[, S) finds the editor's file in the tree. The search box (Ctrl+;) searches file names and, if you want, file contents. Right-click a folder and choose New Solution Explorer View to open a second Solution Explorer window rooted at that folder; handy for keeping src/Bookstore.Api and the Angular project in two separate windows.

In a hundred-project solution the real gain comes from solution filters. You open the solution without loading any project using the Do not load projects option in File > Open, load only what you need with Reload Project, and then save that state into a .slnf file with File > Save Solution As Filter. The file is plain JSON:

{
  "solution": {
    "path": "Bookstore.slnx",
    "projects": [
      "src/Bookstore.Api/Bookstore.Api.csproj"
    ]
  }
}

The filter contains only the API project, but the API references Bookstore.Core. The CLI can build this file too, and it doesn't skip the dependency:

$ dotnet build Bookstore.Api.slnf
  Bookstore.Core -> ./src/Bookstore.Core/bin/Debug/net10.0/Bookstore.Core.dll
  Bookstore.Api -> ./src/Bookstore.Api/bin/Debug/net10.0/Bookstore.Api.dll
Build succeeded.

When a project moves, the filter doesn't go stale silently; it breaks loudly. A filter pointing to a project that isn't in the solution:

$ dotnet build Broken.slnf
./Bookstore.slnx : error MSB4025: The project file could not be loaded. Microsoft.Build.Exceptions.InvalidProjectFileException: Solution filter file at "./Broken.slnf" includes project "src/Bookstore.Web/Bookstore.Web.csproj" that is not in the solution file at "./Bookstore.slnx".

Whoever moves or renames a project must update the .slnf files in the repo as well. Projects added to the solution later show up as unloaded projects in an existing filter.

Code Search and Feature Search

In Visual Studio 2026, All-In-One Search combines two things in one box. Code Search (Ctrl+P, Ctrl+, or Ctrl+T) finds files, types and members; the Ctrl+P shortcut arrived in 18.0 and makes life easier for people coming from Visual Studio Code (VS Code). Feature Search (Ctrl+Q or Ctrl+Shift+P) searches menus and settings: type "format document" and you find the command, type "hot exit" and you find the setting.

In Code Search, prefixes and shortcuts narrow the search: f: for files (Ctrl+Shift+T), t: for types (Ctrl+1, Ctrl+T), m: for members (Alt+\), x: for plain text (Shift+Alt+F). Going to a line uses the same box: :39 goes to line 39 of the open file, Order:43 to line 43 of Order.cs; the file(line,col) form makes it easy to copy and paste a location from compiler output. Open the box without a query and you see your recently navigated files. Did You Mean, which arrived as a preview in 18.0, offers a Copilot-powered suggestion when you mistype or half-remember a file name; it can be turned off under Tools > Options > GitHub > Copilot > Search.

A warning: Code Search finds names, not semantic relationships. "Who calls this method" is a job for Find All References; we cover that difference across the three IDEs in the next post.

What 18.11 Brought

18.11 (the October Update), released on October 13, 2026, brought a few small things that change daily use. From the release notes I picked the ones that matter most to a .NET developer:

• Numbered tab shortcuts: Ctrl+Numpad1 through Ctrl+Numpad9 jump straight to the visible tabs in the active group. Ctrl+Shift+PgUp and Ctrl+Shift+PgDn move tabs with the keyboard, and Ctrl+NumPad0 resets the editor zoom to 100%.
• Hot Exit: when you close and reopen Visual Studio, open documents, unsaved edits and the window layout come back. It is not on by default; you enable it under Tools > Options > Projects and Solutions > General.
• Fonts and Colors now live in the Unified Settings system; your changes are reflected in settings.json. One more step of the new settings experience that started in 18.0.
• Stop build on first failure: opt-in under the Build and Run settings. When a project fails, the rest of the build is stopped; Microsoft writes that it measured a 94% reduction in the time spent after a failure in its own tests (a vendor measurement).
• On the Git side, comparing a commit with the working tree and bulk-resolving conflicts (Keep All Current, Take All Incoming); on the Copilot side, a new chat experience built on the Copilot SDK arrived as opt-in. AI (Artificial Intelligence) features are the subject of the ninth post.

In Production

Keep .vsconfig in the repo and review it. Unnecessary workloads grow the installation by tens of gigabytes; the system requirements page expects between 2.5 GB and 210 GB of disk depending on the installation, and 20 to 50 GB for a typical one. Having everyone on the team install the same workload set ends most "that project doesn't load for me" cases.

Manage updates as a team. A monthly feature update is a good thing, but when three different minor versions circulate on one team, an analyzer warning or a template behavior can differ from machine to machine. Professional and Enterprise have an LTSC (Long-Term Servicing Channel) option; choose your channel deliberately in an enterprise environment.

Plan the .slnx migration together with CI. Update the SDK version on build agents, the scripts that use the solution file name, and the .slnf files in the same change. Real measurement: the .NET 8 SDK cannot read .slnx at all.

Common Pitfalls

Installing everything. Mobile, game and C++ workloads picked "just in case" come back as disk usage, update time and IDE startup. Start with NetWeb and add to .vsconfig as needs arise.

Updating without checking extension compatibility. Microsoft says most Visual Studio 2022 extensions will work in 2026 without updates, but "most" may not include your critical extension. In a side-by-side install extensions are not migrated automatically; try critical extensions on Insiders or on a second machine before updating.

Leaving the old .sln after the migration. The moment there are two solution files in the folder, every dotnet build without a file name stops with MSB1011.

Forgetting solution filters. If the person who moves a project doesn't update the .slnf, the build of everyone using that filter breaks with MSB4025.

Treating Code Search as a reference tool. Finding a method name in Code Search is not the same as finding who calls it.

A Small Experiment

★☆☆ Run dotnet sln migrate in one of your repos, compare the line counts of the two files, delete the old .sln and confirm that dotnet build still works.

★★☆ Add a .vsconfig with only the workloads you need and a .slnf with the backend projects to your repo. What does dotnet build do when you remove a dependency of a filtered project from the filter?

★★★ Add a step to your CI pipeline that breaks the build "if there is more than one solution file in the repo root, or if a .slnf points to a project that isn't in the solution". Hint: dotnet build <file>.slnf tells you this for free.

We have seen Visual Studio's skeleton. In the next post we put the three IDEs on the same table and compare navigation and shortcuts: from Go to Definition to Find All References, from multi-caret to switching keymaps, with Windows and macOS shortcuts side by side.