sdk
sdk copied to clipboard
dotnet
dotnet restore doesn't respect the <RuntimeIdentifier> for sdk-style project.
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
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?
@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.
@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.
@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).
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.
@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.
This worked for me. I was in a similar situation—separating restore from build for a CLI app on .NET 8.
