maui: Using central package management causes build breaking NU1009 with MAUI projects

Description

Building a MAUI project using central package management does not seem possible because of the NU1009 error. It reads as a warning, but is in fact a build breaking error.

I attached a minimal reproduction containing a MAUI project and a library that this project depends on, which itself requires the ILogger abstraction from Microsoft.Extensions.Logging.Abstractions,. If you build it as is, the build fails with:

error NU1009: The packages Microsoft.Extensions.Logging.Abstractions;Microsoft.Extensions.Logging.Abstractions;Microsoft.Extensions.Logging.Abstractions;Microsoft.Extensions.Logging.Abstractions 
 are implicitly referenced. You do not typically need to reference them from your project or in your central package versions management file. For more information, see https://aka.ms/sdkimplicitrefs

If you fix this error by removing the reference to Microsoft.Extensions.Logging.Abstractions (what the error suggests you do), the build fails with a collection of errors, due to the fact that the ILogger interface is cannot be found anymore in the library which the MAUI project depends on.

I also tried using https://learn.microsoft.com/en-gb/dotnet/core/project-sdk/msbuild-props#disableimplicitframeworkreferences, but it seems it is ignored altogether and has no effect.

Moreover, it doesn’t seem to happen with other project types such as web API or console app.

Steps to Reproduce

Clone the attached reproduction project repository
Run dotnet build at the root of the cloned repo

Link to public reproduction project repository

https://github.com/hypdeb/repros

Version with bug

7.0 (current)

Last version that worked well

Unknown/Other

Affected platforms

Windows

Affected platform versions

This is a build failure

Did you find any workaround?

No response

Relevant log output

No response

About this issue

Original URL
State: closed
Created a year ago
Reactions: 8
Comments: 46 (17 by maintainers)

Commits related to this issue

Added condition as suggested here https://github.com/dotnet/maui/issues/12953#issuecomment-1409212256 — committed to hypdeb/repros by hypdeb a year ago
[msbuild] fix NuGet Central Package Management (CPM) Context: https://learn.microsoft.com/nuget/consume-packages/Central-Package-Management Fixes: https://github.com/dotnet/maui/issues/12953 @mattle... — committed to jonathanpeppers/maui by jonathanpeppers 10 months ago
[msbuild] fix NuGet Central Package Management (CPM) (#17235) Context: https://learn.microsoft.com/nuget/consume-packages/Central-Package-Management Fixes: https://github.com/dotnet/maui/issues/1295... — committed to dotnet/maui by jonathanpeppers 10 months ago

Most upvoted comments

I think that may be a good idea tbh… I see the Microsoft.Extensions packages have more than one tfm… I am thinking essentials and graphics could fall into this category. The main maui framework is tfm specific, but the extras are extensions… Let me do a PR and see what shakes out. Probably can do the same for resizetizer as well…

Thanks for this idea that I totally should have considered since I did nuget analysis when we transitioned.

mattleibow on Aug 18, 2023

OK, I am not sure this will be possible to make work in net7. The issue is just that AndroidX is totally a free-for-all, so many API changes in minor version bumps. You can see the pain Xamarin.Forms had with “I Updated AndroidX something from 2.1.1 to 2.1.2 and now my app crashes”.

Everything can work, except that a minor update to any AndroidX packages requires a rebuild and even a re-working of maui. The “nice” thing about workloads is that now you can’t update to break things 😆😭😆😭😆.

With .NET 8 things are no longer workloads so we can potentially look at making .NET 9 things work with .NET 8. For example, a .NET 9 package can have both .NET 8 and .NET 9 TFM. This will mean that we can do “breaking” package updates, and not break people on older things.

Other than that, my PR got merged and probably will go out in the next next version of MAUI: https://github.com/dotnet/maui/pull/17046

This will allow you to disable all the implicit things, and then use the CPM to track it. This does not allow you to update those AndroidX things as it will explode your app.

mattleibow on Aug 29, 2023

The Maui SDK injects package references for you implicitly: https://github.com/dotnet/maui/blob/main/src/Workload/Microsoft.Maui.Sdk/Sdk/BundledVersions.in.targets#L70

When you manage your package versions centrally, NuGet does not want you to define versions for implicitly defined package references since an SDK is trying to manage it for you.

In order to have a <PackageVersion /> in your Directory.Packages.props for a package but not get this error, you’ll need to condition it so that when building a Maui project it is not defined:

<Project>
  <PropertyGroup>
    <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
  </PropertyGroup>
  <ItemGroup>
    <PackageVersion Include="Microsoft.Extensions.Logging.Abstractions" Version="7.0.0" Condition="'$(UseMaui)' != 'true'" />
  </ItemGroup>
</Project>

The $(UseMaui)' != 'true' condition here disables the <PackageVersion /> item for Maui projects and fixes the NU1009 error.

jeffkl on Jan 30, 2023

Just add net7.0 targets to the Maui Essentials package? Then you don’t even need to add any extra props…

Cheesebaron on Aug 18, 2023