{"id":4149,"date":"2026-05-26T17:13:06","date_gmt":"2026-05-26T17:13:06","guid":{"rendered":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/05\/26\/doing-more-with-github-copilot-as-a-net-developer\/"},"modified":"2026-05-26T17:13:06","modified_gmt":"2026-05-26T17:13:06","slug":"doing-more-with-github-copilot-as-a-net-developer","status":"publish","type":"post","link":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/05\/26\/doing-more-with-github-copilot-as-a-net-developer\/","title":{"rendered":"Doing More with GitHub Copilot as a .NET Developer"},"content":{"rendered":"

For most .NET developers, the best way to get started with GitHub Copilot is not by learning every feature first. It is by using the right Copilot experience for the work already in front of you.<\/p>\n

Inline completions are part of that story, of course. They help with the everyday C# work that is repetitive but still necessary: filling in tests, building out LINQ expressions, wiring up DTOs, or scaffolding a Minimal API endpoint. But the bigger gains usually show up when you start using chat<\/strong> for reasoning and agentic workflows<\/strong> for scoped execution.<\/p>\n

That is where the different surfaces matter. Visual Studio, Visual Studio Code, the Copilot CLI, and the cloud coding agent each shine on different kinds of .NET tasks. The question is not which one is \u201cmost advanced.\u201d The better question is: which one fits the job I am doing right now?<\/strong><\/p>\n

Start with the task, not the mode<\/h2>\n

The fastest way to get value is to stop asking, \u201cWhich Copilot feature should I try?\u201d and start asking, \u201cWhat part of this task should I delegate?\u201d<\/p>\n

Real examples of using chat in .NET work<\/h3>\n

Chat becomes useful the moment you need explanation, comparison, planning, or targeted code generation based on your actual project.<\/p>\n

Example 1: Understand a service before changing it in Visual Studio<\/h4>\n

Suppose you open a legacy ASP.NET Core service and find a class with five dependencies, several feature flags, and business rules buried in a long method. Before you change it, use chat to get oriented.<\/p>\n

Prompt:<\/p>\n

Explain what this service is responsible for, identify the key dependencies, and point out which parts are business logic versus infrastructure concerns. Then suggest a safe first refactor that does not change behavior.<\/code><\/pre>\n
That is far better than asking for a blind rewrite. It helps you understand the codebase you already have, which is often the real bottleneck in .NET work.<\/p>\n
Example 2: Generate tests for business logic in Visual Studio<\/h4>\n
Imagine you have a pricing method that applies discounts, caps, and regional tax rules. You can write the first happy-path test yourself, then use chat to help fill out the edge cases.<\/p>\n
Prompt:<\/p>\n
Create unit tests for this method using the same test style as this project. Cover discount boundaries, null input handling, and the case where the total is capped. Explain any edge cases you think are easy to miss.<\/code><\/pre>\n
Bonus: If you are in Visual Studio, use the Test Agent. If you are in VS Code or the CLI, use the dotnet-test skill<\/a> for the best success. This is a strong use case because you want both output and reasoning. You do not just want test code. You want confidence that the right cases were considered.<\/p>\n
Example 3: Plan a refactor before touching the code<\/h4>\n
Let us say a controller has too much logic in it and you want to move validation and orchestration into a service. Chat is useful before you edit anything.<\/p>\n
Prompt:<\/p>\n
Review this controller action and propose a refactor that moves orchestration into a service without changing the HTTP contract. Show the target shape of the controller, service interface, and unit tests I should expect to update.<\/code><\/pre>\n
Enter Plan Mode before doing this and Copilot will create a detailed plan for either you or Copilot to implement when it\u2019s ready. This works well in Visual Studio because you are already looking at the relevant files and solution structure.<\/p>\n
Example 4: Use VS Code when the change crosses code and configuration<\/h4>\n
A common .NET scenario is not just changing C# code. It is changing the API, the OpenAPI description, a deployment file, and the documentation in one pass. That is where VS Code often feels especially comfortable.<\/p>\n
Prompt:<\/p>\n
I am adding a new optional region filter to this endpoint. Update the ASP.NET Core handler, adjust the OpenAPI description, and point out any config, docs, or client code that may also need to change.<\/code><\/pre>\n
This is where chat starts to feel less like autocomplete and more like a working partner. It can help you think across the whole repo, not just the file in front of you.<\/p>\n
Example 5: Use the Copilot CLI to reason about a failing build<\/h4>\n
If dotnet test or dotnet build fails, the CLI is a natural place to work because the failure is already in your terminal.<\/p>\n
Prompt:<\/p>\n
Explain this build failure in plain English, tell me which project likely introduced it, and suggest the next two commands I should run to narrow it down.<\/code><\/pre>\n
Or:<\/p>\n
This xUnit test is failing intermittently. Based on the output and the file paths involved, what are the likely causes, and what should I inspect first?<\/code><\/pre>\n
That is a better starting point than dumping the error into a search engine because the CLI can stay close to your actual repo and command loop.<\/p>\n
What good chat prompts look like<\/h3>\n
For .NET work, the best chat prompts usually include four things:<\/p>\n
    \n
  1. the goal<\/li>\n
  2. the code or command output<\/li>\n
  3. the constraint<\/li>\n
  4. the expected shape of the answer<\/li>\n<\/ol>\n
    For example:<\/p>\n
    Refactor this background worker to make the retry policy easier to test. Keep the public behavior the same, preserve structured logging, and show me the test cases I should add.<\/code><\/pre>\n
    That is much stronger than:<\/p>\n
    Improve this code.<\/code><\/pre>\n
    The more the prompt sounds like a real code review comment or engineering task, the more useful the response tends to be.<\/p>\n
    Real-world agentic flows for .NET developers<\/h3>\n
    Agentic workflows are most useful when the task is multi-step, bounded, and reviewable. You are no longer asking only for an answer. You are asking Copilot to carry out a piece of work.<\/p>\n
    Example 1: Fix a test gap across a feature slice<\/h4>\n
    Suppose a new feature was added to an ASP.NET Core API, but only the happy path was tested. This is a strong agentic task in Visual Studio, VS Code, or the cloud coding agent.<\/p>\n
    Task:<\/p>\n
    Add missing unit tests for the CreateOrder flow. Cover validation failures, duplicate order detection, and the downstream payment timeout path. Keep the existing test style, do not rename public APIs, and stop once the new tests pass.<\/code><\/pre>\n
    Why this works:<\/p>\n