GitHub Copilot with Visual Studio

GitHub Copilot with Visual StudioCopilot IDE & Developer Workflow5Beginner → Intermediate/github-copilot/ide/visual-studio/

Visual Studio is not VS Code with more menus, and treating it that way is the fastest route to a frustrating afternoon. It is a different product with a different context model, a different set of slash commands, different key bindings, and — on two counts — better Copilot support than VS Code has.

This lesson covers what is genuinely different about Copilot here, with .NET as the working context.

Copilot support

Visual Studio

Verified August 20, 2026

The .NET environment. Second only to VS Code on feature coverage, and the only IDE with the .NET Upgrade Agent.

Installed via

Built-in component from Visual Studio 2022 17.10 onward

IDE version tracked

18.6.0

Feature coverage

16 supported · 0 preview · 2 not supported

• Code completionSupported
• ChatSupported
• Agent modeSupported
• Custom instructionsSupported
• MCPSupported
• Copilot code reviewSupported

Key takeaways

• Visual Studio leads VS Code on BYOK and vision, both fully supported here and in preview there.
• It is the only editor with the .NET Upgrade Agent.
• Context is referenced by file and solution — #MyFile.cs, #solution — not by VS Code’s chat variables.
• There is no edit mode, so the gap between chat and agent mode is wider than in VS Code.
• Its slash commands differ: it has /doc and /optimize, and lacks /new and /fixTestFailure.

Installation and versions

That built-in status is not a packaging detail. It is why Visual Studio’s Copilot integration reaches deeper into the solution model than a third-party extension could — the integration ships with the IDE and is developed against internals a marketplace plugin does not see.

Solution context: the real difference

VS Code thinks in terms of a workspace folder. Visual Studio thinks in terms of a solution containing projects, each with its own target framework, references and dependencies. Copilot here inherits that model, and it changes what good context looks like.

Rather than VS Code’s #file and #selection variables, Visual Studio uses file and solution references:

How are #OrderService.cs and #OrderRepository.cs related? Identify which project each lives in and whether the dependency direction matches our layering.

#solution is the reference with no VS Code equivalent, and it is the right tool for architectural questions — “where is validation happening across this solution” is answerable here in a way it is not in a folder-based editor.

Slash commands

Visual Studio’s set overlaps VS Code’s only partially:

/doc and /optimize do not exist in VS Code. /new, /clear and /fixTestFailure do not exist here.

/doc is genuinely useful in C#, because XML documentation comments are verbose and mechanical — exactly the shape of work worth delegating:

/doc

Include every parameter, the return value, and each exception this method can throw. Describe actual behaviour rather than intended behaviour — if the code and its name disagree, say so.

Keyboard behaviour

Accepting with Tab and dismissing with Esc follow Visual Studio’s standard editor behaviour rather than being Copilot-specific bindings, which is why GitHub’s reference does not list them separately.

The .NET Upgrade Agent

The feature that exists nowhere else.

Upgrading a .NET project to a newer target framework is exactly the kind of work that is tedious, well-understood, spread across many files, and error-prone by hand — the profile of a task worth automating. The .NET Upgrade Agent addresses it directly.

Treat its output as a substantial pull request from a competent stranger rather than a completed migration. Review the same things you would review in any upgrade: package version changes, API replacements where a method was removed rather than renamed, changed default behaviours between framework versions, and anything in the build configuration.

Agent mode without edit mode

Visual Studio supports agent mode, checkpoints, custom agents, agent skills, prompt files and MCP. What it does not have is edit mode.

In VS Code, edit mode is the middle gear: you nominate the files, describe the change, and Copilot edits across them without the autonomous loop. Here that gear is missing, so the step from chat to agent mode is larger.

The practical substitute is prompt discipline — a tightly scoped agent task that names the files explicitly and forbids anything outside them:

Rename CustomerDto to CustomerResponse in these three files only: Api/Controllers/CustomerController.cs, Api/Models/CustomerDto.cs, Tests/CustomerControllerTests.cs.

Update the references, keep the namespace unchanged, and do not touch any other file. Do not run anything.

