So if you squint and look at the project.json, it’s basically a nuspec with a little bit of goop to describe what compilation options and sources are needed to build to project. Nuspecs today have 2 sections, frameworkAssemblies for “built in” stuff and dependencies for other nuget dependencies. It has the same meaning here. When you use something from “the framework”, it needs to be specified in frameworkAssemblies vs being a nuget package dependency.
Now onto specifics:
When you use a PCL or .NET Core based library on .NET Framework, the references are to reference assemblies (sometimes called contract assemblies). Some examples of these are things like System.Runtime, System.Threading etc. When using MSBUILD based projects, there is a task that runs which basically automatically adds all of the System.* references to the C# compiler to avoid this mess. These assemblies are called facades on .NET Framework. The unfortunate part is that it adds ALL of them even if they aren’t used. A dependency on System.Runtime is the trigger for this behavior (when running on .NET Framework based csproj files).
The reason adding a reference to the same package doesn’t work is because the .NET Framework folder (net4*) for those contract assemblies (like System.Runtime), don’t have any dlls in them. If you look at those folders, you’ll see an empty _._ file. The reasoning for this is because when you declare a nuget package with a frameworkAssembly reference to System.Runtime, the msbuild project systems fails to install it (very complicated bug and design problem).
That probably made things fuzzier…