dotnet restore doesn't respect the <RuntimeIdentifier> for sdk-style project.

[dxynnez]

Describe the bug

We are migrating our Azure Functions (isolated mode) to .Net 8 but got following errors when trying to build & publish the app as self-contained:

NETSDK1112: The runtime pack for Microsoft.NETCore.App.Runtime.win-x64 was not downloaded. Try running a NuGet restore with the RuntimeIdentifier 'win-x64'.
NETSDK1112: The runtime pack for Microsoft.AspNetCore.App.Runtime.win-x64 was not downloaded. Try running a NuGet restore with the RuntimeIdentifier 'win-x64'.

It appears that in .Net 8, the dotnet restore would not respect the RID specified in the sdk-style project - we got a similar error when trying to publish a console app in the same way.

To Reproduce

Create an Azure Funtions for .Net 8.0 Isolated using the VS built-in template, Add <RuntimeIdentifier>win-x64</RuntimeIdentifier> into the csproj.

Make sure the 'Microsoft.NETCore.App.Runtime' is not in the local nuget cache.

dotnet restore
dotnet build --configuration release --no-restore --self-contained true
dotnet publish --configuration release --no-restore --no-build --self-contained true

Exceptions (if any)

NETSDK1112: The runtime pack for Microsoft.NETCore.App.Runtime.win-x64 was not downloaded. Try running a NuGet restore with the RuntimeIdentifier 'win-x64'.
NETSDK1112: The runtime pack for Microsoft.AspNetCore.App.Runtime.win-x64 was not downloaded. Try running a NuGet restore with the RuntimeIdentifier 'win-x64'.

Further technical details

• Include the output of dotnet --info
• The IDE (VS / VS Code/ VS4Mac) you're running on, and its version

[dxynnez]

Hello team, can someone help to take a look at this?

[marcpopMSFT]

Can you provide a binlog from the restore so we can see what RID it's using? Is it possible you have a solution or directory.build.props that would be affecting the RID used?

[dxynnez]

@marcpopMSFT

here you go
restore.zip
I do see RuntimeIdentifiers = ;win-x64 in it.

Is it possible you have a solution or directory.build.props that would be affecting the RID used?

The behavior can be easily repro with a brand new Azure Function (isolated-mode) / console app created using the template so that shouldn't be the case.

[marcpopMSFT]

@dxynnez Can you try dotnet restore -p:SelfContained=true? I think what's happening is that the restore doesn't know you're going to do self-contained build and so isn't downloading the runtime packs. Then the build is done without restore which includes not restoring key sdk pieces like the runtime packs.

CC @baronfel for feedback on the split restore/build.

[dxynnez]

@marcpopMSFT sry was caught up by some other tasks.

Yes, that would work.

But that's not required if the project references the web SDK (Microsoft.NET.Sdk.Web). I am not sure if this is by-design, but the inconsistency is very confusing (and so is the split restore / build).

[dxynnez]

@marcpopMSFT any insight on this? Thank you!

[marcpopMSFT]

Triage: We discussed this and aren't sure why the Web sdk would behave differently. It didn't behave differently when we did a simple test but there's a lot of different defaults in the web sdk that we can't be sure. Either way, we determined that splitting restore and build while a valid scenario, does require specifying the right settings with restore and there isn't a change we're planning on making at this time for this.

It sounds like you're unblocked now by passing SelfContained on the CLI so I'll go ahead and close this.