#!connect mssql fails on WSL and Linux

[flytzen]

Describe the bug

I wanted to run Dotnet Interactive in a dev container on Windows (to make it easier to add python etc). Connecting to SQL fails as described below, so I tried it in WSL as well and the behaviour described is identical in both environments, making it look like it is a general linux issue. Testing the same steps in Windows works as expected.

NOTE: This looks like a similar problem to #883 - it is the same error message.

#r "nuget:Microsoft.DotNet.Interactive.SqlServer,*-*"

works correctly and reports the packages are installed.

#!connect mssql --kernel-name mydatabase "Persist Security Info=False; Initial Catalog=xxx; Server=yyy.database.windows.net;uid=zzz;pwd=zzz"

Reports the following error:

Error: System.ArgumentException: Path to SQL Tools Service executable was not provided. (Parameter 'serviceExePath')
   at Microsoft.DotNet.Interactive.SqlServer.MsSqlServiceClient..ctor(String serviceExePath)
   at Microsoft.DotNet.Interactive.SqlServer.MsSqlKernelConnection.CreateKernelAsync(MsSqlConnectionOptions options, KernelInvocationContext context)
   at Microsoft.DotNet.Interactive.CompositeKernel.<>c__DisplayClass28_0`1.<<AddKernelConnection>b__0>d.MoveNext() in D:\workspace\_work\1\s\src\Microsoft.DotNet.Interactive\CompositeKernel.cs:line 364
--- End of stack trace from previous location ---
   at System.CommandLine.Invocation.CommandHandler.GetExitCodeAsync(Object value, InvocationContext context)
   at System.CommandLine.Invocation.ModelBindingCommandHandler.InvokeAsync(InvocationContext context)
   at System.CommandLine.Invocation.InvocationPipeline.<>c__DisplayClass4_0.<<BuildInvocationChain>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass21_0.<<UseMiddleware>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass16_0.<<UseHelp>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass25_0.<<UseTypoCorrections>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Invocation.InvocationPipeline.InvokeAsync(IConsole console)
   at System.CommandLine.Parsing.ParseResultExtensions.InvokeAsync(ParseResult parseResult, IConsole console)
   at Microsoft.DotNet.Interactive.Commands.DirectiveCommand.InvokeAsync(KernelInvocationContext context) in D:\workspace\_work\1\s\src\Microsoft.DotNet.Interactive\Commands\DirectiveCommand.cs:line 35
   at Microsoft.DotNet.Interactive.Kernel.HandleAsync(KernelCommand command, KernelInvocationContext context) in D:\workspace\_work\1\s\src\Microsoft.DotNet.Interactive\Kernel.cs:line 261
   at Microsoft.DotNet.Interactive.KernelCommandPipeline.<BuildPipeline>b__6_0(KernelCommand command, KernelInvocationContext context, KernelPipelineContinuation _) in D:\workspace\_work\1\s\src\Microsoft.DotNet.Interactive\KernelCommandPipeline.cs:line 57
   at Microsoft.DotNet.Interactive.KernelCommandPipeline.<>c__DisplayClass6_1.<<BuildPipeline>b__3>d.MoveNext() in D:\workspace\_work\1\s\src\Microsoft.DotNet.Interactive\KernelCommandPipeline.cs:line 72
--- End of stack trace from previous location ---
   at Microsoft.DotNet.Interactive.CompositeKernel.LoadExtensions(KernelCommand command, KernelInvocationContext context, KernelPipelineContinuation next) in D:\workspace\_work\1\s\src\Microsoft.DotNet.Interactive\CompositeKernel.cs:line 162
   at Microsoft.DotNet.Interactive.KernelCommandPipeline.<>c__DisplayClass6_0.<<BuildPipeline>g__Combine|2>d.MoveNext() in D:\workspace\_work\1\s\src\Microsoft.DotNet.Interactive\KernelCommandPipeline.cs:line 70
--- End of stack trace from previous location ---
   at Microsoft.DotNet.Interactive.KernelCommandPipeline.SendAsync(KernelCommand command, KernelInvocationContext context) in D:\workspace\_work\1\s\src\Microsoft.DotNet.Interactive\KernelCommandPipeline.cs:line 42

Please complete the following:

Which version of .NET Interactive are you using? There are a few ways to find this out:

Version: 1.0.246201+da749355d416da20e634e5c80073b92356b57e0e Build date: 2021-09-12T06:21:44.0000000Z

• OS
  • [ ] Windows 10
  • [ ] macOS
  • [X] Linux (Please specify distro)
  • Docker using image mcr.microsoft.com/vscode/devcontainers/dotnet:0-5.0
  • WSL using : Distributor ID: Debian Description: Pengwin Release: 11 Codename: bullseye
  • [ ] iOS
  • [ ] Android
• Browser
  • [ ] Chrome
  • [ ] Edge
  • [ ] Firefox
  • [ ] Safari
• Frontend
  • [ ] Jupyter Notebook
  • [ ] Jupyter Lab
  • [ ] nteract
  • [ ] Visual Studio Code
  • [ ] Visual Studio Code Insiders
  • [ ] Other (please specify)

Screenshots

If applicable, add screenshots to help explain your problem.

Devcontainer

devcontainer.json

{
	"name": "C# (.NET)",
	"build": {
		"dockerfile": "Dockerfile",
		"args": { 
			// Update 'VARIANT' to pick a .NET Core version: 2.1, 3.1, 5.0
			"VARIANT": "5.0",
			// Options
			"NODE_VERSION": "lts/*",
			"INSTALL_AZURE_CLI": "false"
		}
	},
	"settings": {},
	"extensions": [
		"ms-dotnettools.csharp",
		"ms-dotnettools.dotnet-interactive-vscode"
	],
	"remoteUser": "vscode"
}

Dockerfile

ARG VARIANT="5.0"
FROM mcr.microsoft.com/vscode/devcontainers/dotnet:0-${VARIANT}

# [Choice] Node.js version: none, lts/*, 16, 14, 12, 10
ARG NODE_VERSION="none"
RUN if [ "${NODE_VERSION}" != "none" ]; then su vscode -c "umask 0002 && . /usr/local/share/nvm/nvm.sh && nvm install ${NODE_VERSION} 2>&1"; fi

# [Option] Install Azure CLI
ARG INSTALL_AZURE_CLI="false"
COPY library-scripts/*.sh library-scripts/*.env /tmp/library-scripts/
RUN if [ "$INSTALL_AZURE_CLI" = "true" ]; then bash /tmp/library-scripts/azcli-debian.sh; fi \
    && apt-get clean -y && rm -rf /var/lib/apt/lists/* /tmp/library-scripts

[jonsequitur]

What frontend are you using to connect to the kernel (e.g. VS Code, JupyterLab)?

[flytzen]

What frontend are you using to connect to the kernel (e.g. VS Code, JupyterLab)?

VS Code. Could this be something to do with how VS Code remotes into the container from Windows?

[jonsequitur]

I don't think so. I think the environment variable is not getting set correctly when the SQL Tools Service package is loaded:

https://github.com/dotnet/interactive/blob/5ab5eb709fec032a5bc9b2debfd3eccb81ae8887/src/Microsoft.DotNet.Interactive.SqlServer/ToolsServiceClient.cs#L24-L41

[flytzen]

@jonsequitur Do the SQL tools need to be installed into the docker container separately first and env var set? Or is it that #r "nuget:Microsoft.DotNet.Interactive.SqlServer,*-*" doesn't quite do what is needed?

[jonsequitur]

This package (well, its RID-specific dependencies, actually) carries the SQL Tools Service, so the #r "nuget:Microsoft.DotNet.Interactive.SqlServer,*-*" should bring it down as a dependency.

Looking into it a bit more closely, it looks like we didn't publish a package for the appropriate RID, and I'm wondering if there are others we need to publish as well. @KevinRansom?

https://docs.microsoft.com/en-us/dotnet/core/rid-catalog#linux-rids https://www.nuget.org/packages/Microsoft.SqlToolsService/

[colombod]

@KevinRansom this could be related to rods in the tool package, what do you think.