Consider merging System.Net.Primitives and System.Net.Sockets

[scalablecory]

I think Primitives and Sockets are good candidates to merge back into a single assembly.

This would allow us to make some optimizations that are currently impossible because we lack access to internals between the assemblies. One such example is anything on Socket that takes an IPEndPoint argument.

Related:

• Proposal: Zero allocation connectionless sockets #30797
• Udp Socket.ReceiveFrom a lot of allocations for IPAdress #30196
• UDP Socket using SocketAsyncEventArgs garbage collects nearly every second #30532

[davidsh]

Dropping "area-System.Net.Sockets" label. According to @karelz we only use one area label.

[davidsh]

I think this issue opens up the broader discussion of merging other libraries (we used to call them 'contracts'). For example, merging System.Net.WebHeaderCollection with System.Net.Requests would solve some problems (#18784). In general, many times we really don't need new APIs between the libraries; we just need the libraries merged so that we can utilize 'internal' methods.

In .NET Framework, we had almost everything in System.dll. We moved to separate libraries as we went to .NET Core and had separate packages for things. It was thought, back then, that having many small dll's was a good thing.

However, things change. Now, we don't publish separate packages for each library. Binaries are lumped together in "mega" packages, i.e. Microsoft.NETCore.App. And there is no longer as much value in keeping binaries separate anymore, especially as we think about more 'native' solutions (IL to native code, i.e. .NET Native type of things) and single-executables for .NET Core.

@stephentoub

[JanEggers]

maybe you should rather make the internals public then as they may be usefull for someone else as well...

[MarcoRossignoli]

It was thought, back then, that having many small dll's was a good thing.

I remember that was one of the most advertised feat on docs/post/conference 😏 but yes...things change.

[stephentoub]

I'm not against recombining assemblies, but any such combining should be motivated by significant enough wins to warrant the effort, whether those wins be throughput, allocation reduction, binary size, etc. If we're interested in this, I suggest someone prototype it and see what the concrete benefits would actually be.
cc: @ericstj

[dotnet-policy-service]

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of our issue cleanup automation.

[dotnet-policy-service]

This issue will now be closed since it had been marked no-recent-activity but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.