Support for installing .NET Core shared frameworks

[natemcmaster]

ASP.NET Core regularly needs to build against a shared framework which is not bundled by the .NET Core SDK downloads.

The way we did this in KoreBuild was to allow for an item group to define the additional shared frameworks required.

<!-- Installs Microsoft.NETCore.App -->
<DotNetCoreRuntime Include="1.0.5" />
<DotNetCoreRuntime Include="1.0.5" Feed="https://mydotnetclifeed/assets" FeedCredential="$(MySuperSecretToken)" />
<DotNetCoreRuntime Include="latest" Channel="1.0" />
<DotNetCoreRuntime Include="2.0.0" Arch="x64" InstallDir="C:\custom\" />

<!-- Installs the AspNetCore shared framework -->
<AspNetCoreRuntime Include="2.1.0-preview1-1234" Arch="arm64" />

During /t:Restore we ran a target which invoked dotnet-install.sh/ps1 to install the additional shared frameworks into DOTNET_ROOT.

We need this to convert from KoreBuild to Arcade. In the meantime, we've worked around this like this: https://github.com/aspnet/AspNetCore-Tooling/blob/03a21837eec155a2f810ee8e9645e984417439bd/eng/Tools.props#L3-L33

cc @rynowak @ryanbrandenburg @bricelam

[tmat]

You can install additional shared frameworks by adding restore-toolset.ps1 and calling InstallDotNetSharedFramework function like so: https://github.com/dotnet/sdk/blob/master/eng/restore-toolset.ps1#L20-L22

[tmat]

It'd be probably useful to move the function to tools.ps1 and tools.sh, since multiple repos need this.

[natemcmaster]

Does darc update support updating .ps1 files? The version of .NET Core shared frameworks we use rapidly changes and needs to align with the package versions we restore. If possible, I'd love to keep this as MSBuild variables.

[jcagme]

Yes. We update all the files in eng/common regardless of the extension

[natemcmaster]

...but the file @tmat proposed using isn't in eng/common/.

[natemcmaster]

@tmat - is there a bash equivalent?

[tmat]

If possible, I'd love to keep this as MSBuild variables.

They are not MSBuild variables since they are used from PowerShell. The restore script is run before MSBuild is available. If this is an issue, we can think about adding these to global.json in the tools section.

Yes, there is bash equivalent.
https://github.com/dotnet/sdk/blob/master/eng/restore-toolset.sh

[tmat]

It would imo make sense for these to be in global.json, since the version of dotnet is also there. Something like:

{
  "tools": {
    "dotnet": "2.1.400-preview-009088",
    "dotnet-shared-fx": [ "1.0.5", "2.1.0" ]
  },
}

[natemcmaster]

They are not MSBuild variables since they are used from PowerShell.

Yes, I'm aware of the difference. What I meant was that we currently have MSBuild variables which represent the shared framework versions we use. e.g. https://github.com/aspnet/AspNetCore/blob/e310ccac7b30e901f657f81c86c4048fecfedf7b/build/dependencies.props#L6

  <PropertyGroup>
    <MicrosoftNETCoreAppPackageVersion>3.0.0-preview-27122-01</MicrosoftNETCoreAppPackageVersion>
  </PropertyGroup>

In Korebuild, this can be used to drive dotnet-install.ps1 and also to set variables for NuGet restore.

https://github.com/aspnet/AspNetCore/blob/e310ccac7b30e901f657f81c86c4048fecfedf7b/build/runtimes.props#L3-L23
https://github.com/aspnet/AspNetCore/blob/e310ccac7b30e901f657f81c86c4048fecfedf7b/Directory.Build.targets#L51

My concern was that having the variable hard-coded in PowerShell and msbuild means one more thing which can break if update automation doesn't run correctly.

So, is there a way to make this work? Is darc update capable of updating versions in a .json, .ps1, and/or .sh file?

[tmat]

I'll think about it. For now your workaround seems ok.

[markwilkie]

cc/ @rynowak

[rynowak]

We need multiple runtimes in aspnet/AspNetCore-Tooling because we ship functionality in the SDK. We need to be able to test that we can build applications that target our previously-shipped frameworks.

[jcagme]

Where did this land?

[tmat]

It has not. Haven't had time.

[tmat]

I mean the workaround works, but would be nice to get first class support at some point.