Torizon .NET Core container not deploying

I’m very interested in trying to use .NET CORE with Torizon. I’m trying to go through the .NET CORE tutorial here .NET Core Development and Debugging on Torizon Using Visual Studio Code | Toradex Developer Center

I have installed Visual Studio Core, the C# extension for Visual Studio Code and the .NET Core SDK v3.0. I already have docker installed from using the same development PC with the Visual Studio 2017 integration with Torizon. I have downloaded the git repo from GitHub - toradex/dot-net-core: All files related to running .net core on TorizonCore.

I am able to build the container in Visual Studio code using the command “task builddebugcontainer” and I see this result:

    Successfully built a6098ff7d21c
    Successfully tagged dotnetcoredbg:latest

When I use the command “task deploydebugcontainer” it appears to work and I see the result:

Loaded image: dotnetcoredbg:latest

But I don’t see any contains on the module when I execute the command “docker ps -a” there.

If I then attempt to download and debug the demo application then I see this error:

> Executing task: ssh torizon@192.168.87.24 'docker stop dotnetcoreapp-dbg ; docker run -d --rm --name dotnetcoreapp-dbg -p 8023:22 -v $(pwd)/app:/app   dotnetcoredbg:latest' <

sh: docker stop dotnetcoreapp-dbg ; docker run -d --rm --name dotnetcoreapp-dbg -p 8023:22 -v $(pwd)/app:/app dotnetcoredbg:latest: No such file or directory
The terminal process terminated with exit code: 127

I think that Visual Studio Code is not actually deploying the container to the module. What should I check? I did edit settings.json to add the IP address of my module.

Greetings @MikeS,

The deploydebugcontainer task command as defined in that tutorial loads a container IMAGE onto the device, it has yet to actually run the image to create a container. So it should be expected that there are no running containers if you’ve only run the deploydebugcontainer task.

Try running docker images on the device to list the container images that are on the device.

As for your other issue with the debug. It seems that the error is related to the docker run command trying to mount a directory /app into the container, specifically this part -v $(pwd)/app:/app. Can you confirm the existence of such a directory on the device?

Best Regards,
Jeremias

Hi @jeremias.tx, ah ha! I do see the image on the module

colibri-imx7-06372679:~$ docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
dotnetcoredbg       latest              a6098ff7d21c        About an hour ago   307MB

There is no /app folder but there is a /home/torizon/app folder which contains lots of .NET DLLs. Should I try editing that command to be $(PWD)/home/torizon/app:/home/torizon/app?

@jeremias.tx if I enter this command in a bash terminal on my PC then it works correctly and returns a container ID:

ssh torizon@192.168.87.24 'docker run -d --rm --name dotnetcoreapp-dbg -p 8023:22 -v /home/torizon/app:/app dotnetcoredbg:latest'

But the same command from Visual Studio Code fails:

> Executing task: ssh torizon@192.168.87.24 'docker run -d --rm --name dotnetcoreapp-dbg -p 8023:22 -v /home/torizon/app:/app   dotnetcoredbg:latest' <

sh: docker run -d --rm --name dotnetcoreapp-dbg -p 8023:22 -v /home/torizon/app:/app dotnetcoredbg:latest: No such file or directory
The terminal process terminated with exit code: 127

That’s very curious.

@jeremias.tx that command only works from bash on my PC. If I run the same command from a Windows command prompt it fails. It turns out that Visual Studio core is attempting to run that command from a Windows command prompt. If I add bash.exe -c “” to the command in tasks.json then it will start the container. I think that might be a mistake in the template on GitHub.

Visual Studio Core now shows this error message, do you know what this means?

Starting: "ssh" -p 8023 -i ../dot-net-core-master/containers/dotnetcoredbg/id_rsa -oStrictHostKeyChecking=no root@192.168.87.24 "/root/vsdbg/vsdbg --interpreter=vscode"
-------------------------------------------------------------------
You may only use the Microsoft .NET Core Debugger (vsdbg) with
Visual Studio Code, Visual Studio or Visual Studio for Mac software
to help you develop and test your applications.
-------------------------------------------------------------------
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.
The program '[20] dotnet' has exited with code 145 (0x91).

I am using the id_rsa file which came from GitHub as I assume that is embedded inside the container. Or do I need to generate a new key pair to use with the container at this step?

To see if container is there you have to use:
docker images
this will return a list of images, docker ps returns a list of running containers.
Are you using a Windows PC? Do you have Windows Subsystem for Linux installed?
What happens if you try to ssh into the device? You should be able to do that without username and password.
If you can ssh into the device, can you try to run the command line there (the part between ‘’ in line 1).

