NuGet doesn't install split localized packages in PackageReference

[ericstj]

Repro:
Create a .NET 4.5 project and install "Microsoft.AspNet.Mvc": "5.2.3".
Now try to install "Microsoft.AspNet.Mvc.de": "5.2.3"

Expect:
Install success and localized bits are overlayed on the primary package.

Actual:
Install failure.

Microsoft.AspNet.Mvc.de 5.2.3 is not compatible with .NETFramework,Version=v4.5.

This worked with a net45 project using packages.config.

I'm looking into this in an effort to see what can be done to reduce package size of CoreFx.

current doc link: https://docs.microsoft.com/en-us/nuget/create-packages/creating-localized-packages

[yishaigalatzer]

I don't think we want to go with this approach, this model was never adopted by the community,and with this we are changing the content of a package in a global folder, which is violating the basic principle of content of a package is the same given its id and version.

I think we want to go back and discuss the loading model for localized assets (which we can probably do in .NET), and the XML documentation in visual studio.

So this needs to reopen the discussion we had last time with VS.

I do agree that you should be able to install the localized package as is, in its own folder (if of course we can find a way to make it usable).

So to summarize we have a few options:

1. Declare these packages not supported
2. Allow these packages to restore, but put them in their own folder and make .net load them from the right place, and make vs support a different from of xml intellisense (through the redirect)
3. Do the hacky thing NuGet did with packages.config
4. Make the default .NET install not bring down anything but English for RC, and work on a plan for RTM.

CC @lodejard @davidfowl

[rrelyea]

@mishra14 -- you said you knew a dupe?

[nkolev92]

I'm not sure the design is clear cut here. Adding more labels to indicate the status and moving back to New Issues for retriaging.