You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The downstream repos have dotnet.sh script, which calls scripts in arcade to install dotnet in :(top)/.dotnet/ directory's root if it wasn't present and continues using the one that was installed. If the installed .dotnet/dotnet belonged to a different platform, it fails with (a cryptic) run-time error.
I often find myself mounting the repo directory (with local changes) in docker container to test the build against different platform e.g. docker run --rm -v(pwd):/runtime -w /runtime --platform linux/amd64 ubuntu sh -c 'eng/install-native-dependencies.sh && ./build.sh clr+libs (or using cross prereq image)
on Apple Silicon or Windows host machines. This requires deleting .dotnet/ directory each time if the repo was built on host machine first (or vice-versa). In comparison, the artifacts/ directory keeps the platform dependent bits separate in $rid/ sub-directories and we don't need to delete it when switching the executing platform.
It would make things consistent if arcade installs dotnet in $rid sub-directory as well, to avoid installing when switching between the host and the container. i.e. :(top)/.dotnet/win-arm64/dotnet.exe instead of :(top)/.dotnet/dotnet.exe to match the followed under artifacts/ directory.
Important
There is a difference between the $rid used under artifacts/ (which is always the "target RID") and proposed .dotnet/$rid (which is expected to be the "(effective) host RID"). For instance, if the host where docker is running has RID osx-arm64, the effective host in docker container where the build is running has linux-x64 cross-targeting freebsd-arm64; then the dotnet is expected to be installed in .dotnet/linux-x64.
I've run into this myself so I'd generally agree with the change, however there are probably some workflows/scripts that rely on <repo root>/.dotnet/dotnet so I'm not sure it's enough of a pain point to force this change on everyone.
We could add an env var to override the location into InitializeDotNetCli in eng/common/tools.sh (and their Windows equivalents?) as a first step.
Environment variable would essentially be a workaround and honestly it won't be much of an improvement over the current workaround: mv .dotnet .dotnet_osx-arm64 before running the container build.
If we go ahead with it, it won't be the first time we will have to update a few lines during the arcade update in downstream repos. It's relatively straightforward: .dotnet/dotnet to .dotnet/$rid/dotnet or simply to ./dotnet.sh/cmd which we can do already independent of this change.
The downstream repos have
dotnet.sh
script, which calls scripts in arcade to install dotnet in:(top)/.dotnet/
directory's root if it wasn't present and continues using the one that was installed. If the installed .dotnet/dotnet belonged to a different platform, it fails with (a cryptic) run-time error.I often find myself mounting the repo directory (with local changes) in docker container to test the build against different platform e.g.
docker run --rm -v(pwd):/runtime -w /runtime --platform linux/amd64 ubuntu sh -c 'eng/install-native-dependencies.sh && ./build.sh clr+libs
(or using cross prereq image)on Apple Silicon or Windows host machines. This requires deleting
.dotnet/
directory each time if the repo was built on host machine first (or vice-versa). In comparison, theartifacts/
directory keeps the platform dependent bits separate in$rid/
sub-directories and we don't need to delete it when switching the executing platform.It would make things consistent if arcade installs dotnet in
$rid
sub-directory as well, to avoid installing when switching between the host and the container. i.e.:(top)/.dotnet/win-arm64/dotnet.exe
instead of:(top)/.dotnet/dotnet.exe
to match the followed underartifacts/
directory.Important
There is a difference between the $rid used under artifacts/ (which is always the "target RID") and proposed .dotnet/$rid (which is expected to be the "(effective) host RID"). For instance, if the host where docker is running has RID
osx-arm64
, the effective host in docker container where the build is running haslinux-x64
cross-targetingfreebsd-arm64
; then the dotnet is expected to be installed in.dotnet/linux-x64
.cc @ViktorHofer, @jkoritzinsky, @akoeplinger
The text was updated successfully, but these errors were encountered: