Package bloat with duplicate native files (global tools)

[clairernovotny]

With .NET Core global tools, they are tied to the major version of the framework. They will auto roll-forward to the minor, so if you have a netcoreapp2.1 tool, if .NET Core 2.2 is the only one on the box, it'll work. However, if .NET Core 3 is the only one on the box, it'll fail under the current roll-forward policy.

That means tool authors will need to multi-target at least each major version netcoreapp2.1 and netcoreapp3.0.

If a package contains native assets in the publish, or have similar dependencies, there's a huge amount of duplicate files. This is not handled well today by ZIP. It would be helpful if NuPkg could do something about duplicated files (or better yet, at the block level).

As a concrete example, look at https://www.nuget.org/packages/nbgv/2.3.38. It's about 11 megs today due to native libgit2 assets.

Adding a netcoreapp3.0 target made it 23 megs: nbgv.2.3.40-gfa5f67eaa2.nupkg.zip [rename to .nupkg]

/cc @kathleendollard @terrajobst

[dotMorten]

Just solve that with a .targets file instead that deploys the native resources. IMHO the issue here isn't to have a way to handle duplicate files more efficiently, but to avoid needing duplicate files instead.

[clairernovotny]

@dotMorten That doesn't work with the way runtimes/tfm/RID/ works today. Publish takes all those outputs and bundles them up. You'd have to go to tremendous effort to work around it.

[dotMorten]

Are you thinking something like this in the nuspec?

<file src="output\blah\**\*.dll" target="dependencies\blah\**\*.dll" >
   <link path="tools\netcoreapp2.1\any\runtimes\**\*.dll" />
   <link path="tools\netcoreapp3.0\any\runtimes\**\*.dll" />
</file>

I do see how something like that could avoid a bit of the .targets hoopla I currently do.

[nkolev92]

//cc @rrelyea @anangaur