dotnet restore --getProperty:ProjectAssetsFile returns an empty string for multi targeted projects

[0xced]

Describe the bug

The --getProperty option of dotnet commands is supposed to return the specified property as JSON. But performing dotnet restore --getProperty:ProjectAssetsFile on a multi targeted project returns an empty string.

I wonder if it's related to #38956.

To Reproduce

1. Create a project file with multiple target frameworks

MyLibrary.csproj

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFrameworks>net8.0;net9.0</TargetFrameworks>
  </PropertyGroup>

</Project>

2. Run the following command

dotnet restore MyLibrary.csproj --getProperty:ProjectAssetsFile --getProperty:TargetFrameworks

This produces the following output. Notice how ProjectAssetsFile is an empty string.

{
  "Properties": {
    "ProjectAssetsFile": "",
    "TargetFrameworks": "net8.0;net9.0"
  }
}

Workaround

I found a workaround by adding --getTargetResult:_LoadRestoreGraphEntryPoints to the restore command.

dotnet restore MyLibrary.csproj --getProperty:ProjectAssetsFile --getProperty:TargetFrameworks -getTargetResult:_LoadRestoreGraphEntryPoints

Now the ProjectAssetsFile has a valid value!

But I don't really like depending on the undocumented _LoadRestoreGraphEntryPoints target and on what seems to be a side effect!

{
  "Properties": {
    "ProjectAssetsFile": "/private/tmp/MyLibrary/obj/project.assets.json",
    "TargetFrameworks": "net8.0;net9.0"
  },
  "TargetResults": {
    "_LoadRestoreGraphEntryPoints": {
      "Result": "Success",
      "Items": [
        {
          "Identity": "/private/tmp/MyLibrary/MyLibrary.csproj",
          "FullPath": "/private/tmp/MyLibrary/MyLibrary.csproj",
          "RootDir": "/",
          "Filename": "MyLibrary",
          "Extension": ".csproj",
          "RelativeDir": "/private/tmp/MyLibrary/",
          "Directory": "private/tmp/MyLibrary/",
          "RecursiveDir": "",
          "ModifiedTime": "2025-06-16 22:48:27.8055988",
          "CreatedTime": "2025-06-16 22:47:50.9395942",
          "AccessedTime": "2025-06-16 22:48:27.8879172",
          "DefiningProjectFullPath": "/usr/local/share/dotnet/sdk/9.0.301/NuGet.targets",
          "DefiningProjectDirectory": "/usr/local/share/dotnet/sdk/9.0.301/",
          "DefiningProjectName": "NuGet",
          "DefiningProjectExtension": ".targets"
        }
      ]
    }
  }
}

Further technical details

dotnet --info

.NET SDK:
 Version:           9.0.301
 Commit:            a596cd22e2
 Workload version:  9.0.300-manifests.b2ed98c7
 MSBuild version:   17.14.5+edd3bbf37

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  14.7
 OS Platform: Darwin
 RID:         osx-arm64
 Base Path:   /usr/local/share/dotnet/sdk/9.0.301/

.NET workloads installed:
There are no installed workloads to display.
Configured to use loose manifests when installing new manifests.

Host:
  Version:      9.0.6
  Architecture: arm64
  Commit:       3875b54e7b

.NET SDKs installed:
  6.0.428 [/usr/local/share/dotnet/sdk]
  8.0.411 [/usr/local/share/dotnet/sdk]
  9.0.301 [/usr/local/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 6.0.36 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.17 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 9.0.6 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 6.0.36 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.17 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 9.0.6 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
  x64   [/usr/local/share/dotnet/x64]
    registered at [/etc/dotnet/install_location_x64]

Environment variables:
  Not set

global.json file:
  Not found

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

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

[dotnet-policy-service[bot]]

Thanks for creating this issue! We believe this issue is related to NuGet tooling, which is maintained by the NuGet team. Thus, we closed this one and encourage you to raise this issue in the NuGet repository instead. Don’t forget to check out NuGet’s contributing guide before submitting an issue!

If you believe this issue was closed out of error, please comment to let us know.

Happy Coding!

[0xced]

Addendum: the workaround does not work the first time the dotnet restore ... command is run. It only works the second time, when a restore has already been previously performed.