Debugging .NET Core 3 applications on PLCnext

Print

The PLCnext community recommends to use .NET Core 3 with PLCnext. To do this you need VS 2019.
You need to switch off Globalization for your PLCnext project, which I did in .csproj by:

ItemGroup Globalization

Compiling with VS 2019 and uploading with WinSCP is straight forward then.

But debugging does not work, so that I did some re-engineering to get debugging running.

For the remote debugging on the PLCnext you need to “attach to process” in the Debug menu.
During this attach by ssh, VS 2019 changes to the home directory (cd ~) and creates a directory .vs-debugger . VS 2019 stores a script GetVsDbg.sh into .vs-debugger. This script will download the arm version of vsdbg, the debug counterpart for VS 2019. The debugger is stored in a further directory vs2017u5 . If everything is successful, VS 2019 stores a file success.txt in vs2017u5.

vs debugger

Since the script GetVsDbg.sh does not run on PLCnext , we need to do the related steps above manually.

First create the .vs-debugger directory in your home directory (cd ~). Download https://aka.ms/getvsdbgsh and store it in the .vs-debugger directory. Create the directory vs2017u5 in .vs-debugger.

Download the debugger ZIP manually from https://vsdebugger.azureedge.net/vsdbg-16-0-20412-1/vsdbg-linux-arm.zip. Unzip the content to subdirectory vs2017u5. Make vsdbg executable with chmod +x vsdbg.

vsdbg itself is a .NET application, for which globalization needs to be turned off again. Please enter “export DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=true” for testing. Make a test and start “./vsdbg “ manually which shall show (gdb) in the last output line. Stop gbd with CTRL-C.

VS 2019 will rewrite GetVsDbg.sh each time and when started by VS 2019 the variable DOTNET_SYSTEM_GLOBALIZATION_INVARIANT is not set in the script. I solved this by renaming vsdbg to vsdbg2 and created a vsdbg (without extension) with:
               echo $*
               echo $* >~/vsdbg.txt
               export DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=true
               ~/.vs-debugger/vs2017u5/vsdbg2 $*
Make the new vsdbg executable by “chmod +x vsdbg”. Test again.

Create success.txt with the text “16.0.20419.1”. By this the script GetVsDbg.sh detects that the download of the debugger vsdbg was successful and will not try to (unsuccessfully) download again.

Switch to .vs-debugger and try “sh GetVsDbg.sh -v vs2017u5 -l ~/.vs-debugger/vs2017u5 -d vscode”, which shall show

getvsdbg

Stop with ^C.

To show the available tasks VS 2019 issues the command “ps -axww -o pid=A,ruser=B,args=C”, but PLCnext only has busybox for the ps command which does not include the needed switches of ps.
Rename ps to ps-old in /bin.

Fortunately it is possible to use the Debian ps on the PLCnext: https://packages.debian.org/de/jessie/armhf/procps/download and https://packages.debian.org/jessie/armhf/libprocps3/download . You can open the .deb files with 7zip and you will find ps in bin and libprocps in lib. On PLCnext please copy ps to /bin and libprocps.so.3 to /lib. Finally do “ln -s libprocps.so.3.0.0 libprocps.so.3” in /lib. Make ps executable with chmod +x ps. Try that “ps -axww -o pid=A,ruser=B,args=C” works now.

You are now ready to debug with VS 2019 on PLCnext!

Start your .NET Core 3 application on PLCnext.

First create a remote connection in VS 2019 connection manager by SSH.

Connection

Go to the debug menu and attach to process. In the dialog connect by ssh and filter “dotnet” in the processes shown. If asked, select managed .NET application.

Attach

Finally attach to the dotnet process. It takes a moment until all DLLs with debug information are loaded.

Enjoy 😊

 

If you want to debug your application right from the beginning you may use the following code:

WaitDebugger