EF package broken with devDependency flag explicitly setting exclude=Runtime for PackageReference

[jainaashish]

From dotnet/efcore#11437

1. You have a tool like the EF commands (Add-Migration PMC command or dotnet ef), or the xUnit.net test runner, the MVC scaffolding, etc.
2. You need an entry point into the user's project to reflect over and invoke their code to get their DbContext model, test classes, controllers, etc. This entry point is distributed in a NuGet package with developmentDependency="true" so it doesn't get published to the server or referenced by other projects. This is our Microsoft.EntityFrameworkCore.Design package (brought in transitively by the Microsoft.EntityFrameworkCore.Tools package). You want this assembly brought in alongside the runtime assemblies so it can take advantage of NuGet's version resolution and binding redirect logic.
3. Your tool loads the assembly (Assembly.Load()) in the context of the user's project (e.g. using it's App.config). On .NET Framework, we use a separate AppDomain with the project's App.config file to apply appropriate binding redirects. In this case, the assembly just needs to be in the bin folder to work. On .NET Core, we start a new process using the user's deps.json json file (could also be done using an AssemblyLoadContext and the deps.json file). In this case, the assembly needs to be listed in the deps.json file in order for Core CLR to find it, but since the deps.json file is generated from the assets.json file, it's missing the entry when ExcludeAssets="Runtime" is used.
4. The design-time entry point loads and executes the user's assembly to add a migration, run tests, scaffold a view, etc.

[bricelam]

(Also from dotnet/efcore#11437)

This is also broken in .NET Framework projects. In packages.config projects, the assemblies in packages with developmentDependency="true" were copied to the output directory. With <PackageReference>, they're not.

[ajcvickers]

Note that this is breaking EF Core 1.0, 1.1, 2.0, 2.1 on .NET Core and .NET Framework. Therefore it is breaking the .NET Core SDK for 1.0, 1.1, 2.0, and 2.1.

/cc @Eilon @divega @DamianEdwards for visibility

[jainaashish]

Fixed as part of internal bug# https://devdiv.visualstudio.com/DevDiv/_workitems/edit/589635
and commit# NuGet/NuGet.Client@2e21519

[bording]

@jainaashish Since the referenced commit reverted the development dependency support, is there a public followup issue to track adding it back, in whatever form that might occur?

[jainaashish]

yeah I've reopened the original issue tracking this work# #4125 and marked for next release.