TIL installing a .NET SDK can break .NET MAUI builds

Introduction
I was flummoxed when working with a .NET MAUI app when I opened the application and it wouldn’t build. I had previously worked on it a month or so ago and had set everything up on my laptop so it would build, yet without any code changes there were suddenly 5 build errors.
After a lot of time wasted trying to fix the problem, I eventually realised the key piece of information I hadn’t considered — the previous day, I had installed the .NET 10 SDK on my laptop for the first time. This broke the build for my .NET MAUI app, and this blog post explains why that happened. At the end, I reflect on my use of AI in solving this problem, and how it both helped and hindered.
Build errors
I got 5 build errors, two of which were basically the same (NETSDK1202 for two different workloads).
9>Microsoft.NET.EolTargetFrameworks.targets(38,5): Error NETSDK1202 : The workload 'net8.0-android' is out of support and will not receive security updates in the future. Please refer to https://aka.ms/maui-support-policy for more information about the support policy. 9>ProjectName.App.csproj: Error NU1012 : Platform version is not present for one or more target frameworks, even though they have specified a platform: net8.0-android, net8.0-ios 9>ProjectName.App.csproj: Error NU1015 : The following PackageReference item(s) do not have a version specified: Microsoft.Maui.Controls, Microsoft.Maui.Controls.Compatibility 9>Microsoft.NET.EolTargetFrameworks.targets(38,5): Error NETSDK1202 : The workload 'net8.0-ios' is out of support and will not receive security updates in the future. Please refer to https://aka.ms/maui-support-policy for more information about the support policy. 9>Microsoft.NET.TargetFrameworkInference.targets(252,5): Error NETSDK1135 : SupportedOSPlatformVersion 11.0 cannot be higher than TargetPlatformVersion 1.0.
Explanation
At the root of my solution was a global.json file which looked like this:
{
"sdk": {
"version": "8.0.0",
"rollForward": "latestMajor",
"allowPrerelease": false
}
}
The application was using .NET MAUI 8, which is why version is set to 8.0.0. However, it uses "rollForward": "latestMajor". This means it uses the latest .NET SDK which is installed. Installing the .NET 10 SDK effectively changed what version the application is using. Using the later version, the dotnet workloads which the MAUI project used weren’t compatible.
Running dotnet workload restore installed workloads which were compatible with .NET 10, but that broke things in the project because it’s not yet upgraded to .NET 10.
Solution
Once I understood this problem, the fix was a simple change to the json. I used "rollForward": "latestFeature" instead, which means it uses the latest version of v8, but doesn’t upgrade to later major versions. Once I’d cleaned the output directories, the build then ran as it had before I’d installed the .NET 10 SDK and passed.
Lessons about using AI
I used AI tools in trying to fix this problem, because to begin with I had no idea what was wrong. AI was both a help and a hindrance, but definitely more of a hindrance overall. Because I was out of my comfort zone, I was too slow to abandon the use of AI even though I could see it wasn’t making any progress.
I started by trying to get GitHub Copilot to fix the build errors. Unfortunately it dug itself into a hole making unsuitable changes, and couldn’t get out of it. It ran the build repeatedly, seemingly unable to believe the build was still broken, and determined to think that it could fix them by clearing package caches one more time. With hindsight, I wonder if GitHub Copilot, as a coding agent, has been biased toward action too much for this problem. It failed to do any diagnosis, and because I didn’t realise what had caused the problem I wasn’t able to provide that information.
I had much more success asking Claude (via the web chat interface) about the errors. It’s hard to say how much the difference was caused by using Claude rather than Copilot, as by this point I’d realised the possibility that the .NET SDK installation was the root cause, and this was critical information. Either way, it was able to explain the root cause and how to fix it, and was much more useful.