“Do not run anything” is doing real work there — it removes the tool-calling half of agent mode and leaves you with something close to edit mode’s behaviour.

BYOK and vision

Two rows where Visual Studio is ahead of VS Code.

BYOK — bringing your own model key rather than using Copilot’s hosted models — is fully supported in Visual Studio, and in preview in VS Code, JetBrains, Eclipse and Xcode. For an organisation that must run models under its own contract for procurement or data-residency reasons, that is a real, current reason to prefer Visual Studio.

Vision — attaching an image to a prompt — is also fully supported here and in preview in VS Code. Attaching a screenshot of a failing designer surface or a mockup is a legitimate workflow rather than an experiment.

Working with .NET

Some patterns that play to the environment.

Test generation against your existing framework

/tests

Use the same test framework and assertion style as the existing tests in #CustomerControllerTests.cs. Cover a successful request, a validation failure, and a not-found result. Do not introduce a new mocking library.

The last sentence matters more in .NET than elsewhere. The ecosystem has several established mocking and assertion libraries, and without a constraint the model will pick whichever is most common in training data rather than the one your solution already references.

Asking about the solution rather than the file

Looking at #solution, which projects reference the data access layer directly? Flag any that should be going through the service layer instead.

Async and cancellation

A worthwhile prompt in any .NET codebase, because generated async code frequently omits cancellation tokens:

Review this class for async problems: missing CancellationToken parameters, async void methods, blocking calls on async code, and missing ConfigureAwait where it matters for this project type. Quote the specific lines.

C++ and native code

Visual Studio is also the primary C++ environment on Windows, and Copilot behaves differently there in ways worth knowing.

Header and implementation files split the context. A .cpp file without its header open gives Copilot half the picture, and the resulting suggestions will invent signatures that do not match your declarations. Keeping the paired header open is the single most effective habit for C++ completion quality — more effective than any prompt.

Build configuration is largely invisible to Copilot. Preprocessor definitions, include paths and platform toolset settings shape what compiles, and Copilot cannot see any of it. Expect suggestions that are valid C++ and wrong for your configuration, particularly around platform-specific APIs.

Rewrite this function to avoid raw owning pointers, using the smart pointer types already used in #MemoryPool.h. Target C++17 — do not use anything newer. Explain any change in ownership semantics.

Naming the standard version matters here far more than in C# or Python, because the language has changed substantially across revisions and the model has seen all of them.

Debugging

Visual Studio’s debugger is one of its strongest features, and it pairs with Copilot in a specific way: the debugger produces facts, and Copilot is good at reasoning about facts you supply.

The pattern that works is to debug first, then ask. Set a breakpoint, inspect the actual values, and bring those into the conversation:

At this breakpoint in #OrderProcessor.cs, order.Items has 3 entries but order.Total is 0. Given the code in this file, list the conditions that would produce that combination, ordered by likelihood.

That is a considerably better use of the tool than asking it to guess why an exception occurred, because you have replaced speculation with observation.

Exception analysis works well when you paste the full exception including inner exceptions — .NET exception chains carry most of the useful information in the inner exception, and truncating to the outer message throws away the part that identifies the cause.

Copilot code review

Supported in Visual Studio. The habit worth building is the same as elsewhere: run it on your own changes before requesting human review, so a colleague’s attention goes to design rather than to a missing null check.

Two things it does well in .NET specifically — spotting missing using statements on disposables, and flagging async methods that block. Two things it does not do — tell you whether a change belongs in this project rather than another, or whether it matches an architectural decision made three years ago.

Enterprise considerations

Visual Studio is disproportionately used inside organisations, so three points are worth making explicitly.

Governance is a plan feature, not an editor feature. Content exclusion, organisation custom instructions, policy management and audit logs all come from Copilot Business or Enterprise, and they behave identically regardless of editor. The plans comparison covers them.

BYOK is the editor-level enterprise differentiator. Full support here rather than preview is the concrete Visual Studio advantage for a regulated environment.

Agent instruction files are not listed as supported. GitHub’s custom instruction support reference lists repository-wide and path-specific instructions for Visual Studio, but does not list AGENTS.md-style agent instruction files — unlike VS Code, JetBrains, Eclipse and Xcode. If your team standardises on AGENTS.md, Visual Studio users may not get the same behaviour.

