System.Net.Internals.SocketExceptionFactory+ExtendedSocketException

[akalnay]

For the code below I was expecting to get a System.Net.Sockets.SocketException, however for a .NET Core 2.2 project it throws a System.Net.Internals.SocketExceptionFactory+ExtendedSocketException:

 class Program
 {
 static async Task Main()
 {
 Console.WindowWidth = 132;
 try
 {
 await ConnectClientAsync();
 }
 catch (Exception e)
 {
 Console.WriteLine($"Caught exception {e.GetType()}.{Environment.NewLine}{e.Message}.");
 }
 Console.WriteLine("Press any key to end.");
 Console.ReadKey();
 }

 private static async Task ConnectClientAsync()
 {
 TcpClient tcpClient = new TcpClient();
 await tcpClient.ConnectAsync(IPAddress.Loopback, 54321).ConfigureAwait(false);
 }
 }

For a .NET Framework 4.7.2 project the same code throws the expected System.Net.Sockets.SocketException.

This issue appears to be similar to 20744, 29081, 30073.

Tagging subscribers to this area: @dotnet/ncl
Notify danmosemsft if you want to be subscribed.

[stephentoub]

it throws a System.Net.Internals.SocketExceptionFactory+ExtendedSocketException

That is a SocketException. It's a derived type.

[davidsh]

That is a SocketException. It's a derived type.

@stephentoub @wfurt

Do you remember why we invented this exception?

System.Net.Internals.SocketExceptionFactory+ExtendedSocketException

We've seen other devs hit this exception. I'm wondering we don't just throw a normal, public type like SocketException?

[stephentoub]

IIRC, it's because of the split across assembly boundaries / missing public ctors on SocketException. If such ctors were designed/added, the derived type could go away.

[this-fifo]

Not sure if this is related, but I just opened up an issue on SqlClient related to running inside Azure Databricks that has the same exception

EDIT: my issue turned out to be just the connection string 🤷‍♂️