I have a dotnet app, which I'm running on a Raspberry PI. I don't have a way to run full-fledged IDE on it, like Visual Studio or Rider. I run it on Raspberry PI with dotnet run. Since the app depends on some Raspberry PI hardware specifics, I cannot run it anywhere else.
I noticed that sometimes the app gets stuck somehow and the logs are no longer being generated. How can I find out which place in my code is the place where runtime is stuck? I don't see any exceptions. I can't even exit the app with SIGINT. I have to kill -9 it.
You can publish your application in Debug configuration and use remote debugging via SSH (first of all you need to configure SSH on raspberry). More information here: https://learn.microsoft.com/en-us/visualstudio/debugger/remote-debugging-dotnet-core-linux-with-ssh?view=vs-2022
Related
I'm running a .Net 7 application on a Raspberry Pi running the .Net 7 runtime and SDK.
The application runs fine, but as soon as I attached the remote debugger in Visual Studio 2022 I get a segmentation fault, with no indication of what caused it. I have increased the logging to the maximum.
The only error I receive is on the Pi itself 'Segmentation Fault' and an immediate exit with Visual Studio reporting nothing.
To fault find I've run and attached the debugger to a new test application which rules out the Pi and my PC, so I know its my application, I've also tried it on another Pi.
I then stripped back the code in my application to try and see what is going on and rule out hardware, ethernet comms and serial comms. I find that if I disable my Hosted Services in my Startup.cs file, that the debugger does attach to the application, but this is catching issues because things aren't initialised, so doesn't really load fully.
My application communicates with a sensor via serial comms, uses the GPIO on the Pi and uses SignalR to stream data to a front end. I don't think these are causing the issues, but I don't know for sure.
Are there any tools, or logs I can look at to try and solve this issue?
Resolved by reverting to .Net 6 as the workaround stated in this issue.
https://github.com/dotnet/runtime/issues/81921
.Net 7 and 32bit Linux-arm aren't working for remote debugging.
I am using Visual Studio Community 2022, and I was wondering if you could use another CLI to run/debug a c# console application. (I can't use cmd.exe or powershell because it's blocked by the admins of the device I'm using). Git Bash would be preferred, because it's already installed. Thank you!
Edit: Looks like you can't do this. dotnet run just tries to open the blocked binary, no matter where you run it. I think the admins hate everyone though because they allow you to install lots of things (like Unity, vscode, etc.) but running anything just doesn't work.
Thanks for trying everyone!
use this to run your program in CLI but you cannot debug it if you want to debug use debugger mode of vs2022,
If it's a framework-dependent application (the default), you run it by dotnet yourapp.dll.
Run the project in the current directory:
dotnet run
check Microsoft Docs dotnet run for more options.
CLI: Use Vs2022 Terminal in View->Terminal it may help You to run it.
I'm trying to debug remotely an application that's being hosted on Linux
"Debian GNU/Linux 8 (jessie)"
with
.NET Command Line Tools (2.1.500)
I'm connecting via Visual Studio via SSH
and I've tried both modes:
Managed .NET Core for Unix
Native (GDB)
Project has been compiled on Windows
dotnet publish --configuration Release -r linux-x64
and also
dotnet publish --configuration Debug -r linux-x64
and works perfectly fine, but for some reason I'm receiving:
Managed .NET Core for Unix:
Fail to attach to process: Unable to enumerate running instances of the CoreCLR in the specific process
And if that's relevant (probably not, because other people use Managed .NET Core for Unix for that)
Native (GDB):
Unable to start debugging. Unable to estabilish a connection to GDB. Debug output may containt more information
debug information:
Starting unix command: 'gdb --interpreter=mi'
bash: gdb: command not found
gdb --interpreter=mi exited with code 127.
In Visual Studio process is listed as:
Process: MyProjectName
Title: /home/deploy/app/MyProjectName StartUpArgument
Anybody has an idea what can cause that?
You can see how people do that with Raspberry Pi here:
https://youtu.be/ySzTCl-H10w?t=955
What ste
Step 1
Step 2
Step 3
Step 4
Step 5
Apparently our stupidity is limitless
We've been running our app as a service but FROM OTHER USER ACCOUNT THAN WAS USED IN SSH
Connecting to process works properly, but for some reason
Breakpoint will not currently be hit. No symbols have been loaded for this document
edit:
Solution:
https://developercommunity.visualstudio.com/content/problem/97445/vs2017-the-breakpoint-will-not-currently-be-hit-no.html
I also checked:
Enable source link support
Fall back to git credential manager auth. for all source link requests
Enable source server support
Enable just my code [OFF]
I'm getting an error trying to use the Docker functionality with my .NET core 2.0 project. I've been getting an error message saying
Visual Studio Container Tools requires Docker to be running before
building, debugging or running a containerized project. For more info,
please see: http://aka.ms/DockerToolsTroubleshooting
I followed the link, and upon realizing I have Windows 10 Home x64, and had to install Docker Toolbox, instead of Docker For Windows. Now it installed this executable called
Docker Quickstart Terminal
Is this the way one is supposed to start up that docker services? I have tried running this executable, and it seems to be working. My containers are running, but the error for Visual Studio Container Tools still persists.
What am I missing? Is having a version of windows higher than Home required in order to use the Docker Container Support within Visual Studio 2017?
UPDATE:
I tried to follow Quetzcoatl's suggestion, and I am still getting the same error within visual studio about those tools. Here is what I ran in the Docker Quick Start Terminal. I tried building the project after Visual Studio successfully opened the project, and was still getting the aforementioned error regarding the container tools.
My devenv.exe file is located at
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\devenv.exe
and my solution file is located at
D:\Development\Visual Studio\Musify2\Musify2\Musify2.sln
UPDATE 2:
I ran some of the suggested commands to try in the docker quickstart terminal and here were the results of those commands quetz
With Docker Toolbox that's a little tricky, but actually the core-2.0 has nothing to do here. It's all about docker, docker-toolbox, and VS.
First of all:
Is this the way one is supposed to start up that docker services? I have tried running this executable, and it seems to be working.
Yes it is. If docker machine/services are running - that's good!
Now, you have to realize that in docker, typically, the information about how/where the docker is running is kept in environment variables. The quickstart script not only starts the docker-machine for you and checks some basic things, it also sets up a couple of environmental variables so that later all commands like docker, docker-compose etc know where to look for the docker virtual machine. In your/our case that information mainly consists of an IP of the VM and a port number that Docker listens on.
.. and your Visual Studio has no knowledge of that, because, I bet on that, you have ran the VisualStudio from StartMenu or from Desktop icon or by double-clicking on a solution file, so it had no chance of getting the environmental variables from quickstart console.
The solution is quite simple: make sure that VS gets that information. That is, make sure it gets that environmental variables, and make sure that it gets the fresh state of them, because the IP/port may fluctuate sometimes. So don't just copy them to your OS settings, because nothing will ever automagically refresh them..
The simplest way I found is to just close Visual Studio, run docker toolbox quickstart console, then run the VisualStudio from within that console, for example, for my VS2017 Community Edition:
Starting "default"...
(default) Check network to re-create if needed...
(default) Waiting for an IP...
(.......snip..........)
## .
## ## ## ==
## ## ## ## ## ===
/"""""""""""""""""\___/ ===
~~~ {~~ ~~~~ ~~~ ~~~~ ~~~ ~ / ===- ~~~
\______ o __/
\ \ __/
\____\_______/
docker is configured to use the default machine with IP 192.168.99.100
For help getting started, check out the docs at https://docs.docker.com
Start interactive shell
quetzalcoatl#LAP049 MINGW32 ~
$ /c/Program\ Files\ \(x86\)/Microsoft\ Visual\ Studio/2017/Community/Common7/IDE/devenv.exe C:\\PATH\\TO\\MY\\SOLUTION.sln
The path is pretty long to write, even with TAB-completion, so usually make a tiny .sh script to run that for me.
BTW! Notice that the path to DEVENV must be unix-like (/c/Program\ Files...), because the mingw shell has to understand that, while the path to SOLUTION must be a normal windows path (c:\projects\foo\bar\..) because VisualStudio will try to read that after starting up.
This is what I did to get vs 2017 working on windows 10 home with docker-toolbox. You follow this and i guarantee it will work. Note this only applies to windows 10 home which doesn’t support native docker for windows application:
Install docker-toolbox on w10 home
Run docker QuickStart terminal once to create the docker-machine. It takes a while. So be patient while it assigns the IP address and other things
Once it’s done it will show you a command prompt. Type ‘docker-machine ip default’. Note down the ip address as you’re gonna need it later
Close the QuickStart terminal window. That was just to initialize the boot2docker.iso image of a tiny Ubuntu linux server into virtualbox app (aka docker-machine aka default vm). If you’re not familiar with virtualization technology or oracle virtualbox stop reading and read up on them first and then start over. But if you do then gladly continue
As I mentioned that your docker-machine instance is a Linux vm and therefore it’s obvious that you can only open projects built using .net core technology. Unfortunately for full .net framework you’ll either need to run Windows containers which are only available on windows 10 pro or build your own windows nano server or 2016 server vm on virtualbox and then use and follow steps for native docker for windows on dockers website. From here on the remainder of this answer will be helpful to those wanting to run core projects on Linux vm / docker-machine only
Open windows power shell in administrator mode and type ‘docker-machine ls’ to confirm that default vm is running. Can also do ‘docker-machine status default’ and it should return ‘running’
Now open virtualbox application which is running your default vm and click on settings. Open “shared drives” tab where you need to make sure ‘c:\Users’ folder on the host machine is mapped/mounted as ‘c/Users’ folder in the vm. Note that this step is super important and missing it will cause a lot of trouble getting it to work successfully
Also a quick note that your solution/project/codebase MUST be saved under ‘c:\Users\‘ for it to work correctly. This is if you want to use it OOTB. I didn’t wanna waste time trying to mount a folder outside the permitted path. But if you’re the adventurous kind, please, by all means try to figure it out and let us know how you did
Now as Quetzalcoatl correctly mentioned vs needs to know about this docker-machine. The only way that happens is if the environment variables are set. Therefore go ahead and run this command ‘docker-machine env default | Invoke-Expression’ in the powershell window. This is the magic sauce getting vs to behave nicely with docker-machine
Go ahead and open vs normally either by dbl clicking your project solution or creating a new project/solution. In Powershell use the 'start' command to open your existing vs solution or a new vs instance. Pro-tip: if you create a new solution DO NOT select the option of Linux docker at the time of picking the project template type. You can totally add docker support once your solution is all setup and ready to go. Matter of fact leave it unchecked and let vs create your solution. This way you’ll get a chance to build and run your solution in IIS Express or Self-hosted modes to see if your core2.0 even works properly
Once satisfied that everything worked and you saw the OOTB homepage now it’s time to add docker support by rt clicking on your project, hovering over Add and then clicking on ‘Add Docker Support’. This will create a new docker project (.dcproj) and add a bunch of docker related files
Now I’m not gonna go into the nitty gritty of docker here however you’ll notice that your project is no longer the startup and the newly created docker project is. That’s perfectly normal and intended behavior. It means you’re setup and ready to fire up your app using docker containers. So go ahead and click on the ‘Docker’ button to see your hard work finally pay off. Again be patient as it takes a while to build images and spin up containers but once it’s done the vs will start and attach the debugger
Here you’ll once again be disappointed and feel worthless because when the browser opens a new window or tab there’ll be a page unreachable error. The reason is the browser address points to localhost which is not the web server anymore. Your “web server” now is your docker container and therefore you’ll need to replace localhost with the IP address you retrieved above. Port number remains as it is. Once you submit the page you’ll be relieved and ecstatic to see the home page/route work. This should also enable debugging in vs. if for some reason it doesn’t then you may need to delete a folder called .vsdbg in c:\Users\ folder and rerun the application.
I'm trying to make application that would take a picture using web-camera on Raspberry PI running Windows IoT. The problem is that I can't find console app template.Universal Windows blank app template provides me with GUI but I'm going to call this app from python script so it should be without one.
Windows IoT projects provide background task template but the output is .winmd file and I cant execute it from python neither.
What is the way to create simple console app in Windows IoT using c#?
Thanks
Console applications are supported in Windows IoT but apparently in C++ only. Perhaps you could try to create a solution that has a very simple C++ console application that just handles interaction with the user plus a C# class library with all the logic and hardware related code.
Seems to works with a standard c# console apps. How I found out?
I used Reflector and examined all exe files in c:\windows\system32 on the Pi, and one was a .NET assembly: netcmd.exe
When I look at netcmd.exe in Reflector, it says it's build with standard .NET 4.5, this can't be right? But I made a standard c# console app with framework 4.5, added this:
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Hello world");
}
}
put the test.exe on the Pi, and voila:
C:>test
Hello world
Weirdest thing.
I haven't tested more than this, but I imagine You get into trouble with unimplemented API's since only a subset of .NET (same as in Background Application (IoT)?) exist on the Pi, so you must "manually" take care not use unimplemented stuff (or code most in Background Application "mode", and in the final stage, move to standard .NET 4.5 and add the console code).
If you still wish to move forward using C#, it may be sufficient to create the application as a blank Universal Windows Platform application as 1.) The UI will not be instantiated if the RPi2 is powered on without a connected HDMI cable 2.) You may find it useful to use the included UI as a means of live-debugging your application.
If you use your Win 10 device for a single (or multiple) app that all do not need a GUI, (eg for service apps only), you can boot the device with the headless option.
This boots without the whole UI with an extra resource bonus., buts still can be accessed over the network.
display the current state of your device, use the setbootoption utility:
[192.168.0.243]: PS C:\> setbootoption.exe
To modify the state of your device to enable headless mode, use the setbootoption utility with the headless arg:
[192.168.0.243]: PS C:\> setbootoption.exe headless
[192.168.0.243]: PS C:\> shutdown /r /t 0
To modify the state of your device to enable headed mode, use the setbootoption utility with the headed arg:
[192.168.0.243]: PS C:\> setbootoption.exe headed
[192.168.0.243]: PS C:\> shutdown /r /t 0
The device will start up with a black screen.
I was able to create .NET core (3.1 in my case) console app running under Windows 10 IoT:
Create a .net core console app and publish it to a folder
Connect to the device in windows explorer (or ftp) with 10.0...\c$
Create a folder in c:\program files\dotnet
Download an arm 32 dotnet core runtime (for example https://dotnet.microsoft.com/download/dotnet-core/thank-you/runtime-aspnetcore-
3.1.2-windows-arm32-binaries) (note I've used a raspberry pi 4)
Unpack it inside the folder at point 3
Open a powershell terminal to device (https://learn.microsoft.com/en-us/powershell/scripting/getting-started/getting-started-with-windows-powershell?view=powershell-7)
In powershell add the dotnet path to path env variable:
$Env:Path += ";C:\Program Files\dotnet\"
Check dotnet is available with:
dotnet --info
Finally copy your application output (publish folder) over the device
You should be able to run:
dotnet .\myapp.dll