dotnet / interactive

.NET Interactive combines the power of .NET with many other languages to create notebooks, REPLs, and embedded coding experiences. Share code, explore data, write, and learn across your apps in ways you couldn't before.
MIT License
2.88k stars 382 forks source link

#!connect mssql fails on WSL and Linux #1602

Open flytzen opened 3 years ago

flytzen commented 3 years ago

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

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 commented 3 years ago

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

flytzen commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 2 years ago

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