.NET Core 3.0 SDK cannot build 2.1 webapp projects

[richlander]

Our initial philosophy with the .NET Core SDK was that “the latest SDK is always good enough to build your projects.” That isn’t the case for “webapp” projects.

thundera:webapp21 rich$ cat webapp.csproj 
<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>netcoreapp2.1</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.App" />
    <PackageReference Include="Microsoft.AspNetCore.Razor.Design" Version="2.1.2" PrivateAssets="All" />
  </ItemGroup>

</Project>
thundera:webapp21 rich$ dotnet --list-sdks
3.0.100-preview7-012821 [/usr/local/share/dotnet/sdk]
thundera:webapp21 rich$ 
thundera:webapp21 rich$ dotnet build
Microsoft (R) Build Engine version 16.3.0-preview-19329-01+d31fdbf01 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Restore completed in 7.51 sec for /Users/rich/webapp21/webapp.csproj.
  You are using a preview version of .NET Core. See: https://aka.ms/dotnet-core-preview
  It was not possible to find any compatible framework version
  The specified framework 'Microsoft.NETCore.App', version '2.0.7' was not found.
    - The following frameworks were found:
        3.0.0-preview7-27912-14 at [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  
  You can resolve the problem by installing the specified framework and/or SDK.
  
  The .NET Core frameworks can be found at:
    - https://aka.ms/dotnet-download
/Users/rich/.nuget/packages/microsoft.aspnetcore.razor.design/2.1.2/build/netstandard2.0/Microsoft.AspNetCore.Razor.Design.CodeGeneration.targets(69,5): error : rzc discover exited with code 150. [/Users/rich/webapp21/webapp.csproj]

Build FAILED.

/Users/rich/.nuget/packages/microsoft.aspnetcore.razor.design/2.1.2/build/netstandard2.0/Microsoft.AspNetCore.Razor.Design.CodeGeneration.targets(69,5): error : rzc discover exited with code 150. [/Users/rich/webapp21/webapp.csproj]
    0 Warning(s)
    1 Error(s)

Time Elapsed 00:00:29.26

Originally reported @ https://github.com/dotnet/cli/issues/12009

[Pilchie]

@NTaylorMullen Is the error above about not finding the framework coming from rzc? Is rzc in microsoft.aspnetcore.razor.design/2.1.2?

@livarcocc Trying to think about the right solution to this. Sounds like the options are:

1. Publish those tools self-contained in that package
   1.1 Con: Have to republish tool on security patches.
2. Make sure the 3.0 version of the package above is able to work against the 2.1 tfm.
   2.1 Con: Have to change project file to adopt new SDK.
3. Include the runtimes of any tools required for anything directly in the sdk.
   3.1 Con: SDK contains bunches of runtimes.
4. Include the tools directly in the SDK.
   4.1 Con: Works for our tools, but not 3rd parties.
5. Teach the SDK to be able to acquire the runtime required to run tools it's going to run somehow.
   5.1 Con: A bunch of new logic for the SDK
6. Other ideas?

[richlander]

Option 6 — enable roll-forward for all tools like this, and compat test them with each release (including the option to update them).

[Pilchie]

I like option 6 at first glance.

Also tagging @rynowak

[livarcocc]

Are these DotnetCliToolReference tools? If so, you could enable them to roll forward to the latest runtime. That's what we do for other tools that ship in the .NET Core SDK and are produced by ASP.NET.

For 3.1, I would strongly hope we don't go that route. That would put us back in a situation where the SDK would have to rev for any runtime changes.

We have done #4 for a bunch of things and they roll forward to the CLI's runtime.

For 5, we have had this in the backlog in general. A command line acquisition story, but that's mostly around zip/tarballs, maybe windows/osx. This would still be a problem in linux where the paradigm is that we shouldn't be doing acquisition and their own package managers there should be used there.

[richlander]

For 3.1, I would strongly hope we don't go that route. That would put us back in a situation where the SDK would have to rev for any runtime changes.

Can you elaborate? I don’t follow.

[benaadams]

Why is it trying to use 'Microsoft.NETCore.App', version '2.0.7' rather than 2.2.6?

[benaadams]

Oh, is netcoreapp2.1

[richlander]

Actually, no you are right. Why is it asking for 2.0.x at all?

[richlander]

Another way of validating this (I don’t actually have 2.x installed):

thundera:~ rich$ mkdir webapp21
thundera:~ rich$ docker run --rm -v ${PWD}/webapp21:/webapp -w /webapp mcr.microsoft.com/dotnet/core/sdk:2.1 dotnet new webapp
Getting ready...
The template "ASP.NET Core Web App" was created successfully.
This template contains technologies from parties other than Microsoft, see https://aka.ms/aspnetcore-template-3pn-210 for details.

Processing post-creation actions...
Running 'dotnet restore' on /webapp/webapp.csproj...
  Restore completed in 707.68 ms for /webapp/webapp.csproj.

Restore succeeded.

thundera:~ rich$ ls webapp21
Pages				appsettings.json
Program.cs			obj
Properties			webapp.csproj
Startup.cs			wwwroot
appsettings.Development.json
thundera:~ rich$ docker run mcr.microsoft.com/dotnet/core/sdk:3.0 dotnet --version
3.0.100-preview7-012821
thundera:~ rich$ docker run --rm -v ${PWD}/webapp21:/webapp -w /webapp mcr.microsoft.com/dotnet/core/sdk:3.0 dotnet build
Microsoft (R) Build Engine version 16.3.0-preview-19329-01+d31fdbf01 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Restore completed in 6.95 sec for /webapp/webapp.csproj.
  You are using a preview version of .NET Core. See: https://aka.ms/dotnet-core-preview
  It was not possible to find any compatible framework version
  The specified framework 'Microsoft.NETCore.App', version '2.0.7' was not found.
    - The following frameworks were found:
        3.0.0-preview7-27912-14 at [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  
  You can resolve the problem by installing the specified framework and/or SDK.
  
  The .NET Core frameworks can be found at:
    - https://aka.ms/dotnet-download
/root/.nuget/packages/microsoft.aspnetcore.razor.design/2.1.2/build/netstandard2.0/Microsoft.AspNetCore.Razor.Design.CodeGeneration.targets(69,5): error : rzc discover exited with code 150. [/webapp/webapp.csproj]

Build FAILED.

/root/.nuget/packages/microsoft.aspnetcore.razor.design/2.1.2/build/netstandard2.0/Microsoft.AspNetCore.Razor.Design.CodeGeneration.targets(69,5): error : rzc discover exited with code 150. [/webapp/webapp.csproj]
    0 Warning(s)
    1 Error(s)

Time Elapsed 00:00:29.58
thundera:~ rich$ 

[rynowak]

Option 6 — enable roll-forward for all tools like this, and compat test them with each release (including the option to update them).

I think this is the best solution.

---

The versioning/servicing for Razor in 2.1 is really problematic in general. We adopted a scheme in 2.1 where we ship the compiler and MSBuild tasks in a package. Then a decision was made to remove the explicit version number from the shared framework reference in projects and lock it to 2.1.1 forever 😭

So, this is generally the only package you reference you have from ASP.NET Core in you project file, and it's version number is significant, and it's version number has to match everywhere in your solution (MSBuild tasks).

---

We don't follow a scheme like this anymore for new release,s now the compiler and tasks ship in the SDK and we don't ship new versions of the M.A.Razor.Design package.

[richlander]

Makes sense. So, we need to get approval for taking this fix in 2.1 servicing. Will you/your team do that?

lock it to 2.1.1 forever

If that’s the case, might it make sense to update the runtime reference to be beyond 2.0.7?

[mkArtakMSFT]

@richlander we're going to think through this a bit more, as there are a set of risks associated with this. If we decide to take this - obviously Shiproom will need to approve.
If not, I'll bring this up in Tactics so everyone is aware of the state of the things.

[mkArtakMSFT]

After discussing this in more details and the risks involved in this area we've decided that we'll leave things as is for now and wait for community reaction.
//cc @Pilchie