The instance name is ignored when running on Linux

[RobClenshaw]

Describe the bug

When connecting to a non-default instance from a Linux client, Microsoft.Data.SqlClient 2.1 and later ignores the instance name and instead connects to the default instance. Obviously this is a problem as it raises the possibility of executing code on an instance that you didn't know you were connected to.

To reproduce

Setup a Windows server with two SQL Server instances. Let's call them server\defaultinstance and server\nondefaultinstance. I have SQL Server Profiler open with two traces running - one on each instance.

Using dotnet new create a console application using the following code and reference Microsoft.Data.SqlClient 2.1.1.

using Microsoft.Data.SqlClient;
using System;
using System.IO;

namespace test
{
    class Program
    {
        static void Main(string[] args)
        {
            var commandText = @"SELECT 1";

            var connectionString = new SqlConnectionStringBuilder() {
                InitialCatalog = "master",
                DataSource = @"server\nondefaultinstance",
                UserID = "sa",
                Password = "redacted",
                IntegratedSecurity = false
            };

            try {
                Console.WriteLine($"Executing SQL - {commandText}");

                using (var connection = new SqlConnection(connectionString.ToString()))
                {
                    connection.Open();
                    var command = new SqlCommand(commandText, connection);
                    command.ExecuteNonQuery();
                }
            }
            catch (Exception e)
            {
                Console.WriteLine("Caught an exception");
                Console.WriteLine(e.Message);
            }
            finally 
            {
                Console.WriteLine("End of program");
            }
        }
    }
}

I'm using an Ubuntu terminal in WSL2. In the terminal, change to the project directory and run dotnet run.

Expected behavior

To see a batch with SELECT 1 appear in the trace for server\nondefaultinstance

Actual behavior

A batch with SELECT 1 appears in the trace for server\defaultinstance

Further technical details

Microsoft.Data.SqlClient version: 2.1.1 (but 2.1.0 is also affected)
.NET target: 5.0
SQL Server version: Have tested on 2017 and 2019
Operating system: Server 2019 for running the two SQL Server instances, Ubuntu 20.04 for running the application

[ErikEJ]

And 2.0.1 ?

[mark-raymond]

It's fine in 2.0.1, the bug was introduced in 2.1.0. We haven't checked the previews of 2.1.0.

[Context: I'm a colleage of @RobClenshaw]

[ErikEJ]

I'm using an Ubuntu terminal in WSL2.

On the same Windows machine ? - what happens if you try from a remote machine?

[RobClenshaw]

I'm using an Ubuntu terminal in WSL2.

On the same Windows machine ? - what happens if you try from a remote machine?

It is on a remote machine.

[mark-raymond]

I have had a chance to test the preview releases – the bug is NOT present in 2.1.0-preview1.20235.1, and IS present in 2.1.0-preview2.20297.7.

I've made a repo with a minimal test program, based on @RobClenshaw's above, plus a wrapper script to make it easier to run on different versions: https://github.com/mark-raymond/issue868

[mark-raymond]

Line by line:

• 2.0.1, run against default instance, correctly returning MSSQLSERVER
• 2.0.1, run against named instance, correctly returning SQL2019CI
• 2.1.0-preview1.20235.1, run against named instance, correctly returning SQL2019CI
• 2.1.0-preview2.20297.7, run against named instance, incorrectly returning MSSQLSERVER
• 2.1.0, run against named instance, incorrectly returning MSSQLSERVER
• 2.1.1, run against named instance, incorrectly returning MSSQLSERVER

Edit: mdr-hp and mdr-win10 are both bare metal machines, on the same LAN, connected by ethernet. mdr-hp is running Ubuntu 16.04, mdr-win10 is running Windows 10 and has several SQL Server instances on it.

[cheenamalhotra]

Hi @RobClenshaw

The issue is reproducible. You may connect to Instance Port in the mean time by setting connection string as:
Server=<server>,<port>;...

We are investigating the issue.