Package for .NetCore3.1 without Dependencies

[steffi3011]

Hello,
I noticed that the package for . NetCore3.1 is provided with dependencies.
Could you please create the nuget package without dependencies as far as possible?
Thank you in advance.
Stefanie

[JimBobSquarePants]

Why?

[ANahr]

Currently there is only a .NETStandard 2.1 nuget package. However having a .Net Core 3.1+ package would have the following advantages:

• Makes newget clear about dependencies (there would be none on .Net Core 3.1 or higher)

• Prevents installing a huge list of dependencies while developing:

E.g. a plain .Net Core 3.1 Application:

Installing:

Microsoft.NETCore.Platforms.1.1.0
Microsoft.NETCore.Targets.1.1.0
runtime.native.System.4.3.0
runtime.native.System.IO.Compression.4.3.0
SixLabors.Fonts.1.0.0-beta15
System.Buffers.4.3.0
System.Collections.4.3.0
System.Collections.Concurrent.4.3.0
System.Diagnostics.Debug.4.3.0
System.Diagnostics.Tracing.4.3.0
System.Globalization.4.3.0
System.IO.4.3.0
System.IO.Compression.4.3.0
System.IO.FileSystem.Primitives.4.3.0
System.IO.UnmanagedMemoryStream.4.3.0
System.Numerics.Vectors.4.5.0
System.Reflection.4.3.0
System.Reflection.Primitives.4.3.0
System.Resources.ResourceManager.4.3.0
System.Runtime.4.3.0
System.Runtime.CompilerServices.Unsafe.4.7.0
System.Runtime.Extensions.4.3.0
System.Runtime.Handles.4.3.0
System.Runtime.InteropServices.4.3.0
System.Text.Encoding.4.3.0
System.Threading.4.3.0
System.Threading.Tasks.4.3.0
System.Threading.Tasks.Parallel.4.3.0
System.ValueTuple.4.5.0

• Keeps deps.json file clean and small:

A simple .Net Core 3.1 Project has about 0,5kb deps.json. With SixLabors.Fonts it instantly grows to >17kb

All these "negative effects" could be mitigated by providing a dependency-free .Net Core 3.1 nuget target.
Just to reiterate: The code of the library itself currently already IS dependency-free for .Net Core 3.1.

[SimonCropp]

@steffi3011 @ANahr deps.json is an implementation detail of how nestandard works. its size or number of items does not necessarily indicate real negative impact on you. Perhaps you could articulate the problem in actual negative outcomes? eg

• slower build time
• larger resulting app that needs to be deployed
• more memory used by the build
• more difficulty managing dependencies

If no real increased resources are used and no increased technical complexity, then i dont really understand why it matters

[ANahr]

Concerning the .deps:
The application that uses the library will be

• a slightly larger app and it
• will take slightly longer to start up (All of those references need to be loaded and resolved to inbox version at application startup) moreover it
• makes internal tools that we have and that use .deps files unneccesarily complex/ need special handling (because they don't understand type forwarders).

However of course all of these things are tiny effects that are barely measurable.
Point 1 and 2 from the original list do have far more weight for me.

Btw: I already tried and implementation-wise we are talking about a 3-line change in the .csproj to mitigate all this.

[JimBobSquarePants]

I think I'm happy to add the target simply because I'll be looking to phase out netstandard in future versions and this gives us a bridge. Thanks both for your valuable input!

[ANahr]

Thanks, looking forward to the next version

[JimBobSquarePants]

I've just opened #207 for this. Few more changes required than 3 lines though 😉