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

/azp run runtime-libraries-coreclr outerloop

It looks like all Connect(Async) overloads suffer from the same issue. The test was just only doing this for one of the overloads.
For some reason, only one of the overloads supported this before your change?

It looks like all Connect(Async) overloads suffer from the same issue. The test was just only doing this for one of the overloads.
For some reason, only one of the overloads supported this before your change?

yes, it seems like.
I guess in most use cases people don't expect Connect to work after the Socket is explicitly removed. I think this would be easy to fix as well.

I made another change @MihaZupan to set the Socket as needed if user pass in null. This would get us to same state as we would be in initially e.g. mimics the constructor behavior. That is some behavior change but it feels better than guarding every single Connect overload.
That broke ExclusiveAddressUse_NullClient test as now we will get OS/Socket default instead of always false.
Since the property defers to underlying Socket I see no value in the test to enforce false in this case.

Technically this makes it so you can never observe TcpClient.Client being null, even after you set it.
But that's probably a good thing - I don't see any value in carrying around an empty TcpClient.

/azp run runtime-libraries-coreclr outerloop

all failures are unrelated