Web app user experience is broken

[dseefeld]

When doing a smoke test on the built source-build cli, the user experience for building a web app is broken.

Steps to repro:

dotnet new web
dotnet restore
dotnet build
dotnet run

The results of dotnet run are:

Using launch settings from /src/tarball-output/testing-smoke/C#_web/Properties/launchSettings.json...
It was not possible to find any compatible framework version
The specified framework 'Microsoft.AspNetCore.App', version '2.1.0-preview2-final' was not found.
  - Check application dependencies and target a framework version installed at:
      /src/tarball-output/testing-smoke/builtCli/
  - Installing .NET Core prerequisites might help resolve this problem:
      http://go.microsoft.com/fwlink/?LinkID=798306&clcid=0x409
  - The .NET Core framework and SDK can be installed from:
      https://aka.ms/dotnet-download

This message seems to indicate that I need to download Microsoft.AspNetCore.App, but I don't see that it's available separately. It is only available if you download dotnet core.

There should be some way to acquire just the aspnet bits.

[dseefeld]

cc @natemcmaster

[natemcmaster]

ASP.NET Core is not source-buildable yet, so this is expected #375. https://aka.ms/dotnet-download doesn't show Microsoft.AspNetCore.App yet because we haven't RTM-ed the first version. Presumably the instructions look similar to https://www.microsoft.com/net/download/linux-package-manager/fedora26/runtime-2.1.0-preview2, but install the aspnetcore-runtime-2.1.0-preview2-final package.

cc @leecow @rowanmiller - it looks like ASP.NET Core runtime installers are not yet listed on https://www.microsoft.com/net/download/dotnet-core/runtime-2.1.0-preview2. How can we add a section for this?

[rowanmiller]

Downloads are driven by https://github.com/dotnet/core/blob/master/release-notes/releases.json. Work with @leecow to get the missing entries added.

[omajid]

@natemcmaster We are planning on using source-build on RHEL. There are are a few major issues with the suggestions that I can see.

1. We can't ask users to use a non-RHEL repository to have a working ASP.NET Core setup. If we are asking users to do that, why not just ask them to use all the packages from the Microsoft repository? Same issues applies for anyone else trying to use source-build on any Linux distribution.

2. What about dependencies? Most packages from the Microsoft RPM repo have dependencies on other Microsoft packages. Is installing just ASP.NET Core runtime package (without installing the Microsoft-built RPMs) even an option? For any distribution not supported by Microsoft, it looks like using ASP.NET Core may not even work.

3. The packages at the microsoft repository will install the ASP.NTE Core shared runtime at /usr/share/dotnet/.., while our installation of .NET Core will be somewhere under /opt/... Our installation will not be able to make use of the ASP.NET Core packages installed that way.

cc @aslicerh @tmds @Bob-Davis It looks like ASP.NET Core will not work out of the box from source-build. And will require users to install extra bits by hand, to possibly work at all.

[rowanmiller]

@natemcmaster was just looking at the file and I see the entries there and the corresponding links on the site. Are there some that are missing?

[tmds]

We can't ask users to use a non-RHEL repository to have a working ASP.NET Core setup.

That would completely break .NET Core support in OpenShift.

AFAIK this is supposed to work similar as 2.0 for source-build binaries, that is: the package comes from nuget.org when the user restores his app (https://www.nuget.org/packages/Microsoft.AspNetCore.App/2.1.0-preview2-final)

[natemcmaster]

@rowanmiller yes, we're missing a few download links on the list. We also have Alpine Linux .tar.gz file downloads. Is https://github.com/dotnet/core the best place to file an issue for this? Also, sorry if I wasn't clear, but I was trying to ask how we can get this page to show that users need to run apt-get install aspnetcore-runtime-$version (and likewise for yum, dnf, etc.) https://www.microsoft.com/net/download/linux-package-manager/fedora26/runtime-2.1.0-preview2. Right now this page only shows instructions for apt-get install dotnet-runtime-$version.

@omajid may we should start a mail thread on this subject. ASP.NET Core has never been source-buildable, and as described in #375, it is considerable effort to enable it. We don't have that work scheduled for 2.1.0 RTM. If I remember right, you worked around this in 2.0.x by disabling the ASP.NET Core runtime store. We'll have to investigate if a similar workaround is available now that we are shipping aspnet as a shared framework.

cc @muratg @DamianEdwards

[Bob-Davis]

I would echo what @tmds stated - the expectation here is that it would work how 2.0 worked, and pull the package(s) from nuget.

This sounds like this point release is breaking the expected functionality.
Am I misunderstanding this?

[natemcmaster]

To be clear, what I meant by

If I remember right, you worked around this in 2.0.x by disabling the ASP.NET Core runtime store. We'll have to investigate if a similar workaround is available now that we are shipping aspnet as a shared framework.

is that in 2.0, this was the story.

	Source built installation	Default installations
NuGet Packages	NuGet.org	NuGet.org
ASP.NET Core runtime binaries	In app's publish folder (via opt-ing out of the runtime store trimming)	ASP.NET Core Runtime Package Store

In 2.1, the issue at hand is this

	Source built installation	Default installations
NuGet Packages	NuGet.org (no change)	NuGet.org
ASP.NET Core runtime binaries	???? (need to determine how to make this app local)	ASP.NET Core Shared Runtime Framework

[tmds]

???? (need to determine how to make this app local)

Yes, we are missing the equivalent of 2.0 'PublishWithAspNetCoreTargetManifest=false'.

[DamianEdwards]

The shared framework can be opted out of by having the templates explicitly set Microsoft.NETCore.App as the platform package.

[tmds]

The shared framework can be opted out of by having the templates explicitly set Microsoft.NETCore.App as the platform package.

@DamianEdwards how do you csproj that?

[natemcmaster]

Presumably you can do that by setting this:

  <PropertyGroup>
    <MicrosoftNETPlatformLibrary>Microsoft.NETCore.App</MicrosoftNETPlatformLibrary>
  </PropertyGroup>

Disclaimer: haven't tried it myself.

[tmds]

And setting MicrosoftNETPlatformLibrary makes those assemblies part of the published application?

Would it be possible to make this a single property we can set (like we were setting PublishWithAspNetCoreTargetManifest), since in our scripts we don't know if the user is targeting Microsoft.NETCore.App or Microsoft.NETCore.All.

[natemcmaster]

And setting MicrosoftNETPlatformLibrary makes those assemblies part of the published application?

That's the theory. It instructs the SDK which NuGet package represents the shared framework.

Would it be possible to make this a single property we can set

I believe <MicrosoftNETPlatformLibrary>Microsoft.NETCore.App</MicrosoftNETPlatformLibrary> is the default value for all projects using Microsoft.NET.Sdk. But if you find setting this unconditionally causes issues, let me know.