Framework assemblies are no longer added to .nuspec when using the new .csproj project system

[kevinchalet]

Moved from #4412 (comment):

---

In the marvelous world of project.json, specifying a frameworkAssemblies node was enough to tell NuGet to add the corresponding entries in the .nuspec file:

{
  "frameworks": {
    "net451": {
      "frameworkAssemblies": {
        "System.IdentityModel": "4.0.0.0",
        "System.Xml": "4.0.0.0"
      }
    }
  }
}

<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2012/06/nuspec.xsd">
  <metadata>
    // ...
    <frameworkAssemblies>
      <frameworkAssembly assemblyName="System.IdentityModel" targetFramework=".NETFramework4.5.1" />
      <frameworkAssembly assemblyName="System.Xml" targetFramework=".NETFramework4.5.1" />
    </frameworkAssemblies>
  </metadata>
</package>

With .csproj, this is no longer true when using Reference:

<Project Sdk="Microsoft.NET.Sdk">

  <ItemGroup>
    <Reference Include="System.IdentityModel" />
    <Reference Include="System.Xml" />
  </ItemGroup>

</Project>

This breaking change has obviously important implications, as framework assemblies are no longer brought transitively, which means that the final user of the package has to reference the framework assemblies in his own app.

[rohit21agrawal]

@dsplaisted Can <Reference> in Net Core projects point to a random DLL on disk which is not a framework assembly?

[dsplaisted]

It will be able to in the 2.0 tools.

[rohit21agrawal]

@dsplaisted will there be a way to distinguish what References come from the framework and what come from a DLL on disk? Is there a design doc for this so we can adapt pack accordingly?

[dsplaisted]

Here's the PR where this was added to the SDK: dotnet/sdk#876

It turns out we mentioned that nuget pack would need to handle this but never filed an issue.

The logic to figure out where the references actually come from is very complicated and involves the ResolveAssemblyReferences task. I doubt there is a current spec for it.

It might be OK to just see whether the ItemSpec has a .dll or .exe extension, and if so assume it's a file reference, otherwise assume it's a framework reference. Also, .NET Core and .NET Standard projects wouldn't support framework references anyway.

@rainersigwald, @nguerrera, or @eerhardt may be able to provide more feedback.

[NickCraver]

This is a pretty big blocker to find out about at the end of a port. Is there a workaround? I'm porting major libraries here (Dapper, MiniProfiler, StackExchange.Redis, etc.) and this is a big step backwards for the consumer, having to reference framework libraries manually that just worked on the old system.

From a user point of view, they're better off with me not moving to the VS 2017 project system - what can we do so this isn't the case?

[dsplaisted]

One work around would be to continue to use a nuspec, I think.