runtime: ASP.NET MVC 2.0 apps don't work on 2.1 runtime

I verified success with latest 2.1 preview:

D:\git\repros\mvc2>more bin\Debug\netcoreapp2.0\mvc2.runtimeconfig.json
{
  "runtimeOptions": {
    "tfm": "netcoreapp2.0",
    "framework": {
      "name": "Microsoft.NETCore.App",
      "version": "2.0.0"
    },
    "configProperties": {
      "System.GC.Server": true
    }
  }
}

D:\git\repros\mvc2>dotnet --fx-version 2.1.0-preview1-26019-03 bin\Debug\netcoreapp2.0\mvc2.dll
Hosting environment: Production
Content root path: D:\git\repros\mvc2
Now listening on: http://localhost:5000
Application started. Press Ctrl+C to shut down.

Also tested this scenario with auto roll-forward from 2.0 to 2.1 when 2.0 is not installed (with new roll-forward policy changes via https://github.com/dotnet/core-setup/issues/3469)

D:\git\repros\mvc2>dotnet --list-runtimes
Microsoft.NETCore.App 2.1.0-preview1-26019-03 [C:\Program Files\dotnet\shared]

D:\git\repros\mvc2>dotnet bin\Debug\netcoreapp2.0\mvc2.dll
Hosting environment: Production
Content root path: D:\git\repros\mvc2
Now listening on: http://localhost:5000
Application started. Press Ctrl+C to shut down.

Snippet from COREHOST_TRACE=1:

--- Resolving FX directory, name 'Microsoft.NETCore.App' version '2.0.0'
Searching FX directory in [C:\Program Files\dotnet]
Attempting FX roll forward starting from [2.0.0]
'Roll forward on no candidate fx' enabled with value [1]. Looking for the least production greater than or equal to [2.0.0]
No production greater than or equal to [2.0.0] found. Looking for the least preview greater than [2.0.0]
Found version [2.1.0-preview1-26019-03]
Applying patch roll forward from [2.1.0-preview1-26019-03]
Inspecting version... [2.1.0-preview1-26019-03]
Changing Selected FX version from [] to [C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.1.0-preview1-26019-03]
Chose FX version [C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.1.0-preview1-26019-03]

The API do not have to be identical - the public S.R.CS.Unsafe can have extra APIs. You just need to add the ones that System.Memory needs.

Yes remove the IsNETCoreApp/IsUAP properties and remove the netcoreapp build configurations. Also remove the TreatAsOutOfBox suppression once those other properties are removed.

used in some tests

The tests should still depend on the public S.R.CS.Unsafe.

@eerhardt @jkotas here’s our offline meeting notes.

We discussed three classes of scenarios and approaches to each.

The three scenarios:

1. Framework should win. This is the current scenario as described in this issue’s repro steps (assembly added to framework package is newer than the app’s)
2. App should win. The app wants to bring in a newer OOB assembly like System.Collections.Immutable
3. Unknown who should win. The app has locally build framework assemblies or assembly references (not package references) but a roll-forward to a newer framework has occurred.

The proposed solutions to each:

1. Add new metadata to the framework’s deps.json to include the package version so we can make decisions on which is the newer version that we should use (details TBD, but could be as simple as including the versions of some of the decomposed packages that we previously only shipped OOB, such as System.Runtime.CompilerServices.Unsafe)
2. App local wins (like today)
3. App local wins (like today). The app should be re-targeted to the newer framework version, or the older framework should be installed (the one the app targeted).

Note that scenario (2) could change into scenario (1) when the OOB assembly becomes older than the current framework’s assembly during a roll-forward scenario.