Hi @jeremias.tx here’s another piece of information that might help. I used ssh to connect directly to the container using this command ssh -p 8023 -i ../containers/dotnetcoredbg/id_rsa -oStrictHostKeyChecking=no root@192.168.87.28, which shows that the container was created and is running.

Then I used to command dotnet --info inside the container and saw this reply:

  It was not possible to find any installed dotnet SDKs
  Did you mean to run dotnet SDK commands? Please install dotnet SDK from:
      https://aka.ms/dotnet-download

Host (useful for support):
  Version: 3.0.0-preview4-27615-11
  Commit:  ee54d4cbd2

.NET Core SDKs installed:
  No SDKs were found.

.NET Core runtimes installed:
  Microsoft.NETCore.App 3.0.0-preview4-27615-11 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

This message seems to be consistent with the error message from Visual Studio Code. Do I need to perform an extra step to install the SDK inside the container? I would have thought the debug container would already contain the SDK. I have already installed the .NET COre SDK 3.0 on my development PC.

Hi @valter.tx, thanks for replying to my question yesterday. I’ve been having a conversation with @jeremias.tx in the comments further down this topic. I think I’m very close to getting this going, but am stuck now with Visual Studio Core not being to debug the app (Details in the last comment at the bottom of the page)

You don’t need SDK in the container, it’s ok to have installed on the development PC.
You need to have the visual studio debugger there, but this should be already installed in the debug container.
Can you run docker ps on the device (not inside container)?
It seem that there is something strange about that container…
Can you also try to do:
docker pull mcr.microsoft.com/dotnet/core/runtime:3.0-stretch-slim-arm32v7
and then rebuild debug container?
Do you have firewalls or something else that may stop connections between device and dev PC?

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?

@valter.tx you also asked, “Are you using a Windows PC? Do you have Windows Subsystem for Linux installed? What happens if you try to ssh into the device?”

I am using a Windows PC running Windows 10, and I do have the WSL installed. I am able to connect to both the module and the container inside it using SSH on different ports.

I also have a VM with Ubuntu installed and I have considered installed Visual Studio Core there and testing the same sample application. I haven’t done that yet as part of the attraction of using .NET Core for me is being able to do all the development and debugging from Windows. Do you think it would tell us something useful if I repeated this test using Visual Studio Code from Ubuntu?

@MikeS,

So just to summarize your findings your application files got properly deployed to your device in /home/torizon/app. But they were not found in the /app folder inside the debug container. This is strange as the -v /home/torizon/app:/app argument of the docker run command mounts the application files into the container.

If you try to start the debugging process in Visual Studio Code, do you still get the following error?:

 sh: docker stop dotnetcoreapp-dbg ; docker run -d --rm --name dotnetcoreapp-dbg -p 8023:22 -v $(pwd)/app:/app dotnetcoredbg:latest: No such file or directory
 The terminal process terminated with exit code: 127

This original error seems to stem form /home/torizon/app not existing on the device but now it does.

Also you mentioned that you’ve had issues with Powershell vs the Windows Command Prompt. If possible could you try tracing the command sequence that is started when you begin debugging, as perhaps there are other weird shell issues.

The debug behavior in Visual Studio Code is defined by the ./vscode/launch.json file. According to this file it launches prepareuserkey command as pretask, with this command being defined in .vscode/tasks.json.

Based off of your original post with the error it seems to hit a snag at the restartdebugcontainer task.

Also have you tried rerunning the entire tutorial with your shell set to Windows Command Prompt instead of PowerShell?

We tested also on a Windows PC, even if not with the latest updates of vscode released just a few days ago.
We tested with cmd.exe as shell, you may set it as the shell for that specific project by adding:
“terminal.integrated.shell.windows”: “C:\Windows\System32\cmd.exe”
to settings.json in the .vscode subfolder of your project.

@jeremias.tx and @valter.tx I think I’ve made a lot of progress on this, your comment about the -v option failing to mount the app folder inside the container was the key to figuring it out.

I started with tasks.json from the template on GitHub: dot-net-core/tasks.json at master · toradex/dot-net-core · GitHub

Line 50 of that file is:

"command": "ssh torizon@${config:toradexdotnetcore.targetDevice} 'docker stop ${workspaceFolderBasename}-dbg ; docker run -d --rm --name ${workspaceFolderBasename}-dbg -p ${config:toradexdotnetcore.targetSSHPort}:22 -v $(pwd)/app:/app ${config:toradexdotnetcore.containerParms} ${config:toradexdotnetcore.containerParms_debug} ${config:toradexdotnetcore.containerTemplate_debug}:latest'",

