Fix | SqlLocalDB instance pipename issue with Encryption

[JRahnama]

fixes #1395

This PR fixes the issue by adding the support for Instance pipe name of localdb.

[ErikEJ]

Does this also cover Shared instance?

[JRahnama]

@ErikEJ I think so, Every localdb (shared or not) is having a pipe name instance

that pipe name is good for shared instances as well.
We were only checking for (localdb) as an identifier of localDB, however as per mentioned issue, some frameworks are using name pipe internally. This was not a problem up until we added Encrypt=true and now it tries to send and encrypted connection to localDB which is not supported.

[DavoudEshtehari]

Could you add LocalDbSharedInstanceName into the config.json and config.default.json files?

[johnnypham]

I think the input should also be checked if it's empty here. I'm getting different errors when using the prefixes as the server:

(localdb)\;
(provider: SNI_PN11, error: 51 - An instance name was not specified while connecting to a Local Database Runtime. Specify an instance name in the format (localdb)\instance_name.)

np:\\.\pipe\LOCALDB#/:
(provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)

[JRahnama]

this is user error. The error is pretty much explanatory and that is the behavior from before for (localdb).
1- (localdb)\.
2-(localdb)\Instance name
3- (localdb)\.\shared instance name

[JRahnama]

for named pipe:
the only part changing in np:\\.\pipe\LOCALDB#SH452F48\tsql\query is the number inside it

[JRahnama]

we could use other methods such as RegEx, but that would be an overkill. The fact that connection string starts with np:\\.\pipe\LOCALDB# is enough to conclude that user is trying LocalDB, so the Encrypt=true would not be applied to it. If user wants to change the named pipe server will reject that.

[johnnypham]

In the case of (localdb)\ , we tell the user that the server name is not in the correct format, i.e. the instance name is missing. In the case of np:\\.\pipe\LOCALDB#/, shouldn't we also tell them that the instance name is missing?

Edit: I don't think you understand my original comment. There is no need for regex here and this has nothing to do with encrypt=true. All I'm saying is when the user tries to connect with np:\\.\pipe\LOCALDB#/, we should tell them they are missing the instance name, just like we already do if they try connecting with (localdb)\.

[JRahnama]

In the case of (localdb)\ , we tell the user that the server name is not in the correct format, i.e. the instance name is missing. In the case of np:\\.\pipe\LOCALDB#/, shouldn't we also tell them that the instance name is missing?

I dont think so. Because that pattern is not created by user. It is in a folder in LocalDB inside Program File folder. So, you cant just create whatever you want. One can read the name from the folder using a process or copy paste it, whereas (localdb) could have some user mistakes. Plus are you testing in managed SNI?

[johnnypham]

Yes, it is the same in managed SNI.

The whole point of error handling is that we can't assume that the user knows what they're doing and got their named pipe server name from the correct source. If we assumed that the user does the right thing every time, there would be no need for error handling.

The error message when trying to connect to np:\\.\pipe\LOCALDB#/ states that a connection could not be opened because the server was not found or was inaccessible. We should be more specific and say that the connection failed because the provided server name was not even in the correct format.

[David-Engel]

I see merit in aligning the errors produced between tcp and np scenarios. However, I wouldn't block this PR since we are not changing the behavior here. The behavior can be addressed in the future so that we don't delay fixing this issue for the upcoming hotfix.