Uh oh!
There was an error while loading. Please reload this page.
Explicitly omit RID from crossgen2 binary path - #78733
Conversation
jkotas
commented
Nov 22, 2022
/backport to release/7.0 |
Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/3527574284 |
nagilson
left a comment
There was a problem hiding this comment.
LGTM, but be aware that this is still a changed behavior. RuntimeIdentifier will be set where it didn't used to be set before, even if it's not in the path. And I don't know if that has implications with how crossgen uses RuntimeIdentifiers. SelfContained and friends shouldn't allow you to build/publish if you don't have a RuntimeIdentifier unless there is some spicy customization going on here. If there's logic somewhere to allow that, it's unnecessary if the SDK infers a RuntimeIdentifier for you now, so it could be removed.
Also, FYI failure in musl arm64 appears unrelated:
System.Net.Http.Tests.ContentDispositionHeaderValueTest.FileNameStar_NeedsEncoding_EncodedAndDecodedCorrectly [FAIL]
Assert.Equal() Failure
↓ (pos4)
Expected: FileÃName.bat
Actual: File?�Name.bat
↑ (pos4)jkotas
commented
Nov 23, 2022
@nagilson Thank you!
There is a lot of customization in dotnet/runtime build. My reason for fixing the issue using
I do not think that the SDK can infer RuntimeIdentifier for us. dotnet/runtime supports number of cross-building scenarios (e.g. running on linux-x64 and building for linux-arm64). The RID has to be explicitly specified for these cases.
Yes, it is unrelated (build-analysis has a link to the tracking issue). |
While the SDK might not be able to cleverly in this case, the breaking change is that it will try to use the machine RID if you have a property like SelfContained or PublishSingleFile, as normally these properties will fail your build if |
Fixesdotnet/sdk#29177