TcpListener.LocalEndPoint property should really be IPEndPoint, not EndPoint

[geoffkizer]

Since TcpListener is specific to TCP, the LocalEndPoint is always an IPEndPoint, yet it's typed as EndPoint. This means users of this property need to downcast to IPEndPoint to access the actual IPAddress and Port.

We should consider adding new API here so that it's obvious that this can only be an IPEndPoint, and users don't have to do the downcast themselves.

We could simply add a new property like "LocalIPEndPoint", or perhaps "ListenEndPoint" -- I like the latter personally, it calls out that this is different than the typical Local/RemoteEndPoint semantics for connected sockets.

Or we could choose to avoid EndPoint/IPEndPoint entirely and expose the IPAddress and Port as separate properties, something like "ListenIPAddress" and "ListenPort".

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Since TcpListener is specific to TCP, the LocalEndPoint is always an IPEndPoint, yet it's typed as EndPoint. This means users of this property need to downcast to IPEndPoint to access the actual IPAddress and Port.

We should consider adding new API here so that it's obvious that this can only be an IPEndPoint, and users don't have to do the downcast themselves.

We could simply add a new property like "LocalIPEndPoint", or perhaps "ListenEndPoint" -- I like the latter personally, it calls out that this is different than the typical Local/RemoteEndPoint semantics for connected sockets.

Or we could choose to avoid EndPoint/IPEndPoint entirely and expose the IPAddress and Port as separate properties, something like "ListenIPAddress" and "ListenPort".

Author:	geoffkizer
Assignees:	-
Labels:	api-suggestion, area-System.Net.Sockets
Milestone:	-

[karelz]

Triage: Changing the return type would be binary breaking change.
Note TcpListener is not sealed and the property is not virtual.

We should add the new API LocalIPEndPoint, then obsolete and hide from editor the old API.
It would bring small value to customer, not a high pri.

It may make more sense to prioritize it in the context of #63162.

[wfurt]

triage: we should keep it as it is to prevent breaking change and favor #63162 instead to come up with something more complete and usable.