Why does dotnet publish sometimes need nuget.org even though the .NET SDK is installed

[bitbonk]

We often run into the problem that dotnet publish fails because some common nuget packages cannot be found when it is not possible to access nuget.org. This can happen when there is no internet connection or when nuget.org was not allowed/configured as a package source (e.g. there is a <clear/> in nuget.config).

In ta recent occurrence of this behavior we ran the following command:

dotnet publish --configuration=Release -p:PublishReadyToRun=true -p:PublishSingleFile=true --runtime win-x64 --self-contained "AdventureWorks.MyWpfDesktopApp"

And got the following error message (hand-translated from German):

c:\source\AdventureWorks\src\AdventureWorks.Common\AdventureWorks.Common.csproj : error NU1102: The package "Microsoft.NETCore.App.Runtime.win-x64" of version (= 6.0.22) was not found. [c:\source\AdventureWorks\src\AdventureWorks.MyWpfDesktopApp\AdventureWorks.MyWpfDesktopApp.csproj

We had the following global.json file in the solution folder:

{
  "sdk": {
    "version": "6.0.406",
    "rollForward": "latestPatch"
  }
}

The .NET SDK 6.0.406 was installed on the target machine.

The questions now are (updated after clarification):

1. Why does dotnet publish need nuget.org? Shouldn't the package Microsoft.NETCore.App.Runtime.win-x64 be part of the .NET SDK itself?
2. What can we do make dotnet publish succeed without ever giving the target build machine access to the nuget.org or the internet altogether? Is the only solution to manually download the missing packages and put the into a local feed?
3. How can we tell, what additional dependencies dotnet publish might needs to pull from nuget.org that are not directly referenced by our csprojs or by the nupkgs referenced in our solution?

1. Why does dotnet publish need nuget.org? If a prior dotnet restore and dotnet build succeeded, shouldn't the .NET SDK itself contain everything that is needed for dotnet publish?
2. What can we do make dotnet publish succeed without ever giving the target build machine access to the nuget.org or the internet altogether? Is the only solution to manually download the missing packages and put the into a local feed?

[alexrp]

Why does dotnet publish need nuget.org? If a prior dotnet restore and dotnet build succeeded, shouldn't the .NET SDK itself contain everything that is needed for dotnet publish?

Did you run that dotnet build with all the same configuration/properties?

What can we do make dotnet publish succeed without ever giving the target build machine access to the nuget.org or the internet altogether? Is the only solution to manually download the missing packages and put the into a local feed?

Use --no-build which implies --no-restore. But again, you must use the same configuration/properties for the dotnet build step that you use for dotnet publish, or required assets might be missing.

It can be helpful to set some of these in the project file to ensure that this happens. E.g. PublishReadyToRun, PublishSingleFile, RuntimeIdentifier, SelfContained.

[bitbonk]

@alexrp

Did you run that dotnet build with all the same configuration/properties?

Oops my bad, we actually did not run dotnet build or dotnet restore prior to dotnet publish but that's actually not the interesting part in our case. Sorry for the confusion.

In our case we can never give the build server direct access to nuget.org and therefore need to copy all required nuget packages for building and publishing to a local feed. This local feed represents the collection of nuget packages that have been approved for usage.

So let me rephrase my questions:

1. Why does dotnet publish need nuget.org? Shouldn't the package Microsoft.NETCore.App.Runtime.win-x64 be part of the .NET SDK itself?
2. What can we do to make dotnet publish succeed without ever giving the target build machine access to the nuget.org or the internet altogether? Is the only solution to manually download the missing packages and put the into a local feed?
3. How can we tell, what additional dependencies dotnet publish might needs to pull from nuget.org that are not directly referenced by our csprojs or by the nupkgs referenced in our solution?

[alexrp]

Why does dotnet publish need nuget.org? Shouldn't the package Microsoft.NETCore.App.Runtime.win-x64 be part of the .NET SDK itself?

I can't really answer the general question of why it's set up the way it is, but this behavior is expected AFAIK.

What can we do make dotnet publish succeed without ever giving the target build machine access to the nuget.org or the internet altogether? Is the only solution to manually download the missing packages and put the into a local feed?

I suppose; Microsoft.NETCore.App.Runtime.win-x64 is no different from any other NuGet package in this regard.

How can we tell, what additional dependencies dotnet publish might needs to pull from nuget.org that are not directly referenced by our csprojs or by the nupkgs referenced in our solution?

I think you'll want to do a dotnet publish with all the right properties set and then refer to obj/project.assets.json.

[teo-tsirpanis]

Shouldn't the package Microsoft.NETCore.App.Runtime.win-x64 be part of the .NET SDK itself?

There is no 1-1 correspondence between .NET runtimes and SDKs. You can use the .NET 8 SDK to publish a .NET 7 app for example.

[hez2010]

Why does dotnet publish need nuget.org? Shouldn't the package Microsoft.NETCore.App.Runtime.win-x64 be part of the .NET SDK itself?

This is because we are allowing cross building for dotnet publish. You can use dotnet publish to publish a self-contained app then you may publish a linux-x64 one on Windows, in this case the Windows x64 SDK doesn't contain the necessary components which are needed by Linux x64. So we instead have different app runtime packs on the nuget and fetch it when you publish a self-contained app.

[lg2de]

But, why downloading the packages if win-x64 is installed and the publish is targeting win-x64.
All relevant files should already be existing locally, isn't it?