Explicit restore for self-contained app behaves differently than implicit restore

Steps to reproduce

1. mkdir ExplicitRestore

2. cd ExplicitRestore

3. dotnet new console --no-restore

4. dotnet restore -r debian.8-x64 Inspect the obj/project.assets.json to see what version of Microsoft.NETCore.App is used - Microsoft.NETCore.App/2.0.0

5. mkdir ImplicitRestore

6. cd ImplicitRestore

7. dotnet new console --no-restore

8. dotnet build -r debian.8-x64 The build step fails - notice the version of Microsoft.NETCore.App being used - ‘’’ /ImplicitRestore/ImplicitRestore.csproj : error NU1102: Unable to find package Microsoft.NETCore.App with version (>= 2.0.1) /ImplicitRestore/ImplicitRestore.csproj : error NU1102: - Found 14 version(s) in nuget.org [ Nearest version: 2.0.0 ] ‘’’

Expected behavior

I was expecting the two scenarios to behave the same. Specifically I would expect them to be using the same version of Microsoft.NETCore.App - 2.0.1

Actual behavior

Explicit restore uses Microsoft.NETCore.App 2.0.0 while the implicit restore uses 2.0.1.

Environment data

dotnet --info output:

.NET Command Line Tools (2.0.1-servicing-006955)

Product Information:
 Version:            2.0.1-servicing-006955
 Commit SHA-1 hash:  6734510020

Runtime Environment:
 OS Name:     debian
 OS Version:  8
 OS Platform: Linux
 RID:         debian.8-x64
 Base Path:   /usr/share/dotnet/sdk/2.0.1-servicing-006955/

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.1
  Build    : 5eb2f9bd659ad2161a8e035ac4bccd8f892caa0a

[livarcocc]

32bit linux is not supported.

[nguerrera]

NOTE: We are opting not to bump implicit versions for self contained apps until we address this.

cc @richlander @KathleenDollard

This should no longer repro with the steps above when https://github.com/dotnet/cli/pull/7632 is merged. Should we keep this open to track design changes to this or file something new?