-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use SDK-selected runtime in IL SDK #60400
Conversation
Tagging subscribers to this area: @Anipik, @safern, @ViktorHofer Issue DetailsWhen IL SDK is publicly consumed, it is less usable on variety of platforms than the .NET SDK. The reason is a hardcoded list of runtimes identifiers. Repro: # on alpine-x64
$ mkdir testilsdk
$ cd testilsdk
$ cat > testilsdk.ilproj <<EOF
<Project Sdk="Microsoft.NET.Sdk.IL">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net5.0</TargetFramework>
</PropertyGroup>
</Project>
EOF
$ cat > global.json <<EOF
{
"msbuild-sdks": {
"Microsoft.NET.Sdk.IL": "5.0.0"
}
}
EOF
$ cat > Program.il <<EOF
.assembly extern System.Private.CoreLib { }
.assembly extern System.Console { }
.assembly ConsoleApp { }
.class public auto ansi abstract sealed beforefieldinit Program extends System.Object
{
.method public hidebysig static void Main () cil managed
{
.entrypoint
.maxstack 8
ldstr "Hello World! 👋"
call void [System.Console]System.Console::WriteLine(string)
ret
}
}
EOF
$ dotnet build which throws the following error:
It is trying to access linux-x64, rather than linux-musl-x64. Workaround: It requires us leaking the internal usage details to public and we need to explicitly pass (a very weird looking long property with) the desired runtime: $ dotnet build -p:MicrosoftNetCoreIlasmPackageRuntimeId=linux-musl-x64
# while for the rest of the ecosystem
# --runtime <VAL>
# or
# --use-curren-runtime
# suffice
|
cc @ViktorHofer, @hoyosjs, one less hardcoded list (hopefully) 😁 |
This path isn't exercised by CI at the moment, as we don't use a live build of the IL SDK and because we pass in the desired RID. Approving assuming that you tested the changes locally and that the SDK property is always set (?). Presumably this will only work when the package is used in a Microsoft.NET.Sdk project that defines that property - I'm ok with that. |
@ViktorHofer, I applied this change locally (after analyzing logs produced by After that there was another error: /home/am11/.dotnet5/sdk/5.0.402/Microsoft.Common.CurrentVersion.targets(4521,5): error : Expected file "obj/Debug/net5.0/ref/testilsdk.dll" does not exist. [/home/am11/projects/testilsdk/testilsdk.ilproj]
The build failed. Fix the build errors and run again. for some reason, it is looking for the compiled dll under # 1. apply this PR patch
# 2. dotnet build <-- this will fail, but it's a prerequisite to the following workaround
# 3. cp obj/Debug/net5.0/testilsdk.dll obj/Debug/net5.0/ref/ <-- the workaround
# 4. dotnet run
Hello World! 👋 I will keep troubleshooting what is requiring |
@am11 try setting |
Agree with @jkoritzinsky, great observation. It's likely this code path that is triggered which shouldn't run when using the IL.SDK as roslyn isn't used: https://github.com/dotnet/msbuild/blob/35c6ef021eb745623b123307c2ebb55bf6564ef9/src/Tasks/Microsoft.Common.CurrentVersion.targets#L4647-L4657. If that worked, feel free to add that change to the IL.SDK props/targets file :) |
Wow, that fixed it, thank you! I have set it in the Sdk.props (tested it locally by setting in |
Thanks a lot 👍 |
@ViktorHofer, any chance this change be backported to 6.0? |
Unfortunately it's too late for 6.0.0 but it's a good candidate for the first servicing release 6.0.1. Might make sense to prep a PR against release/6.0 with the servicing template. cc @danmoseley |
When IL SDK is publicly consumed, it is less usable on variety of platforms than the .NET SDK. The reason is a hardcoded list of runtime identifiers.
Repro:
which throws the following error:
It is trying to access linux-x64, rather than linux-musl-x64.
PR fixes the problem by delegating external usages default to the runtime picked by its parent; the .NET SDK.
Workaround:
It requires us leaking the internal usage details to public and we need to explicitly pass (a very weird looking long property with) the desired runtime: