The Whestone.Alexa NuGet package is one I happened to stand while also developing this project. It needs to stay, but I tell the modernization copilot to “Remove references to Microsoft.EntityFrameworkCore.Relational.Design and Npgsql.EntityFrameworkCore.PostgreSQL.Design” Once I’m satisfied with my updates to the default plan, I tell copilot to “proceed.”
It creates a number of local commits while it steps through the migration process and pauses a few times to ask whether I would like to review or continue. I notice a build break related to MessagePack, indicating a breaking change between 2.4.59 and 3.1.3, so I ask to “review the MessagePack upgrade.”
![Upgrade]()
There may be some manual edits necessary. There are 55 projects to update, and asking if I want to pause and review every four projects or so becomes tedious. I ask it to “continue and do not ask me if I want to pause or review.” Not the typo in “paue.” Copilot partially understands my request and pauses every seven projects rather than every four. I try again with “continue and do not pause until after finishing all projects” and that works until I get a strange response reporting that Whetstone.StoryEngine.Data.Tests.csproj does not exist. After insisting that Whetstone.StoryEngine.Data.Tests.csproj exists. Copilot finds it and upgrades it.
![Tasks]()
The process completed in approximately 15 minutes with 59 granular commits. Each commit was either an update to the ItemGroup settings in a project or to the TargetFramework. Out of 55 projects, the upgrade missed two test projects:
- Whetstone.Queue.SessionLogger.Tests.csproj
- Whetstone.Queue.CoreApi.Tests.csproj
In fairness, test project types are not in the list of project types supported by the GitHub Copilot app modernization – upgrade for .NET extension, but it did handle the other test projects.
Assessing Results
In this use case, running a search and replace across csproj would have been sufficient to upgrade all projects to .NET 9, including the two that were missed. For example, replace “<TargetFramework>net7.0</TargetFramework>” with “<TargetFramework>net9.0</TargetFramework>” would have covered all 55 projects.
![Assessing Results]()
Clearly, asking it to upgrade all packages missed most of them. It did upgrade the MessagePack references and almost all of the Npgsql references, which addressed the vulnerable package version.
It also identified packages that are now part of .NET 9, and I was able to remove them. I wish it did a better job of identifying breaking changes and informing the user. Moving forward, I could see using this extension to identify and manage solution-wide package upgrades once this functionality improves.
This particular upgrade experience underutilized the capabilities in the migration assistant – there are no Xamarin Forms to convert to MAUI.
WiX is another project type that would benefit from an automated migration process. As of Feb 6, 2024, WiX 3 is out of community support. Upgrading to a supported version is not trivial. If you happen to watch the Q&A portion of The Future of .NET App Modernization Streamlined with AI Build session, you’ll hear me ask about WiX support, and it sounds like the team is committing to it.
While this effort met with limited success, it still gave me a head start in migrating to the latest package versions in mass. There’s room for improvement, and I look forward to revisiting it as the tool evolves.
After the migration, I took additional steps to manage breaking changes, leveraging GitHub CoPilot and assigning PR reviews to CoPilot. That’s a subject for another article.