Struggling with upgrade a ASP.NET app from .NET 8 to .NET 10

Question

Struggling with upgrade a ASP.NET app from .NET 8 to .NET 10

Rod Falanga 1,156

This is a problem I've encountered before but have never found a satisfactory solution. I'm taking a Pluralsight course which came out 2 years ago. Thus, it was written using .NET 8, which was the latest, at that time. I'm trying to upgrade it to .NET 10 and have run into more and more problems. The Visual Studio solution is comprised of 9 VS projects. I thought it would be a simple task of editing the .csproj files and replacing .NET8 with .NET10. Then upgrade the NuGet packages. Initially I had 1 error. The upgrades I did, weren't working, so I thought I would bring GitHub Copilot in to help me with this. I decided to leave it in Ask mode (perhaps this is a part of my problem, I don't know). Under .NET 8 the original app included the NuGet package Microsoft.OpenApi.Models. Under .NET 10, it complains and says there's no Models in Microsoftr.OpenApi. I started with 1 error, which then went to 9 errors, and now I'm at 29 errors. I'm thinking that GitHub Copilot is just chasing after rabbits and going crazy. I think I will make a note of the initial changes I made in this child branch, then blow the whole branch away, to start over again with only the first few commits.

My question for this forum is how can I reduce prevent GitHub Copilot from just generating errors exponential? My using Copilot in this way isn't at all useful. In fact, it is worse than useless. There's probably a dozen NuGet packages used in the whole VS solution. Changing just the ones tied to .NET 8 I see results in causing mayhem in the solution. Is there a way of using GitHub Copilot more intelligently, so that it will "know" that changing this NuGet package(s) will require changing those NuGet packages?

0 comments

Answer accepted by question author

Bruce (SqlWork.com) 85,276

The biggest change from .net8 to .net10 are the changes in openapi and swagger support. I recommend creating a new webapi project and follow the docs to add open api.

https://learn.microsoft.com/en-us/aspnet/core/fundamentals/openapi/aspnetcore-openapi?view=aspnetcore-10.0&tabs=visual-studio%2Cvisual-studio-code

Then you can apply this knowledge to converting your old project.

If your old project supported swagger see this post:

https://github.com/dotnet/aspnetcore/issues/54599

And this doc for adding

https://learn.microsoft.com/en-us/aspnet/core/tutorials/getting-started-with-swashbuckle?view=aspnetcore-8.0&tabs=visual-studio

Note: In my .net 8 projects I used nswag, but switched to swashbuckle for .net 10.

Rod Falanga 1,156 Reputation points

2026-09-10T01:45:56.1866667+00:00

Thank you, Bruce, I like this approach.

1 additional answer

Your answer

Rod Falanga 1,156 Reputation points

2026-09-10T01:45:56.1866667+00:00

Thank you, Bruce, I like this approach.

Answer 1

Yes. The main way to stop GitHub Copilot upgrade from creating cascading changes is to use the upgrade agent in a scoped, scenario-driven way instead of broad Ask-mode prompts.

For a 9-project ASP.NET solution, use this approach:

Start with a single project, not the whole solution.
Large solutions are handled project-by-project, and a single-project pilot helps surface systemic issues early.
Use the upgrade agent with an explicit scenario prompt.
In Visual Studio, right-click the solution or project in Solution Explorer and select Modernize, or open GitHub Copilot Chat and type @Modernize.
Be very specific about scope. For example:
- Upgrade the WebApi project to .NET 10
- Upgrade the API project first, then the shared library
- Fix the build error in CustomerService.cs related to the removed API
State constraints up front so the agent does not make broad changes on its own. For example:
- Don't change the public API surface.
- Don't touch the legacy reporting module.
- Upgrade only this project first.
Ask the agent for the plan before accepting changes. Useful prompts include:
- Explain the plan
- Walk me through the tasks
- What did the assessment find?
- Why did you choose X over Y?
Save preferences early in scenario-instructions.md.
This file persists across sessions and is the most reliable way to influence behavior, including exclusions and coding preferences.
If the agent starts pushing the wrong kind of upgrade, correct it explicitly. Instead of a generic request like upgrade my project, use a precise one such as I want to upgrade to .NET 10. The troubleshooting guidance also recommends adding scenario preferences to scenario-instructions.md to avoid repeated mismatches.
If the session becomes inconsistent, reset the workflow state rather than continuing to pile on fixes.
- If tasks are stuck, tell the agent resume or restart the current task.
- If the state looks wrong, tell it reassess and re-plan.
- Check .github/upgrades/ because that folder stores the workflow state.
Make sure the workspace root is correct.
If the agent cannot correctly identify the solution or project, it can choose the wrong scenario or fail to assess dependencies properly. The workspace root should contain the .sln, .csproj, or .vbproj file, or the agent should be pointed to the correct file.
For package-related failures, let the agent assess first instead of manually changing many packages at once.
The upgrade workflow is designed around assessment, recommendations, code fixes, and validation. Manually editing all target frameworks and packages first can create the kind of cascading errors being seen.

For the current branch, the cleanest path is:

Roll back to the point where there was only the initial error.
Start the upgrade agent with a narrow prompt for one project.
Ask for the assessment and plan first.
Apply changes incrementally and validate after each project.

Also, GitHub Copilot upgrade supports .NET version upgrades to .NET 8, 9, 10, or later, and supports ASP.NET Core-related project types such as MVC, Razor Pages, and Web API.