Central Package Management causes build failure without PackageReference

[dansiegel]

NuGet Product Used

dotnet.exe, MSBuild.exe, NuGet SDK

Product Version

7.0.200-preview.22628.1

Worked before?

No response

Impact

It's more difficult to complete my work

Repro Steps & Context

When using Central Package Management I may have a number of projects within a given solution. Some of those projects may contain Package References which are required because they are core projects without Framework references. When using .NET MAUI the SDK provides Implicitly Defined Package References. This fails when a PackageVersion exists within the Directory.Packages.props even though the Maui project does not include a PackageReference to the package.

https://github.com/dotnet/maui/blob/5b6663d61c922f6c971542e8f8751303a53ed364/src/Workload/Microsoft.Maui.Sdk/Sdk/BundledVersions.in.targets#L63-L81

<!-- Directory.Packages.Props -->
<Project>
  <ItemGroup>
    <PackageVersion Include="Microsoft.Extensions.DependencyInjection" Version="SomeVersion" />
  </ItemGroup>
</Project>

<!-- Some Services Project -->
<Project Sdk="Microsoft.Net.Sdk">
  <PropertyGroup>
    <TargetFramework>net7.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.Extensions.DependencyInjection" />
  </ItemGroup>
</Project>

<!-- Project Targeting Maui-->
<Project Sdk="Microsoft.Net.Sdk">
  <PropertyGroup>
    <TargetFrameworks>net7.0-ios;net7.0-android;net7.0-etc</TargetFrameworks>
    <UseMaui>true</UseMaui>
  </PropertyGroup>
</Project>

In the scenario shown here... the Services Project would work just fine as expected, however the Maui project wouldn't due to the Implicitly Defined References.

Verbose Logs

No response

[zivkan]

@dansiegel I tried to create a sample using the information in your bug report, but dotnet restore worked without error. Can you share a reproduction please?

[MartyIX]

This issue dotnet/maui#12953 is the original one and it has a repro link so maybe it is helpful for additional context and understanding of this issue.

[dansiegel]

@zivkan I ran into this with Prism. We were using the references for some unit tests, you'll see the work around for our purposes here. Thanks @MartyIX for providing a repro for this :)

https://github.com/PrismLibrary/Prism/blob/1b6bf93f04f46c9958210881ef4b7fcd6980d7c2/Directory.Packages.props#L60-L63

[nkolev92]

Just digesting the information provided into a few concepts:

• CPM requires versions to be declare in the PackageVersion element.
• CPM allows packages marked with IsImplicitlyDefined to specify versions in the project file as those are not meant to be changed by the end user, but rather are supposed to be versioned with the .NET SDK.
• Maui projects declare packages with IsImplicitlyDefined.
• dotnet new maui declares packages in the project file without IsImplicitlyDefined

	<ItemGroup Condition="$(TargetFramework.Contains('-windows'))">
		<!-- Required - WinUI does not yet have buildTransitive for everything -->
		<PackageReference Include="Microsoft.WindowsAppSDK" Version="1.0.0" />
		<PackageReference Include="Microsoft.Graphics.Win2D" Version="1.0.0.30" />
	</ItemGroup>

So there's really 2 potential problems + some thoughts on moving forward:

• Changing versions for packages that Maui projects declare as implicitly defined, that are packages users would sometimes prefer to change versions for.
  • Are these packages ones that have to be tied to the SDK? Is it something that end users should be able to change?
• Maui templates declare packages inside the project file that are not implicitly defined?
  • Should these packages be implicitly defined? It's possible no, so the user could manage them, but the SDK suggests that maybe they should be?

[MartyIX]

@nkolev92 Should your findings/observations be posted to dotnet/maui#12953 so that it gains some attention?

[aortiz-msft]

@rrelyea - Would you please look at this issue related to MAUI in 2023-06?

[nkolev92]

The linked issue has been addressed. I don't think there's anything else to be done here.