I got hit with NU1105 right after updating a MAUI package version, and the error message about “PackageVersion was expected to have a single value across all target frameworks” made absolutely no sense to me at first read. Took a bit of digging to realize these two errors — NU1105 and NU1202 — are actually about completely different problems that just happen to both show up as “restore failed.” Worth untangling them separately instead of treating this as one generic NuGet issue.
Quick Answer
- NU1105 means NuGet couldn’t read project information at all — often a corrupt project file, missing targets, or inconsistent multi-targeting values
- NU1202 means a specific package doesn’t support your project’s target framework — it’s a compatibility problem, not a broken project
- For NU1105, try
dotnet restorefrom the command line first to get a clearer underlying error - For NU1202, either change your target framework or downgrade/upgrade the incompatible package
- Deleting the obj and bin folders can help with stale restore state, but won’t fix an actual framework incompatibility
Why These Two Errors Get Confused
They both show up under “restore failed” in the Error List, and both stop your build cold, but they come from genuinely different root causes.
NU1105 means NuGet couldn’t even read the project’s information. This isn’t about a package being wrong — it’s that NuGet couldn’t determine what your project needs in the first place. According to Microsoft’s own documentation, this shows up in two main forms: either the project file is missing the targets required for restore, or it has an outright invalid target framework string, like a typo such as net.6.0 instead of net6.0.
NU1202 means NuGet understood your project fine, but a specific package doesn’t work with it. The package itself has assemblies for certain target frameworks, and yours isn’t one of them. This is a compatibility mismatch, not a corrupted project — the message literally lists which frameworks the package does support, which is honestly one of the more helpful error messages NuGet gives you.
Multi-targeting projects trigger NU1105 in a specific, confusing way. If a project targets multiple frameworks (common in MAUI or class libraries targeting several TFMs) and a PackageVersion or similar property ends up with different values across those targets, NuGet can’t reconcile a single answer and throws NU1105 rather than picking one arbitrarily.
There’s a less obvious cause behind some NU1105s: the project simply being unloaded in Visual Studio. If a referenced project in your solution didn’t load properly, NuGet can’t read its information either, and the fix has nothing to do with packages at all — it’s about getting that project to actually load.
Where Each Error Shows Up Most
NU1105 appears constantly after upgrading multi-targeted projects, particularly MAUI apps with several platform-specific target frameworks, where a version bump on one target doesn’t get mirrored cleanly across the others.
NU1202 shows up most when a project’s target framework gets changed (say, upgrading from .NET 6 to .NET 8) without checking whether every referenced package has already published assets for the new framework.
Both show up more in CI pipelines than local builds sometimes, since a local NuGet cache can mask a problem that a clean CI restore immediately exposes.
Error Comparison Table
| Error | Root Cause | Typical Fix |
|---|---|---|
| NU1105 (missing targets) | Project file missing NuGet.targets import | Run dotnet restore from CLI, check for corruption |
| NU1105 (invalid TFM) | Typo in target framework string | Correct the TFM string (e.g., net6.0 not net.6.0) |
| NU1105 (multi-target mismatch) | Inconsistent property values across TFMs | Align the property to one consistent value, or split TargetFrameworks temporarily to isolate |
| NU1105 (unloaded project) | A referenced project failed to load | Reload the project in Solution Explorer |
| NU1202 | Package doesn’t support your TFM | Change target framework, or find a compatible package version |
Step-by-Step: Fixing NU1105
Step 1: Try a command-line restore for a clearer error. Run dotnet restore MySolution.sln from a terminal. The command-line output is often more specific than what Visual Studio’s Error List shows, and it can reveal whether the real issue is a corrupt file or a missing targets import.
Step 2: Check for an invalid target framework string. Open the .csproj file directly and look at the TargetFramework or TargetFrameworks value carefully. Typos like an extra period are easy to introduce when editing by hand and easy to miss when reading quickly.
Step 3: Check for property value mismatches across multi-targeted frameworks. If your project targets multiple frameworks and you’re seeing a message about a property having multiple values, look for conditional PackageReference or PropertyGroup entries that might be setting different versions per target framework unintentionally.
Step 4: Isolate by temporarily reducing to a single target framework. If you’re stuck on a multi-targeting issue, temporarily set TargetFrameworks to just one value to confirm the project restores fine in isolation. This won’t fix the underlying issue but helps confirm where it lives before you re-add the other targets one at a time.
Step 5: Check whether the project is actually loaded. Look in Solution Explorer for a project shown in a lighter or unloaded state. Right-click and reload it if so — NuGet can’t read information from a project that Visual Studio hasn’t successfully loaded.
Step 6: Close Visual Studio and clear obj/bin folders if state seems stale. Visual Studio holds file handles open while running, so fully exiting first ensures cached files can actually be deleted and regenerated cleanly on the next restore.
Step-by-Step: Fixing NU1202
Step 1: Read exactly which frameworks the package supports. The NU1202 message lists the specific target frameworks the package provides assets for. Compare that list directly against your project’s TargetFramework value.
Step 2: Decide whether to change your project’s framework or the package. If the package supports an older or newer framework than what you’re targeting, you have two paths: update your project’s TargetFramework to something the package supports, or find a different version of the package that supports your current one.
Step 3: Check the package’s version history for framework support changes. Sometimes a specific package version dropped support for an older framework in a later release. Downgrading the package to a version published before that change can resolve it if upgrading your project’s framework isn’t practical right now.
Step 4: Consider a NuGet dependency resolution extension for complex cases. Microsoft DevLabs publishes a Visual Studio extension called NuGetSolver specifically designed to help identify and resolve these kinds of dependency conflicts automatically, which can save time on tangled multi-package compatibility chains.
What Actually Worked For Me
My NU1105 case came from a MAUI project after a package upgrade, and the fix that officially worked — dropping down to a single TargetFramework temporarily — felt more like a workaround than a real fix, and it was. Once I did that, the project restored fine, which told me the actual mismatch lived somewhere in how the version was applied per-target rather than a broken package itself. It took manually comparing PackageReference entries across each TFM-specific section of the csproj to spot that one platform target still referenced an old version string that hadn’t gotten updated in the same edit.
That was more tedious than clever, honestly — no shortcut found it faster than just reading the file carefully line by line. NU1202 fixes have generally been more straightforward for me in practice: once you see the supported framework list in the error, it’s usually obvious pretty quickly whether the fix is your project or the package.
Advanced Fixes and Edge Cases
Locked NuGet.targets imports can cause a persistent NU1105 that survives cache clearing. If restoring from the command line still fails after clearing caches, check that Microsoft.Common.targets is actually being imported correctly in the project file — a broken import chain won’t be fixed by deleting obj/bin since the problem is structural, not cached state.
Package downgrade warnings can compound with these errors in newer .NET tooling. Some recent .NET SDK versions treat package downgrades as errors by default in certain project types, which can interact confusingly with NU1202 fixes if you’re intentionally downgrading a package to resolve a framework mismatch — you may need to explicitly allow the downgrade rather than have it silently rejected.
CI-only failures often mean a stale local cache was hiding the real problem. If NU1202 or NU1105 only shows up in your pipeline and never locally, trust the CI result — it’s very likely exposing something your local NuGet cache had been quietly working around.
Prevention Tips
When multi-targeting a project, keep package versions explicitly consistent across all target frameworks rather than relying on conditional logic that can silently diverge. Check a package’s supported framework list before upgrading your project’s target framework, not after, to avoid the NU1202 surprise entirely. And run a clean CI restore periodically even during local development cycles, so cache-masked problems surface before they pile up.
FAQ
Does deleting the NuGet cache fix NU1202? No. NU1202 is a genuine compatibility mismatch, not a caching issue, so clearing the cache won’t change which frameworks a package actually supports.
Can I ignore NU1105 and just force a build? Not really — NU1105 means NuGet couldn’t determine what to restore at all, so the build will typically fail downstream regardless of any restore workaround.
Why did NU1202 suddenly appear after a routine package update? Some package updates drop support for older target frameworks in newer versions. Check the package’s release notes or version history for framework support changes around the version you updated to.
Is NuGetSolver worth installing for occasional errors? Probably only if you’re regularly hitting complex, tangled dependency conflicts. For a single one-off NU1202, reading the error message and adjusting manually is usually just as fast.
Editor’s Opinion
these two get lumped together in a lot of forum threads as “nuget restore broken” but theyre honestly not the same problem at all, one’s about NuGet not understanding your project and the other’s about a package genuinely not supporting your framework. reading the actual error text carefully saves a lot of wasted troubleshooting time here, more than usual even.
