The dotnet store is incorrectly including BCL assemblies when targeting .NET Core 3.1

Using the following store manifest that only includes Newtonsoft.Json

<Project Sdk="Microsoft.NET.Sdk">
  <ItemGroup>
    <PackageReference Include="Newtonsoft.Json" Version="9.0.1" />
  </ItemGroup>
</Project>

I execute the following command to create a store for .NET Core 2.1:

dotnet store --manifest .\manifest.xml -f netcoreapp2.1 -o ./store2.1 -r linux-x64 --skip-optimization

the store artifact.xml contains only Newtonsoft.Json as expected.

<StoreArtifacts>
  <Package Id="Newtonsoft.Json" Version="9.0.1" />
</StoreArtifacts>

But then creating the store for .NET Core 3.1 using the command:

dotnet store --manifest .\manifest.xml -f netcoreapp3.1 -o ./store3.1 -r linux-x64 --skip-optimization

Creates a store with a lot of runtime and system dlls which bloat the package store and also those assembles fail to the store optimization.

<StoreArtifacts>
  <Package Id="Microsoft.CSharp" Version="4.0.1" />
  <Package Id="Newtonsoft.Json" Version="9.0.1" />
  <Package Id="runtime.any.System.Collections" Version="4.0.11" />
  <Package Id="runtime.any.System.Diagnostics.Tools" Version="4.0.1" />
  <Package Id="runtime.any.System.Globalization" Version="4.0.11" />
  <Package Id="runtime.any.System.IO" Version="4.1.0" />
  <Package Id="runtime.any.System.Reflection" Version="4.1.0" />
  <Package Id="runtime.any.System.Reflection.Extensions" Version="4.0.1" />
  <Package Id="runtime.any.System.Reflection.Primitives" Version="4.0.1" />
  <Package Id="runtime.any.System.Resources.ResourceManager" Version="4.0.1" />
  <Package Id="runtime.any.System.Runtime" Version="4.1.0" />
  <Package Id="runtime.any.System.Runtime.Handles" Version="4.0.1" />
  <Package Id="runtime.any.System.Runtime.InteropServices" Version="4.1.0" />
  <Package Id="runtime.any.System.Text.Encoding" Version="4.0.11" />
  <Package Id="runtime.any.System.Text.Encoding.Extensions" Version="4.0.11" />
  <Package Id="runtime.any.System.Threading.Tasks" Version="4.0.11" />
  <Package Id="runtime.unix.System.Diagnostics.Debug" Version="4.0.11" />
  <Package Id="runtime.unix.System.IO.FileSystem" Version="4.0.1" />
  <Package Id="runtime.unix.System.Private.Uri" Version="4.0.1" />
  <Package Id="runtime.unix.System.Runtime.Extensions" Version="4.1.0" />
  <Package Id="System.Dynamic.Runtime" Version="4.0.11" />
  <Package Id="System.IO.FileSystem.Primitives" Version="4.0.1" />
  <Package Id="System.Linq" Version="4.1.0" />
  <Package Id="System.Linq.Expressions" Version="4.1.0" />
  <Package Id="System.ObjectModel" Version="4.0.12" />
  <Package Id="System.Reflection.Emit" Version="4.0.1" />
  <Package Id="System.Reflection.Emit.ILGeneration" Version="4.0.1" />
  <Package Id="System.Reflection.Emit.Lightweight" Version="4.0.1" />
  <Package Id="System.Reflection.TypeExtensions" Version="4.1.0" />
  <Package Id="System.Runtime.Serialization.Primitives" Version="4.1.1" />
  <Package Id="System.Text.RegularExpressions" Version="4.1.0" />
  <Package Id="System.Threading" Version="4.0.11" />
  <Package Id="System.Threading.Tasks.Extensions" Version="4.0.0" />
  <Package Id="System.Xml.ReaderWriter" Version="4.0.11" />
  <Package Id="System.Xml.XDocument" Version="4.0.11" />
</StoreArtifacts>

This change in behavior seems to make the dotnet store command a broken experience.

@nguerrera We have talked about dotnet store in the past. Can you shed any light on why this is happening now?

[dsplaisted]

@normj The NullReferenceException should be fixed in the 3.1.400 SDK release.

[normj]

@niklr For the Lambda side the ball is in my court now to update the Lambda tooling to use the work around added in 3.1.400. I hope to get to that soon just juggling a few things right now. I think the issue is still worth leaving open as I think the current fix in 3.1.400 is a work around that requires users of the dotnet store command to do extra work and hopefully there will be a fix someday that doesn’t require any extra work.