Fix installer build on Alpine

[am11]

When building for linux-musl on Alpine Linux host, the current approach is to pass /p:OutputRid=linux-musl-{arch} argument to ./build.sh command for sfxprojs in installer, which use Microsoft.DotNet.SharedFramework.Sdk and resolve RuntimeIdentifer as linux-x64, rather than linux-musl-x64.

PR fixes it by deleting the third OS list (_outputRID). Few issues highlighted after this simplification are also fixed; missing /p:CrossBuild in src/tests restore projects.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

[am11]

cc @ViktorHofer, now we have two OS lists instead of three.. it is gradually getting improved. 🙂

[am11]

This was a 4 years old typo, which seems to be working by accident.

[ViktorHofer]

cc @ViktorHofer, now we have two OS lists instead of three.. it is gradually getting improved. 🙂

Great to see, thanks so much. What's the remaining OS duplication?

[ViktorHofer]

Could you please verify that with this change VS still builds as expected? Just to double that check that we don't regress.

[am11]

What's the remaining OS duplication?

Currently the matrix has the following concepts (I might have missed something):

OSes:

1. _hostOS: local property for host OS
2. TargetOS: public property for TargetOS, it defaults to _hostOS
3. _portableOS: local property that mainly varies for portable, non-portable builds
4. RuntimeOS: public property for computing runtime assets' path

RIDs:

1. __DistroRID: this is computed by shell script (eng/native/init-distro-rid) and used to parse out the default value of RuntimeOS
2. PackageRID: public property to restore packages. It defaults to {_hostOS}-{_hostArch} when building for host and {_portableOS}-{TargetArchtecture} or {RuntimeOS}-{TargetArchitecture}.
3. OutputRid: public property for build packages, it defaults to PackageRID
4. MicrosoftNetCoreIlasmPackageRuntimeId: public property that is computed based on several conditions; mainly rely on the logic of 'closest package we can use on host to build runtime tools for the given target'.

If we could reduce the number of properties, in the spirit of avoiding multiple ways of doing the same thing, it would make it make it more scalable and easier to comprehend. In particular, RuntimeOS, __DistroRID and __portableOS can be simplified/refactored, if we hash out the details of what precisely we are supporting and define a strong contract for each of the following use-case:

• Portable build: ./build.sh - applies to platform with the concept of distros, host and target are same, produced packages have platform name (e.g. linux-arm64 or illumos-x64).
• Portable cross build: ./build.sh -cross -os SomeUnix or ./build.sh -arch <something different than host>- host and target are different, so tooling will cross compile
• Non-portable build: ./build.sh --portablebuild false - produced packages have distro name (e.g. ubuntu-arm64 or openindiana-x64). This is currently used by dotnet/source-build and Tizen folks
• Non-portable cross build: ./build.sh -cross -os SomeDistro --portable false - this is currently not used by anyone (I think), but we have support for it.

TL;DR, ideally we just want to know two simple things: host and target .. but that is most likely an oversimplification.. 🤣

One issue is the lack of Tizen and non-portable / source-build CI legs, which results in a lots of 'what if someone is using it' kind of cautions and hence the tech debt.

[am11]

Could you please verify that with this change VS still builds as expected? Just to double that check that we don't regress.

I followed these steps https:/dotnet/runtime/blob/d4d50db6768f729857b27ced3b68067bf30d18de/docs/workflow/building/libraries/README.md#quick-start and built System.Text.RegularExpressions and System.Globalization solutions inside Visual Studio, all projects succeeded.

[ViktorHofer]

Maybe we should move that discussion into a separate issues and loop more folks in?

[ViktorHofer]

Based on the recent infra changes let's retrigger a build and then merge :)

[ViktorHofer]

/azp run runtime

[ViktorHofer]

/azp run runtime-dev-innerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).