dotnet restore inconsistencies across platforms

[winterqt]

I'm a maintainer of Nixpkgs, the package repository for the Nix package manager. One of our explicit requirements is complete reproducibility, so we employ sandboxes and other restrictions to build packages. Our .NET packages currently do three things to solve the problem of remote dependencies:

1. Create a list of packages needed, using dotnet restore and a script to pull metadata. This results in a file that looks like this
2. Build a local source from those packages
3. Use it when running dotnet restore (in an airgapped sandbox)

This has, for the most part, worked great. However, there's an issue that I discovered that makes what we currently do pretty fragile.

(I should note that if you look at our current dotnet restore invocations, we don't explicitly specify a RID to build for, which will clearly cause issues. I'm working to fix this, and everything that I've described below is in the context of explicitly specifying one.)

This root cause is how we use dotnet restore to get the list of packages, and how this interacts with bundled app hosts. For example, if I run a restore for linux-arm64 on linux-arm64, it produces a packages directory that does not include Microsoft.NETCore.App.Host.linux-arm64. Therefore, if the package list is built on a linux-arm64 machine, and then that list is used to try to compile a linux-arm64 build from a non-linux-arm64 system, it will fail. If the list is built on another system, this issue does not occur, but this is obviously not ideal.

A workaround suggested to me was to set NetCoreTargetingPackRoot to an invalid path during the restore, which would forcibly download the required app host.

Is this a workaround that can be utilized, or is there a better way to do our dependency management as a whole?

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

Issue Details

---

I'm a maintainer of Nixpkgs, the package repository for the Nix package manager. One of our explicit requirements is complete reproducibility, so we employ sandboxes and other restrictions to build packages. Our .NET packages currently do three things to solve the problem of remote dependencies:

1. Create a list of packages needed, using dotnet restore and a script to pull metadata. This results in a file that looks like this
2. Build a local source from those packages
3. Use it when running dotnet restore (in an airgapped sandbox)

This has, for the most part, worked great. However, there's an issue that I discovered that makes what we currently do pretty fragile.

(I should note that if you look at our current dotnet restore invocations, we don't explicitly specify a RID to build for, which will clearly cause issues. I'm working to fix this, and everything that I've described below is in the context of explicitly specifying one.)

This root cause is how we use dotnet restore to get the list of packages, and how this interacts with bundled app hosts. For example, if I run a restore for linux-arm64 on linux-arm64, it produces a packages directory that does not include Microsoft.NETCore.App.Host.linux-arm64. Therefore, if the package list is built on a linux-arm64 machine, and then that list is used to try to compile a linux-arm64 build from a non-linux-arm64 system, it will fail. If the list is built on another system, this issue does not occur, but this is obviously not ideal.

A workaround suggested to me was to set NetCoreTargetingPackRoot to an invalid path during the restore, which would forcibly download the required app host.

Is this a workaround that can be utilized, or is there a better way to do our dependency management as a whole?

Author:	winterqt
Assignees:	-
Labels:	area-Infrastructure-libraries, untriaged
Milestone:	-

Tagging subscribers to this area: @dotnet/area-meta
See info in area-owners.md if you want to be subscribed.

Issue Details

---

I'm a maintainer of Nixpkgs, the package repository for the Nix package manager. One of our explicit requirements is complete reproducibility, so we employ sandboxes and other restrictions to build packages. Our .NET packages currently do three things to solve the problem of remote dependencies:

1. Create a list of packages needed, using dotnet restore and a script to pull metadata. This results in a file that looks like this
2. Build a local source from those packages
3. Use it when running dotnet restore (in an airgapped sandbox)

This has, for the most part, worked great. However, there's an issue that I discovered that makes what we currently do pretty fragile.

(I should note that if you look at our current dotnet restore invocations, we don't explicitly specify a RID to build for, which will clearly cause issues. I'm working to fix this, and everything that I've described below is in the context of explicitly specifying one.)

This root cause is how we use dotnet restore to get the list of packages, and how this interacts with bundled app hosts. For example, if I run a restore for linux-arm64 on linux-arm64, it produces a packages directory that does not include Microsoft.NETCore.App.Host.linux-arm64. Therefore, if the package list is built on a linux-arm64 machine, and then that list is used to try to compile a linux-arm64 build from a non-linux-arm64 system, it will fail. If the list is built on another system, this issue does not occur, but this is obviously not ideal.

A workaround suggested to me was to set NetCoreTargetingPackRoot to an invalid path during the restore, which would forcibly download the required app host.

Is this a workaround that can be utilized, or is there a better way to do our dependency management as a whole?

Author:	winterqt
Assignees:	-
Labels:	area-Meta, untriaged
Milestone:	-

[agocke]

I should note that if you look at our current dotnet restore invocations, we don't explicitly specify a RID to build for, which will clearly cause issues. I'm working to fix this, and everything that I've described below is in the context of explicitly specifying one.)

Yeah, I'm not surprised this is running into some issues. The core piece here is that "restore" is a dependent target that runs with different options, depending on what you pass. In this case, running publish or build with a RID will pass different options, which results in different arguments to restore.

At the moment, we don't really have any guidance on restore, aside from the statement that you'll need to run restore with the same options that you use to build.

Note: a lot of this is part of the SDK, not really the runtime

[ericstj]

Agree with @agocke. Your questions here are around the implicit package references added by the SDK. These are added to give users a better default experience for the system they're running on (applications get an apphost that's specific to their build machine so they don't need to use dotnet to run the app). If you don't want that you can turn it off and avoid getting a copy of the AppHost. Or you could specify the apphost RID to get a consistent one regardless of the build machine.

[winterqt]

If you don't want that you can turn it off and avoid getting a copy of the AppHost.

@ericstj We did end up fixing this, but I'm curious for future reference/if anyone ever runs into this issue in the future: how would you do this?

[ericstj]

I was referring to https://learn.microsoft.com/en-us/dotnet/core/project-sdk/msbuild-props#useapphost I believe setting this to false will prevent the SDK from dowloading the AppHost packages (and also prevent your app from including the apphost entrypoint). Here's the relevant part of the SDK targets:

sdk/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets

Lines 135 to 193 in 0f87434

	<PropertyGroup Condition="'$(AppHostRuntimeIdentifier)' == '' And
	('$(UseAppHost)' == 'true' Or '$(EnableComHosting)' == 'true' Or '$(UseIJWHost)' == 'true')">
	<AppHostRuntimeIdentifier>$(RuntimeIdentifier)</AppHostRuntimeIdentifier>
	<AppHostRuntimeIdentifier Condition="'$(AppHostRuntimeIdentifier)' == ''">$(DefaultAppHostRuntimeIdentifier)</AppHostRuntimeIdentifier>
	</PropertyGroup>
	<ResolveAppHosts TargetFrameworkIdentifier="$(TargetFrameworkIdentifier)"
	TargetFrameworkVersion="$(_TargetFrameworkVersionWithoutV)"
	TargetingPackRoot="$(NetCoreTargetingPackRoot)"
	AppHostRuntimeIdentifier="$(AppHostRuntimeIdentifier)"
	OtherRuntimeIdentifiers="$(RuntimeIdentifiers)"
	RuntimeFrameworkVersion="$(RuntimeFrameworkVersion)"
	PackAsToolShimRuntimeIdentifiers="@(_PackAsToolShimRuntimeIdentifiers)"
	DotNetAppHostExecutableNameWithoutExtension="$(_DotNetAppHostExecutableNameWithoutExtension)"
	DotNetSingleFileHostExecutableNameWithoutExtension="$(_DotNetSingleFileHostExecutableNameWithoutExtension)"
	DotNetComHostLibraryNameWithoutExtension="$(_DotNetComHostLibraryNameWithoutExtension)"
	DotNetIjwHostLibraryNameWithoutExtension="$(_DotNetIjwHostLibraryNameWithoutExtension)"
	RuntimeGraphPath="$(BundledRuntimeIdentifierGraphFile)"
	KnownAppHostPacks="@(KnownAppHostPack)"
	NuGetRestoreSupported="$(_NuGetRestoreSupported)"
	EnableAppHostPackDownload="$(EnableAppHostPackDownload)"
	NetCoreTargetingPackRoot="$(NetCoreTargetingPackRoot)">
	<Output TaskParameter="PackagesToDownload" ItemName="_PackageToDownload" />
	<Output TaskParameter="AppHost" ItemName="AppHostPack" />
	<Output TaskParameter="SingleFileHost" ItemName="SingleFileHostPack" />
	<Output TaskParameter="ComHost" ItemName="ComHostPack" />
	<Output TaskParameter="IjwHost" ItemName="IjwHostPack" />
	<Output TaskParameter="PackAsToolShimAppHostPacks" ItemName="PackAsToolShimAppHostPack" />
	</ResolveAppHosts>
	<PropertyGroup Condition="'$(UsePackageDownload)' == ''">
	<UsePackageDownload Condition="'$(MSBuildRuntimeType)' == 'Core'">true</UsePackageDownload>
	<UsePackageDownload Condition="'$(PackageDownloadSupported)' == 'true'">true</UsePackageDownload>
	<UsePackageDownload Condition="'$(UsePackageDownload)' == ''">false</UsePackageDownload>
	</PropertyGroup>
	<ItemGroup Condition="'$(UsePackageDownload)' == 'true'">
	<PackageDownload Include="@(_PackageToDownload)">
	<Version>[%(_PackageToDownload.Version)]</Version>
	</PackageDownload>
	</ItemGroup>
	<ItemGroup Condition="'$(UsePackageDownload)' != 'true'">
	<PackageReference Include="@(_PackageToDownload)"
	IsImplicitlyDefined="true"
	PrivateAssets="all"
	ExcludeAssets="all" />
	</ItemGroup>
	<!-- Add implicit package references that don't already exist in PackageReference. -->
	<ItemGroup>
	<_ImplicitPackageReference Remove="@(PackageReference)" />
	<PackageReference Include="@(_ImplicitPackageReference)"
	IsImplicitlyDefined="true"
	PrivateAssets="all" />
	</ItemGroup>
	</Target>

Alternatively you could multi-target your project to all the runtimes that you might want to build for to collect all those hosts, or set a single value for AppHostRuntimeIdentifier rather than getting the default which, as you notice, changes based on where the app is built.