Runtime: Consider merging System.Net.Primitives and System.Net.Sockets
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:
- dotnet/runtime#30797
- dotnet/runtime#30196
- dotnet/runtime#30532
scalablecory
All 5 comments
Dropping "area-System.Net.Sockets" label. According to @karelz we only use one area label.
davidsh
on 11 Sep 2019
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
davidsh
on 11 Sep 2019
maybe you should rather make the internals public then as they may be usefull for someone else as well...
JanEggers
on 12 Sep 2019
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 :smirk: but yes...things change.
MarcoRossignoli
on 13 Sep 2019
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
stephentoub
on 18 Sep 2019
Related issues
noahfalk
路
3Comments
jzabroski
路
3Comments
omariom
路
3Comments
omajid
路
3Comments
nalywa
路
3Comments
Most helpful comment
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