The command above fails on my system. The first thing I changed was to wrap the command with bash.exe -c”” as shown below. Several of the other commands in this file use bash.exe when running on Windows and not when running on Linux, but this command does not for some reason.

"command": "bash.exe -c \"ssh torizon@${config:toradexdotnetcore.targetDevice} 'docker stop ${workspaceFolderBasename}-dbg ; docker run -d --rm --name ${workspaceFolderBasename}-dbg -p ${config:toradexdotnetcore.targetSSHPort}:22 -v $(pwd)/app:/app ${config:toradexdotnetcore.containerParms} ${config:toradexdotnetcore.containerParms_debug} ${config:toradexdotnetcore.containerTemplate_debug}:latest'\"",

That helped, but I found that $(pwd)/app didn’t seem to work (I think it should). This command also seemed to fail silently without writing anything to the console and it left an empty /app folder inside the container. I changed that to ~/app as shown below and it did start to work:

"command": "bash.exe -c \"ssh torizon@${config:toradexdotnetcore.targetDevice} 'docker stop ${workspaceFolderBasename}-dbg ; docker run -d --rm --name ${workspaceFolderBasename}-dbg -p ${config:toradexdotnetcore.targetSSHPort}:22 -v ~/app:/app ${config:toradexdotnetcore.containerParms} ${config:toradexdotnetcore.containerParms_debug} ${config:toradexdotnetcore.containerTemplate_debug}:latest'\"",

The output of the debugger is now (Notice the Hello World!):

Starting: "ssh" -p 8023 -i ../containers/dotnetcoredbg/id_rsa -oStrictHostKeyChecking=no root@192.168.87.28 "/root/vsdbg/vsdbg --interpreter=vscode"
-------------------------------------------------------------------
You may only use the Microsoft .NET Core Debugger (vsdbg) with
Visual Studio Code, Visual Studio or Visual Studio for Mac software
to help you develop and test your applications.
-------------------------------------------------------------------
Loaded '/app/System.Private.CoreLib.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
Loaded '/app/dotnetcoreapp.dll'. Symbols loaded.
Loaded '/app/System.Runtime.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
Loaded '/app/System.Diagnostics.Debug.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
Hello World!
The program '[21] dotnet' has exited with code 0 (0x0).

If I debug the app over and over again then it works most of the time, but occasionally it fails with the message below. I think I can live with this for now but thought you should know. Restarting the container for every debug session may not be necessary so I could edit tasks.json to avoid restarting the container in order to avoid this error.

> Executing task: bash -c "ssh torizon@192.168.87.28 'docker stop dotnetcoreapp-dbg ; docker run -d --rm --name dotnetcoreapp-dbg -p 8023:22 -v ~/app:/app   dotnetcoredbg:latest'" <

dotnetcoreapp-dbg
1623a017db1b07a78351b2a0c342dc0413dce4e7e7a9069fe11bce5cda9567e5
docker: Error response from daemon: OCI runtime create failed: container_linux.go:345: starting container process caused "process_linux.go:299: copying bootstrap data to pipe caused \"write init-p: broken pipe\"": unknown.
The terminal process terminated with exit code: 125

Thanks for your help and patience with this.

@MikeS,

I’m happy to hear it works for you now. Thank you for the testing and feedback on your side. It’ll help correct and improve our current tools and documentation.

Hi Mike,
thank you for sharing the information and the good news.
By adding “bash -c” to that command you switched from the standard ssh client provided by Windows 10 to the one in the WSL.
They provide the same functionality and that should not be an issue, but I will try to figure out why the ssh command behave differently on some PCs.
The console messages are mixed with the debug ones, it seems that currently the .NET core extension in VSCode has no way to split them :frowning:
We restart the container to allow the app to run in a clean and reproducible environment every time, usually this should not take too long and work reliably.
On what module are you testing it?
We may do some additional testing to make the system a bit more reliable.

If you have time, can you type:
ssh -V on a command prompt? Just to check if the ssh client is the same as the one of the PC we used for testing?
Here is:
OpenSSH_for_Windows_7.6p1, LibreSSL 2.6.4

@valter.tx I am using a Colibri iMX7D 1GB eMMC module. When I type ssh -V in a Windows command prompt I see the same version as you: OpenSSH_for_Windows_7.6p1, LibreSSL 2.6.4.

I also noticed that the console output of my application was mixed up with the debug information in Visual Studio Code in a way which didn’t look good. It looked quite a bit better when I added using System.Diagnostics and then used Debug.WriteLine("Hello World!") instead of Console.WriteLine("Hello World!").

Yes, the issue is that the remote debugger currently works over ssh and processes all the console messages as they are debugger-related. Unfortunately is not something we can change.