CoreRT feed and version update

[adamsitnik]

@AndreyAkinshin CoreRT has moved from https://github.com/dotnet/corert/ to https://github.com/dotnet/runtimelab/tree/feature/NativeAOT and we need to update the default compiler version and nuget feed address to avoid issue like #1605

Fixes #1605

/cc @MichalStrehovsky @jkotas

[MichalStrehovsky]

Thank you!

Maybe the old compiler reference could just be removed in favor of latest? The old compiler and runtime is a snapshot from somewhere halfway between .NET Core 3.0 and 5.0 anyway. The NuGet feed is going to be retired at some point.

[jkotas]

I agree with Michal. The experimental project does not have packages synchronized with .NET release. We always point everybody to latest.

[adamsitnik]

I wanted to keep the old TFMs (< net5.0) using the old compiler because I was getting an error when building a sample app that was targeting old monikers and new compiler:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFrameworks>net5.0;netcoreapp2.1</TargetFrameworks>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.DotNet.ILCompiler" Version="6.0.0-*" />
  </ItemGroup>
</Project>

dotnet publish -r win-x64 -c Release -f netcoreapp2.1

PS C:\Projects\repro\HelloWorld> dotnet publish -r win-x64 -c Release -f netcoreapp2.1
Microsoft (R) Build Engine version 16.9.0-preview-20561-01+56ab63409 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
  Restored C:\Projects\repro\HelloWorld\HelloWorld.csproj (in 993 ms).
  You are using a preview version of .NET. See: https://aka.ms/dotnet-core-preview
  HelloWorld -> C:\Projects\repro\HelloWorld\bin\Release\netcoreapp2.1\win-x64\HelloWorld.dll
C:\Users\adsitnik\.nuget\packages\microsoft.netcore.app\2.1.23\build\netcoreapp2.1\Microsoft.NETCore.App.targets(19,5): error : Project is targeting runtime 'win-x64' but did not resolve any runtime-specific packages for the 'Microsoft.NETCore.App' package.  This runtime may not be supported by .NET Core. [C:\Projects\repro\HelloWorld\HelloWorld.csproj]

But it turns out that it's just a warning and the .exe is produced anyway. So I am going to ignore the warning and use new compiler everywhere.

[adamsitnik]

Update: the .exe is produced, but not in /native subfolder and it's a managed .NET Core .exe, not CoreRT. I'll dig into that later

[AndreyAkinshin]

LGTM

[adamsitnik]

@MichalStrehovsky we have updated our CI to use .NET 5 SDK (previously we have been using 2.1) and with the latest CoreRT packages (from the new feed) our AzureDevops Ubuntu 16.04 CI leg fails with the following error:

2021-01-21T14:14:33.3304860Z  clang : error : linker command failed with exit code 1 (use -v to see invocation) [/home/vsts/work/1/s/tests/BenchmarkDotNet.IntegrationTests/bin/Release/net5.0/8c235400-73dd-4e49-8a8e-12d2337082d6/BenchmarkDotNet.Autogenerated.csproj]
2021-01-21T14:14:33.3305692Z    /__w/1/s/src/libraries/Native/Unix/System.Native/pal_networking.c:527: undefined reference to `gai_error'
2021-01-21T14:14:33.3306705Z    /home/vsts/.nuget/packages/runtime.linux-x64.microsoft.dotnet.ilcompiler/6.0.0-alpha.1.21070.1/framework/libSystem.Native.a(pal_networking.c.o): In function `GetHostEntryForNameAsyncComplete':
2021-01-21T14:14:33.3307908Z    /__w/1/s/src/libraries/Native/Unix/System.Native/pal_networking.c:646: undefined reference to `getaddrinfo_a'
2021-01-21T14:14:33.3308861Z    /home/vsts/.nuget/packages/runtime.linux-x64.microsoft.dotnet.ilcompiler/6.0.0-alpha.1.21070.1/framework/libSystem.Native.a(pal_networking.c.o): In function `SystemNative_GetHostEntryForNameAsync':
2021-01-21T14:14:33.3310091Z  EXEC : warning : RD.XML processing will change before release (https://github.com/dotnet/corert/issues/5001) [/home/vsts/work/1/s/tests/BenchmarkDotNet.IntegrationTests/bin/Release/net5.0/8c235400-73dd-4e49-8a8e-12d2337082d6/BenchmarkDotNet.Autogenerated.csproj]
2021-01-21T14:14:33.3310717Z    Generating native code
2021-01-21T14:14:33.3311275Z    /usr/bin/clang

Is it a known problem? How can I solve it?

[MichalStrehovsky]

Sigh. Not known. Apparently dotnet/runtime#34633 introduced new dependencies that we need to compensate for.

Could you please try if dropping

    <ItemGroup>
      <LinkerArg Include="-lanl" />
    </ItemGroup>

into the project file that is invoking the compiler fixes it? We'll need to put that into the targets that the compiler carries with it.

Apparently we don't test anything that uses networking in the CI.

[MichalStrehovsky]

Cool, I'll make a pull request to fix this in the package. Thank you for testing the fix!

[adamsitnik]

@MichalStrehovsky thanks a lot!