Hi @valter.tx,
The result from running docker ps
on the module is:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
7d6d8ebb7892 dotnetcoredbg:latest "/usr/sbin/sshd -D" 25 seconds ago Up 22 seconds 0.0.0.0:8023->22/tcp dotnetcoreapp-dbg
The result from running docker pull mcr.microsoft.com/dotnet/core/runtime:3.0-stretch-slim-arm32v7
inside the dot-net-core-master\containers\dotnetcoredbg
folder on my development PC is:
3.0-stretch-slim-arm32v7: Pulling from dotnet/core/runtime
Digest: sha256:92ea8068e0afd8794de158aea825c07b5297a0dce0bbf453d213cb99b492292b
Status: Image is up to date for mcr.microsoft.com/dotnet/core/runtime:3.0-stretch-slim-arm32v7
mcr.microsoft.com/dotnet/core/runtime:3.0-stretch-slim-arm32v7
It looks like the container was already up to date. I rebuilt the debug container just to be sure, with the result:
Successfully built de5da5be5d0e
Successfully tagged dotnetcoredbg:latest
Then I deployed the debug container with the result:
Loaded image: dotnetcoredbg:latest
Then I deployed the app with the result:
sending incremental file list
app/dotnetcoreapp.deps.json
app/dotnetcoreapp.runtimeconfig.json
sent 3,981 bytes received 295 bytes 2,850.67 bytes/sec
total size is 65,210,671 speedup is 15,250.39
Then I tried to debug the app from Visual Studio Code but I still have the same error:
Error from pipe program 'ssh': It was not possible to find any installed dotnet SDKs
Error from pipe program 'ssh': Did you mean to run dotnet SDK commands? Please install dotnet SDK from:
Error from pipe program 'ssh': https://aka.ms/dotnet-download
The target process exited without raising a CoreCLR started event. Ensure that the target process is configured to use .NET Core. This may be expected if the target process did not run on .NET Core.
When I look inside the container on the module I can see the debugger is present as the executable file \root\vsdbg\vsdbg
. That folder also contains lots of other files including .det DLLS and a file called version.txt which contains the text 16.2.10709.2 commit:d18411016e7da314dd58c44a4828778b19665cc3
.
The module also contains a folder called \app
inside the container which is empty. Should that folder contain a copy of the app which was deployed by Visual Studio Core?
The module contains a folder outside the container called \home\torizon\app
which does contain the app and a set of DLLs which were deployed there by Visual Studio Code. Should part of the script be copying those files to a folder inside the container before trying to run the debugger?
Regarding firewalls, the development PC and the Colibri module are directly connected to the same network switch and are on the same subnet. I am able to connect from the development PC to the module using SSH on port 22, and I can also connect from the development PC to the container on the module using SSH on port 8023. Is there another port number that I should test? I did try completely switching off the firewall on my development PC but it didn’t make a difference.
One thing I did notice is that Visual Studio Code started with the default shell set to PowerShell, but the scripts that came from the Toradex example code won’t run in PowerShell so I changed the default shell to the Windows Command Prompt, which allowed the scripts to run. There is a third shell option in Visual Studio Code: WSL Bash, but the provided scripts won’t run in that shell either. Should I be using a specific shell with Visual Studio Code?