Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NET 9-windows project can't project-reference a net8-windows project #45764

Open
dotMorten opened this issue Jan 7, 2025 · 3 comments
Open
Labels
Area-NetSDK untriaged Request triage from a team member

Comments

@dotMorten
Copy link

Describe the bug

If I create a .NET 8 WinUI Class library, and then reference that in a .NET 9 MAUI project, I get the following build error:

C:\Program Files\dotnet\sdk\9.0.101\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(266,5): error NETSDK1005: Assets file 'E:\source\WinUIClassLibraryNet8\WinUIClassLibraryNet8\obj\project.assets.json' doesn't have a target for 'net9.0-windows10.0.19041.0'. Ensure that restore has run and that you have included 'net9.0-windows10.0.19041.0' in the TargetFrameworks for your project.

To Reproduce

  • Create a WinUI .NET 8 Class Library
  • Create a .NET MAUI .NET 9 Class Library
  • Add a project reference to the NET8 WinUI project from the NET9 MAUI project
    <ProjectReference Include="..\WinUIClassLibraryNet8\WinUIClassLibraryNet8.csproj" Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'windows'">
  • Build the project and observe the build error mentioned above.

Repro project: WinUIClassLibraryNet8.zip

Exceptions (if any)

project.assets.json' doesn't have a target for 'net9.0-windows10.0.19041.0'. Ensure that restore has run and that you have included 'net9.0-windows10.0.19041.0' in the TargetFrameworks for your project.

Further technical details

dotnet --info

.NET SDK:
Version: 9.0.101
Commit: eedb237
Workload version: 9.0.100-manifests.4a280210
MSBuild version: 17.12.12+1cce77968

Runtime Environment:
OS Name: Windows
OS Version: 10.0.22631
OS Platform: Windows
RID: win-x64
Base Path: C:\Program Files\dotnet\sdk\9.0.101\

.NET workloads installed:
[ios]
Installation Source: VS 17.12.35527.113
Manifest Version: 18.1.9163/9.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.sdk.ios\18.1.9163\WorkloadManifest.json
Install Type: Msi

[maui-windows]
Installation Source: VS 17.12.35527.113
Manifest Version: 9.0.0/9.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.sdk.maui\9.0.0\WorkloadManifest.json
Install Type: Msi

[android]
Installation Source: VS 17.12.35527.113
Manifest Version: 35.0.7/9.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.sdk.android\35.0.7\WorkloadManifest.json
Install Type: Msi

[maccatalyst]
Installation Source: VS 17.12.35527.113
Manifest Version: 18.1.9163/9.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.sdk.maccatalyst\18.1.9163\WorkloadManifest.json
Install Type: Msi

Configured to use loose manifests when installing new manifests.

Host:
Version: 9.0.0
Architecture: x64
Commit: 9d5a6a9aa4

.NET SDKs installed:
8.0.404 [C:\Program Files\dotnet\sdk]
9.0.101 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
Microsoft.AspNetCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 9.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.11 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 9.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
x86 [C:\Program Files (x86)\dotnet]
registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
Not set

global.json file:
Not found

Learn more:
https://aka.ms/dotnet/info

Download .NET:
https://aka.ms/dotnet/download

- The IDE (VS / VS Code/ VS4Mac) you're running on, and its version: VS2022 17.12.3

Workarounds:

Add the following to the project reference:
<AdditionalProperties>TargetFramework=net8.0-windows10.0.19041.0</AdditionalProperties>
or change the WinUI class library to use TargetFrameworks instead of TargetFramework which seem silly when there's just one TFM.

@dotnet-issue-labeler dotnet-issue-labeler bot added Area-NetSDK untriaged Request triage from a team member labels Jan 7, 2025
@baronfel
Copy link
Member

baronfel commented Jan 7, 2025

The proximate cause is that the GetMrtPackagingOutputs Target from the Microsoft.WindowsAppSDK package ends up calling the ResolvePackageAssets Target on the .NET 8-targeted project, but using the .NET 9 TFM from the MAUI app. It feels like there should be a negotiation step that should happen somewhere. Here's the binlog showing this. @dsplaisted / @rainersigwald do we have any guidance that we could give to the WindowsAppSDK team to help negotiate better TFMs?

msbuild.binlog.zip

@dsplaisted
Copy link
Member

The zip with the binlog seem like it's corrupted, so I couldn't look at it.

Here's the documentation for how we handle TargetFramework negotiation for project references: https://github.com/dotnet/msbuild/blob/main/documentation/ProjectReference-Protocol.md

I'm not sure how GetMrtPackagingOutputs should work, but probably it should hook into the existing ProjectReference handling or follow a similar pattern.

@baronfel
Copy link
Member

baronfel commented Jan 8, 2025

Oh the zip isn't really a zip - it's just a renamed binlog.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-NetSDK untriaged Request triage from a team member
Projects
None yet
Development

No branches or pull requests

3 participants