Remove support for the implicit package version of Microsoft.AspNetCore.App

[natemcmaster]

Microsoft.AspNetCore.App, unlike normal NuGet packages, represents a shared framework. This means the package provides:

• A) The minimum expected version of of the ASP.NET Core shared runtime (found in C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App$(PackageVersion))
• B) A baseline of assemblies versions which the SDK expects to find in the shared runtime
• C) References assemblies for the compiler
• D) Implementations assemblies for self-contained deployments

There is tension between these as we want the lowest possible version of (A) to simplify deployment concerns, the highest version of (D) for security updates and patch fixes, and a version of (B) and (C) compatible with both (A) and (D).

We attempted to solve this tension in 2.1.0 by optimizing for (A) and hiding the package version from users and keeping it low, pinned to 2.1.0. That made it difficult to use packages which shared dependencies with the shared framework. In 2.1.1, we tried to fix this by easing off the restrictions and allowing package upgrades, but means users unintentionally upgrade out of the baseline (B), and end up with redundant copies of binaries in their publish output.

After lots of design discussion reviewing half a dozen alternatives, we think it will be better in the long run to back to reverse course and encourage users to use an explicit version on the PackageReference to Microsoft.AspNetCore.App, and it regularly update it to latest.

Proposed changes

• Update dotnet new templates to include the latest Microsoft.AspNetCore.App package version in the .csproj file.

• Update Microsoft.NET.Sdk.Web to warn when Microsoft.AspNetCore.App is missing a package version.

  • Text: The package reference to Microsoft.AspNetCore.App is missing the Version attribute. Defaulting to Version="2.1.1"..

• Remove "IsImplicitlyDefined" = true from Microsoft.NET.Sdk.Web. This unblocks the NuGet UI from displaying updates.
  Before:
  
  After:
  

Downsides

One of the primary reasons for making the version implicit was to simplify deployment. As history since 2.0.0 has taught us, our users that updating a PackageReference should be sufficient to use the newest version of ASP.NET Core. However, there is one more step required: users need to install a compatible shared runtime. This step is not obvious from the NuGet Package UI in VS, and error messages indicating the missing runtime are sometimes hidden (e.g. IIS Express, Test Explorer).

Proposed enhancement

[Nate: July 9]: this was not implemented, and we are not planning to implement right now.

• Update Microsoft.NET.Sdk to produce a warning when compiling for a .NET Core shared framework which is not present on the machine (cc @dsplaisted @nguerrera).
  • Text: This project is compiling for Microsoft.AspNetCore.App 2.1.3, but a compatible runtime was not found. .NET Core runtimes can be installed from https://aka.ms/dotnet-download
    

cc @DamianEdwards @davidfowl @JunTaoLuo @vijayrkn

[vijayrkn]

/cc @mlorbetske

[nguerrera]

Cc @steveharter. I'm not sure how we would implement that warning. We should tread carefully before putting host internals into build logic.

Fundamentally, I'm always wary of build trying to decide things based on the current machine. We have a long history of tooling bugs from doing just that.

But I do think there needs to be a diagnostic of some kind somewhere.

[nguerrera]

Isn't a bug that IIS express and test explorer are hiding the clear runtime message?

[natemcmaster]

@steveharter @nguerrera how much work do you think it would be to implement something like hostfxr_resolve_sdk, but instead hostfxr_resolve_shared_runtime?

Isn't a bug that IIS express and test explorer are hiding the clear runtime message?

Yes, yes it is. We should work with VSTest and IIS Express to see if we can improve this, too.

[nguerrera]

Writing the function is easy enough but there are some deployment issues. Chief among them is that we often run in 32 bit msbuild but dotnet installed is 64 bit. Sdk resolver gets around this by carrying its own hostfxr, now we'd need access to same during build. It's messy already and I don't have a great feeling about more interaction between build and hostfxr after the experience so far.

[nguerrera]

Adding @jeffschwMSFT

[natemcmaster]

It's messy already and I don't have a great feeling about more interaction between build and hostfxr after the experience so far.

Presumably we can piggy back off the messiness you've already wrangled, right? From what I can tell, to implement this diagnostic we only need to read a runtimeconfig.json and check if a runtime exists to satisfy the runtime framework name and version. Are there complications in doing this that would make the messiness even worse?

[nguerrera]

Not really. The resolver lives in its own world with its private hostfxr and no knowledge of the build tasks. And the build tasks have no knowledge of the resolver. So we'd either have to duplicate this messiness in the build tasks (yuck) or come up with some other activation scheme. I'd push for the latter but I don't have a solution in mind for it yet. It's definitely something that would need careful thought. I hope we don't decide to rush on it for 2.1.3.

[nguerrera]

And I'm still concerned about the general idea of warning about what won't run with the dotnet on PATH. It is valid to publish from an environment that can't run a program to an environment that can.

A suppressible warning isn't the worst sin of this kind. It pales in comparison to say RAR thinking the presence of an assembly in the build machine's GAC is relevant to whether it should be copied. But bad decisions like that give me pause whenever we discuss anything that ties the runtime environment of the build to the runtime environment of the program being built.

[rockerinthelocker]

@natemcmaster , @coolcsh , While you're at it, #3257 might need the same treatment.