runtime: SqlClient: Connection to Sql Server over network with named instance fails to connect

When attempting to connect to a Sql Server instance over the network, with named instances, SqlConnection throws error 26 on .NET Core with the SqlClient nuget library.

Sample Code

using System;
using System.Data.SqlClient;
namespace ConsoleApp1 {
    class Program {
        static void Main(string[] args) {
            var sqlString = "Data Source=192.168.0.3\\SQLEXPRESS;Initial Catalog=Database;User ID=sa;Password=<password>";
            var conn = new SqlConnection(sqlString);
            conn.Open();
            conn.Close();
            Console.WriteLine("Hello World!");
        }
    }
}

This sample code was tested working on .NET 4.5 and 4.6.1, but breaks on .NET Core 2.0, 1.1 and 1.0, along with versions 4.4, 4.3, and 4.1 of the System.Data.SqlClient library on nuget. I’ve been able to only reproduce this on Windows.

The server is configured for remote access as I’m able to connect to the remote instance using the same sample code full .NET Framework. The expected output should just be Hello World! and the program terminating, which happens on the full framework. However the following exception gets thrown instead on .NET Core:

System.Data.SqlClient.SqlException occurred
  HResult=0x80131904
  Message=A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified)
  Source=Core .Net SqlClient Data Provider
  StackTrace:
   at System.Data.SqlClient.SqlInternalConnectionTds..ctor(DbConnectionPoolIdentity identity, SqlConnectionString connectionOptions, Object providerInfo, Boolean redirectedUserInstance, SqlConnectionString userConnectionOptions, SessionData reconnectSessionData, Boolean applyTransientFaultHandling)
   at System.Data.SqlClient.SqlConnectionFactory.CreateConnection(DbConnectionOptions options, DbConnectionPoolKey poolKey, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningConnection, DbConnectionOptions userOptions)
   at System.Data.ProviderBase.DbConnectionFactory.CreatePooledConnection(DbConnectionPool pool, DbConnection owningObject, DbConnectionOptions options, DbConnectionPoolKey poolKey, DbConnectionOptions userOptions)
   at System.Data.ProviderBase.DbConnectionPool.CreateObject(DbConnection owningObject, DbConnectionOptions userOptions, DbConnectionInternal oldConnection)
   at System.Data.ProviderBase.DbConnectionPool.UserCreateRequest(DbConnection owningObject, DbConnectionOptions userOptions, DbConnectionInternal oldConnection)
   at System.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, UInt32 waitForMultipleObjectsTimeout, Boolean allowCreate, Boolean onlyOneCheckConnection, DbConnectionOptions userOptions, DbConnectionInternal& connection)
   at System.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, TaskCompletionSource`1 retry, DbConnectionOptions userOptions, DbConnectionInternal& connection)
   at System.Data.ProviderBase.DbConnectionFactory.TryGetConnection(DbConnection owningConnection, TaskCompletionSource`1 retry, DbConnectionOptions userOptions, DbConnectionInternal oldConnection, DbConnectionInternal& connection)
   at System.Data.ProviderBase.DbConnectionInternal.TryOpenConnectionInternal(DbConnection outerConnection, DbConnectionFactory connectionFactory, TaskCompletionSource`1 retry, DbConnectionOptions userOptions)
   at System.Data.SqlClient.SqlConnection.TryOpen(TaskCompletionSource`1 retry)
   at System.Data.SqlClient.SqlConnection.Open()
   at TestSqlAccess.Program.Main(String[] args) in C:\src\PlaneStatus\TestSqlAccess\Program.cs:line 9

Temporary Workaround

I figured out for now was using hostname,port instead of the hostname\\instance works and connects as intended, however I’d like to use a named instance instead of having to rely on ports.

This workaround does not work for Linux, at least according to my tests, as it throws other exceptions even with this workaround, mostly being able to not connect. I haven’t checked Mac since I don’t have access to one.