Move all MSBuild logic from Microsoft.AspNetCore.App (the package) into an MSBuild SDK

[natemcmaster]

Problem

Follow-up to #3608. In 2.1 and 2.2, there are some MSBuild targets and tooling bundled in the NuGet packages pulled in by Microsoft.AspNetCore.App. As a part of making Microsoft.AspNetCore.App a shared framework in 2.1, we failed to realize that this would impact MSBuild targets and related tooling. The design of shared frameworks calls for the package version of Microsoft.AspNetCore.App to be pinned and not to update in packages. This makes it difficult to service the MSBuild targets and tooling without also impacting compilation references and runtime versions.

In 3.0, this will impacts the following

• Microsoft.AspNetCore.App
• Microsoft.AspNetCore.Razor.Design
• Microsoft.AspNetCore.Mvc.Razor.Extensions
• Microsoft.Extensions.Configuration.UserSecrets
• Microsoft.Extensions.FileProviders.Embedded

Proposed solution

All packages that are part of Microsoft.AspNetCore.App should move MSBuild targets and tasks out of the package and into an MSBuild SDK.

• Targets and tools for Razor compilation move into Microsoft.NET.Sdk.Razor.
• Targets for Microsoft.AspNetCore.App move into Microsoft.NET.Sdk (the <FrameworkReference> feature)
• Targets and tasks for Microsoft.Extensions.FileProviders.Embedded move into either:
  • An in-box SDK like Microsoft.NET.Sdk
  • A separate package named something like Microsoft.Extensions.FileProviders.Embedded.Sdk which provides build-time only assets
• Targets for Microsoft.Extensions.Configuration.UserSecrets move into Microsoft.NET.Sdk

[poke]

So in order to use Razor features, projects will have to set their SDK to Microsoft.NET.Sdk.Razor? How will that impact projects that would want to use a different SDK? I expect Microsoft.NET.Sdk.Web to extend the Razor SDK? But what happens when there are multiple disjunctive SDKs involved in the future?

[natemcmaster]

Users shouldn’t need to change the SDK used in projects. Microsoft.NET.Sdk.Razor already exists in the 2.1 tooling, but it’s not typically referenced in project file.

[poke]

Okay, so it is possible for a project to reference multiple SDKs. Alright, nevermind my comment then :)

[rynowak]

So in order to use Razor features, projects will have to set their SDK to Microsoft.NET.Sdk.Razor?

Yeah this is already the case 😆 - historically Razor only worked in web applications. We added class library support in 2.1 but it's always required Razor SDK.

[dsplaisted]

Just to be clear, you don't (and won't) need to explicitly use the Razor SDK if your project uses Microsoft.NET.Sdk.Web.

[muratg]

Moving out since preview2 is done. @natemcmaster I assume this is still required?

[natemcmaster]

The work is blocked, pending a design from the SDK team on how targeting packs should specify package conflict resolution metadata.

[natemcmaster]

This work was completed in 3.0 preview 4.

• Conflict resolution data is shipped in targeting packs as .txt files which the SDK supports
• Mvc and Razor targets and tasks ship in the Web SDK.
• User secrets support was added to Microsoft.NET.Sdk
• Those who want to use the embedded file provider can opt-in to the manifest generation by adding a PackageReference to Microsoft.Extensions.FileProviders.Embedded. Until there is sufficient demand, there are no plans to move the manifest generation targets into the SDK itself.