Resolving NuGet Dependency Conflicts in Xamarin Corporate Projects

Question

Resolving NuGet Dependency Conflicts in Xamarin Corporate Projects

Michael Smith 0

I'm currently trying to develop a proof-of-concept for our mobile division using the Play plugin and facing NuGet dependency conflicts. But every time I attempt to integrate these within our corporate Xamarin environment using the <PackageReference> format, the build immediately breaks. I’ve been tasked by the CTO to have this prototype ready, yet I’m stuck staring at a screen full of red error logs that I can't seem to resolve. How do I fix these library version mismatches?

0 comments

2 answers

Your answer

Answer 1

Follow these steps to resolve NuGet dependency conflicts and library version mismatches in a Xamarin project using <PackageReference>:

Identify the exact error codes and packages
- Look in the build output and Package Manager Console for errors like NU1106, NU1107, NU1102, or NU1202.
- Note which packages and versions are in conflict (for example, two different versions of the same Play plugin or its dependencies).
Fix version conflicts between packages (NU1107 / diamond dependencies)
- When two packages require different versions of the same dependency (classic “diamond dependency”), NuGet must pick one version.
- If the error resembles NU1107 (version conflict detected for PackageX):
  1. Edit the main Xamarin project’s .csproj.
  2. Add a direct <PackageReference> for the conflicting package with the version to use, typically the higher version:
```
        <ItemGroup>
          <PackageReference Include="PackageX" Version="4.0.0" />
        </ItemGroup>
```
  3. Restore packages and rebuild.
- This explicitly tells NuGet which version to unify on and resolves the conflict.
Avoid overly strict or conflicting version ranges (NU1106)
- If the error is like NU1106 (unable to satisfy conflicting requests):
  - Open the .csproj and look for <PackageReference> entries with exact or upper-bounded versions, for example:
```
       <PackageReference Include="ExamplePackage" Version="[1.0]" />
       <PackageReference Include="ExamplePackage" Version="[1.0,2.0)" />
```
  - Replace exact or tight ranges with a minimum version only, which is more “open-ended” and easier for NuGet to resolve:
```
       
       <PackageReference Include="ExamplePackage" Version="1.0.0" />
```
  - Re-run restore and build.
Ensure requested versions actually exist (NU1102)
- If the error is like NU1102 (unable to find package with version >= X):
  1. Open the .csproj and verify the Version attribute for the failing package.
  2. Change it to a version that actually exists on your configured sources.
  3. Check NuGet.Config in the corporate environment to ensure the correct feeds are configured and not blocking the needed source.
  4. Restore packages and rebuild.
Fix target framework incompatibilities (NU1202 / “not compatible” errors)
- If the error says a package “is not compatible with” the project’s target framework (for example, NU1202):
  1. Check the Xamarin project’s <TargetFramework> (or <TargetFrameworks>) in the .csproj.
  2. Compare with the frameworks listed in the error message as supported by the package.
  3. Use one of these options:
    - Retarget the project to a framework supported by the Play plugin and its dependencies.
    - Or choose a different version of the plugin that supports the current target framework.
  4. After changing the target framework or package version, restore and rebuild.
Prefer minimum-only version declarations for your own libraries
- For internal corporate libraries referenced via NuGet:
  - Use a minimum version only (no upper bound, no exact range) to reduce conflicts:
```
       <PackageReference Include="Corporate.Library" Version="1.2.0" />
```
  - Avoid exact versions ([1.2.0]) or upper limits ([1.2.0,2.0.0)), as they increase the chance of conflicts when combined with third-party packages.
If using packages.config in older projects
- If any legacy Xamarin projects still use packages.config instead of <PackageReference>:
  - Be aware NuGet selects the lowest major.minor version that satisfies dependencies, which can differ from <PackageReference> behavior.
  - Mixed stable/prerelease graphs are not allowed with ranges like [1.0.0, 2.0.0).
  - Consider migrating to <PackageReference> for more predictable restore and easier conflict resolution.
Use tooling help if available
- In Visual Studio, consider using the NuGetSolver extension (if permitted in the corporate environment) to automatically analyze and suggest fixes for dependency conflicts.

Applying these steps systematically—first unifying versions via direct references, then relaxing strict version ranges, verifying available versions, and aligning target frameworks—will resolve most NuGet dependency conflicts in a Xamarin corporate project.

References:

Answer 2

Hello,

what you are running into is a classic NuGet dependency resolution conflict in Xamarin projects when using <PackageReference> instead of the older packages.config. The Play plugin you are trying to integrate likely depends on specific versions of Xamarin.AndroidX or Google Play Services libraries, while your corporate Xamarin baseline already pins different versions of those same assemblies. When MSBuild restores with <PackageReference>, it enforces a single version per package across the solution, so mismatches immediately break the build.

The first step is to inspect the exact error messages in your build output. They will usually show something like “Version conflict detected for Xamarin.AndroidX.Core. Installed: 1.9.0. Requested: 1.8.0 by Play.Plugin.” That tells you which package is pulling in the conflicting version. You can confirm by running dotnet restore --force-evaluate or checking the obj/project.assets.json file, which lists the resolved dependency graph.

Once you identify the conflict, the correct approach is to unify the versions across your solution. In practice, you add explicit <PackageReference> entries in your main project for the conflicting libraries, pinned to the highest version that satisfies all dependencies. For example:

xml

</ItemGroup>

This forces NuGet to resolve to those versions, and downstream packages will align. If the Play plugin is hard‑coded to an older version, you may need to update to a newer release of the plugin that supports the current AndroidX baseline. If no update exists, you can use a BindingRedirect equivalent in Xamarin by editing the .csproj and ensuring the AndroidXMigration tooling is enabled, but the cleanest solution is always to standardize on the latest supported versions.

Also, make sure your corporate Xamarin environment is using the latest Visual Studio and Xamarin workload updates. Older Xamarin.Android builds had incomplete support for <PackageReference> and would throw false conflicts. Updating to Visual Studio 2022 with the latest Xamarin.Android SDK resolves many of these issues.

In short: check the project.assets.json to see which packages are clashing, pin the versions explicitly in your .csproj, and update the Play plugin if necessary. That will stabilize your build and allow you to move forward with the proof‑of‑concept.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

Domic Vo.