Visual Studio 2026 editions (Community, Professional, Enterprise), workloads and components, and using a .vsconfig file to give every developer the same installation.
For .NET 10 you need Visual Studio 2026. The edition depends on licensing and features: Community is free for individuals, open source and small organisations; Professional is the normal paid edition; Enterprise adds tools like IntelliTrace and Live Unit Testing. You install workloads such as ASP.NET and web development. To keep the team consistent, export a .vsconfig from the Visual Studio Installer and commit it at the repo root: Visual Studio then prompts anyone missing a component to install it, and the installer can apply the same file on build agents.
"For .NET 10 the IDE has to be Visual Studio 2026. Visual Studio 2022 isn't supported for .NET 10 projects, and an out-of-date IDE is a classic cause of IntelliSense errors on C# 14 code even when
dotnet buildsucceeds. The edition is mostly a licensing decision: Community is free for individuals, open source, academia and small non-enterprise teams, Professional is the normal paid edition, and Enterprise adds tools like IntelliTrace and Live Unit Testing.What you actually install are workloads, which are bundles of components. A backend team typically needs ASP.NET and web development and often Azure development, and a desktop team adds .NET desktop development. I install only what the solution needs, because every extra workload costs disk space, update time and start-up time.
To keep everyone consistent, I export a
.vsconfigfrom the Visual Studio Installer and commit it next to the solution. Visual Studio then prompts anyone missing a component to install it, and new laptops apply the same file unattended withsetup.exe modify --config. The pitfall is assuming.vsconfigpins a version; it only lists components, so I also document the minimum Visual Studio version and pin the SDK inglobal.json. I keep Visual Studio on its latest update for security fixes and newer SDK support, and most build agents need only the .NET SDK, not Visual Studio.I treat the developer workstation as configuration, not tribal knowledge, and the same idea extends to standardising a mixed Visual Studio, VS Code and Rider team."
Visual Studio 2026 (version 18) is the release Microsoft supports for .NET 10 and C# 14 development. Visual Studio 2022 is not supported for .NET 10 projects: the .NET 10 SDK warns "Targeting .NET 10.0 or higher in Visual Studio 2022 17.14 is not supported" because the IDE needs matching changes that only ship in Visual Studio 2026. Some projects may still open in Visual Studio 2022, but you are outside support and IntelliSense for new C# 14 features can be wrong. So an upgrade to .NET 10 usually means an IDE upgrade for Windows developers as well, and after that you keep Visual Studio 2026 on its latest update.
| Edition | Who it is for | Notes |
|---|---|---|
| Community | Individuals, open-source contributors, classroom and academic use, and non-enterprise organisations with up to five users | An "enterprise" here means more than 250 PCs or more than US$1 million annual revenue; such organisations cannot use Community except for open source, education or research |
| Professional | Most commercial teams | Paid subscription |
| Enterprise | Teams that want advanced diagnostics and testing | Adds IntelliTrace, Live Unit Testing and other advanced tooling |
The Visual Studio Installer installs workloads (bundles for a kind of work) made of components. A typical .NET 10 backend team needs ASP.NET and web development and often Azure development; desktop teams add .NET desktop development. Individual components cover things like Git tooling or specific SDKs.
.vsconfig file.setup.exe modify --config..vsconfig lists components, not versions.After moving a payments platform to .NET 10, half the team was still on Visual Studio 2022 and the rest had different workloads. We standardised on Visual Studio 2026 Professional, committed a .vsconfig, and added the installer command to the laptop provisioning script. The "it works on my machine" tickets about missing templates and Azure tooling stopped.
The interviewer is checking practical knowledge of the Microsoft toolchain and whether you think about reproducible developer setup.
Green flags
.vsconfig and unattended installs.Red flags
Visual Studio Installer
+- Instance (e.g. Visual Studio 2026 Professional, installed at a path, on a channel)
+- Workload: Microsoft.VisualStudio.Workload.NetWeb
| +- components: ASP.NET tooling, web templates, ...
+- Workload: Microsoft.VisualStudio.Workload.Azure
+- Individual components: Microsoft.VisualStudio.Component.Git, ...
.vsconfig (committed in repo) --open solution--> Visual Studio compares
+- missing? -> "Install" prompt
| Concept | Meaning |
|---|---|
| Instance | One installation of one edition at one path. You can have several side by side |
| Channel | Release or Preview. Preview gets new features (and .NET previews) first |
| Workload | A bundle of components for a kind of work, such as ASP.NET and web development |
| Component | A single installable piece, such as Git tooling or a targeting pack |
.vsconfig |
A JSON list of workload and component ids that a solution needs |
| Visual Studio | .NET 10 / C# 14 support |
|---|---|
| Visual Studio 2026 (version 18), latest update | Supported |
| Visual Studio 2022 17.14 | Not supported; the SDK warns when you target net10.0 |
| Visual Studio 2022, older updates | Not supported |
Visual Studio 2022 remains a valid tool for projects that stay on .NET 8 or .NET 9, and it can be installed side by side with Visual Studio 2026 during a migration.
| Team | Workloads |
|---|---|
| ASP.NET Core APIs and web apps | ASP.NET and web development; often Azure development |
| Worker services and console tools | .NET desktop development or ASP.NET and web development (both include the .NET SDK tooling) |
| WinForms / WPF | .NET desktop development |
| Mixed solution with .NET Framework projects | .NET desktop development plus the matching .NET Framework targeting packs |
| .NET MAUI | .NET Multi-platform App UI development |
Install only what the solution needs; every extra workload adds disk use, update size and start-up cost.
.vsconfig, Visual Studio compares it with the installed instance and shows a banner offering to install missing components.setup.exe modify --config <path> (or --add for individual ids).Pair it with a documented minimum Visual Studio version (for example "Visual Studio 2026, latest update") and a pinned SDK in global.json.
vswhere.exe lives in the installer folder and lists instances, their paths, versions and installed components. Scripts use it to find the right instance:
& "${env:ProgramFiles(x86)}\Microsoft Visual Studio\Installer\vswhere.exe" -latest -products * -requires Microsoft.VisualStudio.Workload.NetWeb -property installationPath
SDK-style projects build with the .NET SDK alone, so most agents don't need Visual Studio at all. Install Visual Studio Build Tools (or full Visual Studio) only for projects that need Windows-only build components, such as some .NET Framework, C++ or legacy web projects.
| Situation | Edition |
|---|---|
| Individual developer, open source, classroom, academic research | Community is free |
| Non-enterprise organisation, up to five users | Community is free |
| Enterprise (more than 250 PCs or more than US$1 million annual revenue) | Professional or Enterprise subscriptions for commercial work |
| Contractors | Need a licence: from the client or their own business |
Enterprise adds tools such as IntelliTrace, Live Unit Testing and advanced debugging and testing features. Whether that is worth it is a per-team decision.
.NET 11 preview support appears first in the Visual Studio Preview channel. Install it as a separate instance for experiments, so your main instance stays on the supported release.
.vsconfig..vsconfig next to a solution, open it, and watch for the prompt.vswhere.exe -latest -property installationPath from the installer folder.vswhere.exe -all -format json and find each instance's channel and version.A minimal .vsconfig committed at the repo root:
{
"version": "1.0",
"components": [
"Microsoft.VisualStudio.Workload.NetWeb",
"Microsoft.VisualStudio.Workload.Azure",
"Microsoft.VisualStudio.Component.Git"
]
}
Apply it unattended to the latest installed instance (PowerShell, run as administrator):
$installer = "${env:ProgramFiles(x86)}\Microsoft Visual Studio\Installer"
$vsPath = & "$installer\vswhere.exe" -latest -property installationPath
& "$installer\setup.exe" modify --installPath $vsPath --config "$PWD\.vsconfig" --passive
Mistake: using Community at a company that exceeds its limits. Over 250 PCs or more than US$1 million annual revenue makes the organisation an enterprise, and Community isn't licensed for its commercial work. An audit finding is an avoidable cost. Instead: buy Professional or Enterprise subscriptions for everyone doing commercial work, including contractors (licensed by the client or their own business).
Mistake: staying on Visual Studio 2022 for .NET 10 projects. The SDK warns that this is unsupported, and IntelliSense for C# 14 features can be wrong. Instead: upgrade to Visual Studio 2026 and keep it on the latest update. Keep Visual Studio 2022 side by side only for branches that stay on .NET 8 or 9.
Mistake: removing workloads that legacy projects still need.
A solution that still contains .NET Framework projects fails to load or build them without the right workload and targeting packs.
Instead: check the .vsconfig covers every project in the solution, not just the new ones, and test it on a clean machine.
Mistake: letting developers fall behind on updates. They miss security fixes and support for newer SDK feature bands. Instead: agree an update cadence (for example within two weeks of each release) or use an administrator-controlled update channel.
Mistake: installing every workload "just in case".
It makes Visual Studio slower to start and update, and uses tens of gigabytes of disk.
Instead: install what the .vsconfig lists, and add workloads when a project actually needs them.
Mistake: assuming a .vsconfig pins the Visual Studio version.
It lists components only, so people on old versions still pass the check.
Instead: document the minimum version in the README and onboarding script, and pin the SDK with global.json.
Mistake: putting full Visual Studio on every build agent. It makes agent images huge and slow to patch, and SDK-style projects don't need it. Instead: build with the .NET SDK alone, and use Visual Studio Build Tools only for the projects that require Windows build components.
Treat the developer workstation as configuration, not tribal knowledge. A committed .vsconfig, a pinned SDK in global.json, and a provisioning script turn a two-day onboarding into an hour, and that saving multiplies as the team grows: at ten new starters a year it is weeks of engineering time.
The edition decision is a cost-benefit call. Enterprise features like Live Unit Testing and IntelliTrace are valuable for some teams, but most backend teams get more from Professional plus fast CLI-based tests and profiling in CI. Decide per team, not per company, and revisit when the team's work changes (for example a desktop rewrite).
Plan IDE upgrades with .NET upgrades: a move to .NET 10 is also a move to Visual Studio 2026, so schedule both, keep Visual Studio 2022 side by side for branches still on older .NET, and remove it once those branches are retired. Licensing is part of the engineering lead's job in Australian organisations too; an audit that finds Community in use at a large company is an avoidable finding.
I standardise below the IDE rather than forcing one IDE. The CLI and CI are the source of truth. I pin the SDK with global.json, put style and analyser severities in .editorconfig, centralise build properties in Directory.Build.props and versions with Central Package Management, and commit shared IDE files such as .vsconfig, .vscode/extensions.json and launchSettings.json while ignoring personal state. I offer a Dev Container or a setup script for onboarding, keep secrets in user secrets and Key Vault, and CI runs the same dotnet format, build and test commands developers run locally.
The IDE's errors come from design-time builds and the language service, not from the real compiler run, so a mismatch means the IDE has a different view of the project. I first confirm which side reports the error by filtering the Error List to Build only and IntelliSense only. Then I check the usual causes: the IDE resolved a different SDK from the CLI (fix with global.json), stale caches in obj/ or .vs/, a failed restore, a source generator that has not re-run, or the wrong target framework context in a multi-targeted project. I fix the root cause and confirm with a clean dotnet build.
Last updated 1 Nov 2026.