Localized satellite packages are incorrectly marked as incompatible by the CLI

[DamianEdwards]

Steps to reproduce

Create a console application and add a reference to "Humanizer": "2.0.1", then run dotnet restore

Expected behavior

Restore completes successfully.

Actual behavior

CLI states that the satellite packages aren't compatible with netcoreapp1.0
This seems to be due to those packages only contained resources, and no runtime, ref or lib assets, and the CLI currently doesn't account for this (see https://github.com/dotnet/cli/blob/rel/1.0.0/src/Microsoft.DotNet.ProjectModel/Resolution/PackageDependencyProvider.cs#L35-L38)

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.0-preview1-002702)

Product Information:
 Version:     1.0.0-preview1-002702
 Commit Sha:  6cde21225e

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

[davidfowl]

/cc @yishaigalatzer @rrelyea @emgarten Can we expose the nuget compatibility check via an API that the CLI can use?

[yishaigalatzer]

We don't have actual public APIs on the NuGet packages (as in nothing we can commit to be fully stable), but we can definitely share how to run the check. @joelverhagen can you drop a sample here?

[davidfowl]

We have a check but it's out of date. It would be great if we could call into something, even if it wasn't a good API. The cli and nuget ship in the same app so it's impossible to update nuget outside of the cli (as a cli user) so the risk of breaking is low

[yishaigalatzer]

@davidfowl agreed. We are taking a look right now

[joelverhagen]

I don't think we have a public API for this right now. The code certainly exists (CompatibilityChecker.cs), but it is marked as internal.

We should keep this issue open in dotnet/cli as well as expose a friendly API in NuGet: NuGet/Home#2911.

[yishaigalatzer]

@davidfowl now that I think about it, why does the CLI even do this check? If restore succeeds it means the packages are compatible. Can you elaborate a bit?

[davidfowl]

Nuget does not persist all of the results of restore. We need the build and the IDE to show nice errors when a restore fails. Today this works in UWP because restore runs on build. In the cli, we try to infer diagnostics from the lock file

[yishaigalatzer]

1. I still don't understand why we try to see if a package "fits" when restore succeeds?
2. We need to work on consolidating the two systems so we don't need duplicate code paths to "figure things out". Perhaps the right thing is to capture all restore errors, which we do write to the output and surface them instead?

[davidfowl]

I still don't understand why we try to see if a package "fits" when restore succeeds?

Restore succeeds and always writes the lock file (regardless of failure). Build and the project model server want to show the same errors that restore showed. To do that, it tries to repeat the compatibility check to make sure things got resolved.

We need to work on consolidating the two systems so we don't need duplicate code paths to "figure things out". Perhaps the right thing is to capture all restore errors, which we do write to the output and surface them instead?

That's the entire purpose of this request. The errors need to be persisted in some format, preferably the lock file since that's what we use for everything else.

[TheRealPiotrP]

@yishaigalatzer @rrelyea I see NuGet/Home#2911 is not scheduled yet. Do you expect this to make CLI preview2?

[clairernovotny]

Note that this completely breaks Humanizer from working correctly for CLI projects (and any other libraries that use satellite languages).

[TheRealPiotrP]

@brthor can you coordinate with @joelverhagen on this one?

[clairernovotny]

Anything on this? When is preview 3 schedule for? This completely blocks Humanizer from working on xproj. It does appear to install on a csproj that's netstandard.