Source-build: Support the Microsoft.AspNetCore.App shared runtime in source-build

[natemcmaster]

The Microsoft.AspNetCore.App shared runtime (first-released in 2.1) and many of dependencies are not currently supported in source-build. To enable source-build on this shared runtime, we expect the following changes will need to be addressed:

• Update most build tools and infrastructure used by aspnetcore to support building offline. This infrastructure code mostly lives in two places. Both will require significant refactoring.
  
  
  
  • https://github.com/aspnet/BuildTools
  
  
  • https://github.com/aspnet/Universe
  
  
• Add source build support to Microsoft.AspNetCore.App dependencies (if they have not already been added)
  
  
  
  • Newtonsoft.Json 11 - https://github.com/JamesNK/Newtonsoft.Json
  
  
  • Microsoft.IdentityModel.* and System.IdentityModel.* binaries - https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet ( see https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/issues/925)
  
  
  • Remotion.Linq - https://github.com/re-motion/Relinq
  
  
  • System.Interactive.Async - https://github.com/Reactive-Extensions/Rx.NET
  
  
  • Microsoft.CodeAnalysis.CSharp.Workspaces.dll - (required for Razor) (see also https://github.com/dotnet/roslyn/issues/26299)
  
  
  • Microsoft.Extensions.DependencyModel.dll - (required for MVC)
  
  
  • A few other binaries from dotnet/corefx that are not in Microsoft.NETCore.App
    
    
    
    
    
    • sni.dll (Windows only)
    
    
    
    • System.Composition.AttributedModel.dll
    
    
    
    • System.Composition.Convention.dll
    
    
    
    • System.Composition.Hosting.dll
    
    
    
    • System.Composition.Runtime.dll
    
    
    
    • System.Composition.TypedParts.dll
    
    
    
    • System.Data.SqlClient.dll
    
    
    
    • System.IO.Pipelines.dll
    
    
    
    • System.Net.Http.Formatting.dll
    
    
    
    • System.Net.WebSockets.WebSocketProtocol.dll
    
    
    
    • System.Runtime.CompilerServices.Unsafe.dll
    
    
    
    • System.Security.Cryptography.Pkcs.dll
    
    
    
    • System.Security.Cryptography.Xml.dll
    
    
    
    • System.Security.Permissions.dll
    
    
    
    • System.Text.Encoding.CodePages.dll
    
    
    
    • System.Text.Encodings.Web.dll
    
    
    
    • System.Threading.Channels.dll
    
    
    
  
  

[tmds]

@natemcmaster I'm wondering about something.
Suppose a user references 'Microsoft.AspNetCore.App' version '2.1.0' in his csproj file.
And at some point security release '2.1.1' is made.

With the Microsoft binaries, the fixed 'Microsoft.AspNetCore.App' is deployed to the production server. This means all production apps use the patched version, even when they are targeting an older version ('2.1.0' in this case). Is that correct?

For source-build binaries, the plan for 2.1 is to fetch this package from nuget.org and are deployed with the application. So to get the new bits, the user will need to re-build his application. afaik nuget doesn't understand this is a patch release, so it is also the user's responsibility to manually update the version number in the csproj file. Is that correct? If the user would have specified 2.1.* as a version dependency, would that be an appropriate way to always use the latest patch version?

CC @omajid

[natemcmaster]

With the Microsoft binaries, the fixed 'Microsoft.AspNetCore.App' is deployed to the production server. This means all production apps use the patched version, even when they are targeting an older version ('2.1.0' in this case). Is that correct?

Yes. Microsoft.AspNetCore.App is a shared framework. Like Microsoft.NETCore.App, the patch rollforward policy applies. Users do not need to re-build the framework-dependent deployments to get this security update.

For self-contained deployments, Microsoft.AspNetCore.App and Microsoft.NETCore.App are in the same boat: users need to re-build and redeploy for security patches. This means updating the NuGet package references for both of these packages to 2.1.*. There is a proposal to fix this in the SDK in the future. See https://github.com/dotnet/designs/pull/36

[tmds]

@natemcmaster I noticed rc1 templates no longer have a version for the Microsoft.AspNetCore.App package:

<PackageReference Include="Microsoft.AspNetCore.App" />

I guess the Microsoft.NET.Sdk.Web sdk fills in what it knows to be the latest version? So that will also work on source-build? And it means that source-build users won't have to manually patch their csproj files (i.e. building with a more recent sdk is enough)?

[natemcmaster]

Correct, users should not need to patch their .csproj file. Our intention here is to follow the same behavior of the implicit reference to Microsoft.NETCore.App. The web sdk will pick the version as follows

• SelfContained == false -> reference version is '2.1.0'. This version is a minimum shared runtime version, so we won't update this. The host policy will auto rollforward to newer 2.1.x patches when they are installed.
• SelfContained == true -> reference the latest 2.1.x version. cref https://github.com/dotnet/designs/pull/36

See https://github.com/aspnet/websdk/blob/0e78949b6c03efc8c257643e4913f4a22e52b653/src/Web/Microsoft.NET.Sdk.Web.Targets/Sdk.DefaultItems.targets#L14-L33 for more details.

[tmds]

SelfContained == false -> reference version is '2.1.0'. This version is a minimum shared runtime version, so we won't update this. The host policy will auto rollforward to newer 2.1.x patches when they are installed.

If this doesn't get updated, doesn't that mean source-build will continue to get the 2.1.0 from nuget.org even when patches are available?

[natemcmaster]

Yes, and this is true for Microsoft.NETCore.App as well. See https://github.com/dotnet/sdk/blob/a8cf9e78eeb14852a7bf97b344731d9734b5d877/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.DefaultItems.targets#L63-L138

[tmds]

For Microsoft.NETCore.App that's fine, for not self-contained, it runs on what the system has. For source-build there is no system Microsoft.AspNetCore.App, so it will always select the 2.1.0 from nuget.org.
Perhaps it makes sense in the case where you are overriding MicrosoftNETPlatformLibrary for source-build, to also set TargetLatestAspNetCoreRuntimePatch to true?

[natemcmaster]

We can’t set TargetLatestAspNetCoreRuntimePatch in the same place as MicrosoftNETPlatformLibrary, since TargetLatestAspNetCoreRuntimePatch defines which version of the package is pulled in, and MicrosoftNETPlatformLibrary is set from inside the package.

[tmds]

We can probably set TargetLatestAspNetCoreRuntimePatch in the sdk based on similar conditions that end-up setting MicrosoftNETPlatformLibrary?

That will only fix the issue when the user is always using the latest sdk. If the sdk is fixed in global.json for compat reasons, he is still using a possibly out-dated version of ASP.NET Core.

[tmds]

That will only fix the issue when the user is always using the latest sdk. If the sdk is fixed in global.json for compat reasons, he is still using a possibly out-dated version of ASP.NET Core.

I was wondering how https://github.com/dotnet/designs/pull/36 might solve this, but it is suffering from the same problem:

As proposed, the .NET Core SDK targets will have a hard-coded list of the latest patches for each minor .NET Core release. This couples SDK releases with runtime patches and means we would have to release an updated SDK each time there was a new runtime patch if we want self-contained apps to roll forward to it-- and that developers would need to install the new SDK in order to roll forward to the latest patch.

[natemcmaster]

FYI - we are planning on addressing this in 3.0.

[JunTaoLuo]

@crummel I suppose we can close this now that https://github.com/dotnet/source-build/pull/1144 is in?

[natemcmaster]

Nice work!