Unable to connect to Kusto

[TylerLeonhardt]

Describe the bug

Please provide as much information as you can.

Please complete the following:

Which version of .NET Interactive are you using? (In a notebook, run the #!about magic command. ):

• OS
  • [ ] Windows 11
  • [ ] Windows 10
  • [x] macOS
  • [ ] Linux (Please specify distro)
  • [ ] iOS
  • [ ] Android
  • Browser
  • [x] Chrome
  • [ ] Edge
  • [ ] Firefox
  • [ ] Safari
  • Frontend
  • [ ] Jupyter Notebook
  • [ ] Jupyter Lab
  • [ ] nteract
  • [ ] Visual Studio Code
  • [x] Visual Studio Code Insiders
  • [ ] Visual Studio
  • [ ] Other (please specify)

Screenshots

If applicable, add screenshots to help explain your problem. (removed private data)

[jonsequitur]

What version of VS Code and Polyglot Notebooks are you using?

[TylerLeonhardt]

Polyglot: v1.0.4153011

VS Code stuff:

Version: 1.77.0-insider (Universal) Commit: 0cab3cc3cbe4d4ac2cbf30e8c30351d9db6dcfb4 Date: 2023-03-06T05:21:07.151Z Electron: 19.1.11 Chromium: 102.0.5005.196 Node.js: 16.14.2 V8: 10.2.154.26-electron.0 OS: Darwin arm64 22.3.0 Sandboxed: Yes

[brettfo]

@TylerLeonhardt The Kusto connector installs a dotnet global tool to do its work, can you run this dotnet tool list --global and check the version of microsoft.sqlserver.kustoservicelayer.tool? I'm hoping to see 1.2.0. Similarly for microsoft.sqlserver.sqltoolsservicelayer.tool.

[TylerLeonhardt]

I see just:

microsoft.sqlserver.kustoservicelayer.tool      1.2.0        MicrosoftKustoServiceLayer

[corivera]

Are you able to run MicrosoftKustoServiceLayer by itself in a command prompt? It should be getting added to the PATH, since it's installed as a global tool.

[TylerLeonhardt]

looks like it in my terminal in vscode.

[corivera]

There have been other issues with the tools not showing up properly on the PATH. I'll add the full Kusto tool path to the services and see if that resolves the issue.

[TylerLeonhardt]

@jonsequitur and I sat down, the fix, for me, was the set my Environment.CurrentDirectory to the dotnet tools directory and things started working.

[corivera]

Is $env:USERPROFILE/.dotnet/tools present in the PATH on that machine?

[jonsequitur]

$USERPROFILE/.dotnet/tools, no. $USER/.dotnet/tools, yes.

[corivera]

What does $USER resolve to here? It's not defined on my machine Never mind, didn't see that this was originally for Macs. The Windows paths in the exception were confusing.

[jonsequitur]

Yeah, that Win32Exception is always a fun vestigial name to find on Linux and Mac.

[corivera]

So the tools directory is in the PATH, but the tool can only be found if you're working in that tools folder?

[jonsequitur]

The tools directory is in the path but the extension isn't calculating the path correctly on macOS. It expands the unknown $USERPROFILE variable as an empty string, resulting in the extension looking for MicrosoftKustoServiceLayer in the current directory (which was the Downloads directory in @TylerLeonhardt's screen shot). This is why changing the working directory to the tools directory was an effective workaround.

[corivera]

What specific part do you mean by "extension" here?

[jonsequitur]

Microsoft.DotNet.Interactive.Kql. Presumably Microsoft.DotNet.Interactive.SqlServer has the same problem.

[corivera]

We aren't using USERPROFILE in those, though. We just use the tool name as the path for the process to start. So it currently would rely entirely on what's in the PATH (unless I'm misunderstanding something here). This is where we pass the service path to the KQL command. It gets passed through, unmodified, to ProcessStartInfo eventually in ToolsServiceClient. https://github.com/dotnet/interactive/blob/main/src/Microsoft.DotNet.Interactive.Kql/KqlKernelExtension.cs#L20