Use in-tree ilasm to run test suite natively on s390x

[uweigand]

• There are no linux-s390x packages on nuget.org, so use in-tree
  built ilasm when running the test suite natively on s390x

In #58952, @akoeplinger introduced code to allow building the test suite targeting linux-s390x, even through there are no linux-s390x packages currently available on nuget.org, by using the in-tree live-built versions of the host packages instead.

However, there is still one remaining obstacle to actually running the test suite natively on linux-s390x, and that is the availability of the ilasm package. This PR sets the ILAsmToolPath property to use the in-tree live-built ilasm binary instead.

With this PR applied, I'm able to successfully build and run the runtime libs.tests test suite natively on linux-s390x without any changes applied to the upstream repository.

[ghost]

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

Issue Details

---

• There are no linux-s390x packages on nuget.org, so use in-tree
  built ilasm when running the test suite natively on s390x

In #58952, @akoeplinger introduced code to allow building the test suite targeting linux-s390x, even through there are no linux-s390x packages currently available on nuget.org, by using the in-tree live-built versions of the host packages instead.

However, there is still one remaining obstacle to actually running the test suite natively on linux-s390x, and that is the availability of the ilasm package. This PR sets the ILAsmToolPath property to use the in-tree live-built ilasm binary instead.

With this PR applied, I'm able to successfully build and run the runtime libs.tests test suite natively on linux-s390x without any changes applied to the upstream repository.

Author:	uweigand
Assignees:	-
Labels:	area-Infrastructure-libraries
Milestone:	-

[ViktorHofer]

Looks good. Thank you.

[uweigand]

Can this be merged now or is there anything else I should be doing? Thanks!

[akoeplinger]

We probably need the same change for ppc64le, /cc @Sapana-Khemkar

[Sapana-Khemkar]

@akoeplinger Thanks for highlighting. Yes we will take this for ppc64le.

[ViktorHofer]

Ideally we would just always use the live built version. We don't use ILAsm/ILDasm anymore in the product build as we removed CompilerServices.Unsafe.ilproj. The projects (I think only test projects) in the repo that continue to use the .ilproj extension could just import the props and targets file automatically instead of being an reference. The targets file could make sure that the toolchain is (incrementally) built. The package would continue to be available for consumers outside the repo, like roslyn.

That would remove the existing self dependencies for the Microsoft.NET.Sdk.IL and we could eventually remove the self referencing node in the build graph: runtime -> runtime.

from https://github.com//pull/72371

EDIT: As pointed out in #58109 (comment), a good first step to approach this might be removing the prebuilts of ILAsm and ILDasm by setting the ILAsmToolPath property unconditionally. That would always use the live built version of the tools themselves and with some more work I'm sure we will also be able to avoid the IL.SDK package prebuilt.