Shared framework publish on wildcard Microsoft.NETCore.App results in the "Error loading hostpolicy" exception

[guardrex]

Steps to reproduce

Create a shared framework application that targets a wildcard Microsoft.NETCore.App package with ...

"Microsoft.NETCore.App": {
    "type": "platform",
    "version": "1.0.0-*"
}

with NuGet.config of ...

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <clear />
    <add key="AspNetCI" value="https://www.myget.org/F/aspnetcidev/api/v3/index.json" />
    <add key="NuGet.org" value="https://api.nuget.org/v3/index.json" />
  </packageSources>
</configuration>

Expected behavior

Restore, publish, and dotnet .\testshared.dll runs the app.

Actual behavior

project.lock.json resolves the package to Microsoft.NETCore.App/1.0.0-rc2-23931
testshared.runtimeconfig.json resolves to ...

{
  "runtimeOptions": {
    "framework": {
      "name": "Microsoft.NETCore.App",
      "version": "1.0.0-rc2-23931"
    }
  }
}

dotnet .\testshared.dll results in ...

Error loading hostpolicy 1.0.1-rc2-002296; interface mismatch between hostpolicy [32771] and 
hostfxr [120]. Specifically, the structure of corehost_init_t has changed, do not know how to 
interpret it

Environment data

.NET Command Line Tools (1.0.0-rc2-002363)

Product Information:

 Version:     1.0.0-rc2-002363
 Commit Sha:  065e8352fc

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.10586
 OS Platform: Windows
 RID:         win10-x64

Discussion with @schellap on this at: https://github.com/dotnet/cli/issues/2452
Possibly related or a dupe of: https://github.com/dotnet/cli/issues/2405
Repro project: https://github.com/GuardRex/sharedapp

[schellap]

There are two issues here:

1. The back compat issue which is well understood at this point and the resolution is to move to a latest CLI clean install. In this case, ASP .NET needs to update their feed with latest CLI bits. See related discussion here: https://github.com/dotnet/cli/issues/2435
2. The second issue is the project.json targets 1.0.0-* picks up some framework potentially a higher version from the feed than even what CLI MSIs bring in. Thus this higher framework is not found on the box. Our roll-forward doesn't downgrade so the app has the FX missing.

[guardrex]

@schellap 🎉 😄 Working! 🎉 😄 for me now on -2394. I'm using the wildcard syntax for Microsoft.NETCore.App, and all is well.

I had to make a strange unrelated change to one of my feed addresses ...

https://www.myget.org/F/aspnetcidev/api/v3/index.json

... stopped working as a feed, and I had to strip the www off of the address for ...

https://myget.org/F/aspnetcidev/api/v3/index.json

... to get it working. The feed address that was not resolving for me is in the one shown in the cli-samples repo, so I'm not sure what's up with that. /cc @davidfowl ... prior feed address working fine now. idk what that was all about!

Shall I close this now? You don't need this to remain open, correct?

[schellap]

Wildcard is an issue if whats on the feed is higher than whats on the box as we don't downgrade. Version ranges @davidfowl :)

[schellap]

The feed got updated with the netcoreapp bits lower than or equal to whats on the box.

[guardrex]

I'll close then. Thank you @schellap for your help. I'm still a little 💀 scared 💀 of the shared framework model due to the instability of my shared test app over the last week. Standalone has been rock-solid for test apps and production apps. Time and experience with shared should change that feeling. Thanks again for your help.

[bleroy]

@schellap 's comment "The second issue is the project.json targets 1.0.0-* picks up some framework potentially a higher version from the feed than even what CLI MSIs bring in. Thus this higher framework is not found on the box. Our roll-forward doesn't downgrade so the app has the FX missing." should be addressed. The star is too tempting, and does result in real head-scratchers.

[TheRealPiotrP]

@bleroy @blackdwarf what is the fix you imagine here?

[blackdwarf]

@piotrpMSFT so there are a couple of things that come to mind (not exclusive):

1. Make restore (or build) complain about this metapackage and advise people to not put in a star with a good error message and a link to...
2. ...a proper docs that explains why stars are not good for this scenario and why people should avoid them (in general as well).

The templates already do not contain a star, so in order to come into this situation, the user has to manually modify the dependency in the project file.

[TheRealPiotrP]

This needs to work with platform packages in general. We don't want to hard-code package lists.

This scenario will only blow up in two cases, and I don't think I want to block other scenarios since doing a build shouldn't require that you install a shared framework e.g.

The first case it blows up is run and we could easily put a check there that validates that the Shared Framework version is available. We'd want to do this in a way that VS can handle as well.

The second case is dotnet path/to.dll. Here we need to have a good clear message whether this bug is the driver or not. Luckily, @schellap seems to have already done that:

The specified framework 'Microsoft.NETCore.App', version '1.1.1' was not found.
  - Check application dependencies and target a framework version installed at:
      /Users/piotrp/code/github/piotrpMSFT/cli/artifacts/osx.10.11-x64/stage2/shared/Microsoft.NETCore.App
  - The following versions are installed:
      1.0.1
  - Alternatively, install the framework version '1.1.1'.

So, if we fix up the dotnet run scenario are we in good shape?

[blackdwarf]

@piotrpMSFT sounds like a plan. Of course, we need docs as well. I will file that issue in dotnet/docs repo.

[TheRealPiotrP]

Documentation bug is filed, and the run-time behavior is being tracked in #458. Closing this issue.