A realistic Visual Studio workflow

Putting the pieces in the order a .NET developer would actually use them on a feature.

Orient with #solution. Before touching anything, ask where the concept you are about to change already lives. In a large solution this is faster than navigating by hand, and it surfaces the project boundaries you need to respect.

Draft the shape in chat, not in the editor. Describe the endpoint or service you intend to add and ask what it would touch. Reviewing a plan costs a minute; reviewing a wrong implementation costs considerably more.

Write the signature, let completion fill the body. The contract-first habit from Cluster 1 applies unchanged. In C# that means the method signature, the XML doc comment stating what it throws, and the parameter types — which together constrain the completion far more than any prompt would.

Use /tests against your existing test file. Referencing the existing tests is what keeps the generated ones in your project’s framework and style rather than whichever is most common in training data.

Run the tests in Test Explorer. Not the agent’s claim about them. Visual Studio’s test tooling is good; use it rather than trusting a summary.

Run Copilot code review before requesting a human one. It clears the mechanical findings so review attention goes to design.

Read the diff in the Git changes view. Reading changed files in place makes it too easy to see what you expected rather than what changed.

Steps five through seven do not get delegated, in this editor or any other.

Coming from VS Code

Most of the friction here comes from habits rather than from missing features. The five that cause the most lost time, in order:

Chat variables do not exist. Typing #file or #selection produces a prompt that mentions a literal string and attaches nothing. Reference files by name instead — #OrderService.cs — or use #solution.

Chat participants do not exist either. There is no @terminal or @workspace. Ask the question in plain language and attach what it needs.

There is no edit mode. The middle setting between chat and agent mode is absent, so a narrow change means either copying from chat or constraining agent mode with an explicit prompt about what it may not touch.

The cycling keys are different. Alt+, and Alt+., not Alt+[ and Alt+]. This is the one that catches people repeatedly, because the muscle memory is strong and the wrong keys do something else rather than nothing.

Half the slash commands are different. /new, /clear and /fixTestFailure are not here; /doc and /optimize are, and have no VS Code equivalent.

Two things run the other way and are worth knowing about: BYOK and vision are fully supported here and in preview in VS Code, and the .NET Upgrade Agent exists in no other editor. Visual Studio is not a reduced VS Code — it is a different product with a different balance.

Troubleshooting

Frequently asked questions

Do I need to install anything for Visual Studio 2022 17.10 or later? No. Copilot ships as a built-in component. You add a GitHub account with Copilot access and it activates.

Why do VS Code tutorials not work here? Because several things they rely on do not exist in Visual Studio: chat variables like #file, chat participants like @terminal, edit mode, and the /new and /fixTestFailure commands. The concepts transfer; the syntax does not.

Is Copilot worse in Visual Studio than in VS Code? Not overall. It trails on edit mode and a handful of commands, and it leads on BYOK, vision and the .NET Upgrade Agent. For .NET work the solution-level context is a genuine advantage.

Can I use the .NET Upgrade Agent on any project? It targets .NET upgrades specifically. Review its output as you would any substantial migration pull request — particularly package versions and behaviours that changed between framework versions rather than APIs that were merely renamed.

Does Copilot understand my whole solution? It supports workspace indexing and #solution, so it can reason across projects. That is not the same as complete knowledge — explicitly referenced files still carry more weight than indexed ones.

Why is AGENTS.md not working? GitHub does not list agent instruction files as supported in Visual Studio. Put anything essential in .github/copilot-instructions.md, which is supported.

Does Copilot work with C++ as well as it does with C#? Less reliably, for a structural reason rather than a language one: C++ splits declarations and definitions across files, and build configuration is invisible to Copilot. Keeping the paired header open closes most of that gap.

Next steps

For the cross-editor picture, see GitHub Copilot for IDEs.

If you also work in VS Code, GitHub Copilot with Visual Studio Code covers the chat variables and edit mode that do not exist here — worth reading precisely so you know what not to reach for.

The capstone, From Idea to Pull Request, walks a complete workflow that applies in any editor.