search

SuessLabs / VsLinuxDebug

VS Extension to remotely deploy and debug your .NET (Core) C# solutions directly to your Linux or Raspberry Pi devices! .NET Core 3.1, .NET 5, 6, 7, 8, 9
https://marketplace.visualstudio.com/items?itemName=SuessLabs.VSLinuxDebugger
MIT License
38 stars 9 forks source link

Live update of GUI project #44

Closed HakanL closed 1 year ago

HakanL commented 1 year ago

I'm using the VsLinuxDebug extension to develop a Platform Uno project running on a Raspberry Pi. My workflow is that I build code in VS2022, make sure it runs under WinUI (switch start project), then I push it to my RPi for further testing/debugging. In this workflow it would be great with two features:

  1. Be able to control which project is pushed to my RPi. There are many times I've accidentally deployed the Windows project since I forgot to switch the startup. A setting would be good, or maybe a flag in the csproj that would skip my non-Linux project.
  2. In my current workflow I have to have a SSH open to the RPi (it has a screen, but no keyboard/mouse) and after each VsLinuxDebug deploy I kill the app (Ctrl-C in the SSH session) and then launch it again (dotnet App.dll). This works fine, but what would be very neat would be a form of "live push" where the app would be killed and re-launched automatically. I'm not sure exactly how this would be implemented. Or if VsLinuxDebug could launch the app after deploy (killing the previous instance), that way I wouldn't even need the SSH session (but I also use it to see console messages, so this is less of a need for my case.

Maybe it could be crafted with a "runner script" that would watch for modified files?

DamianSuess commented 1 year ago

To answer item no. 2, this feature is currently in beta testing (see, #37 Deploy and Launch in GUI) and has been merged into develop. As it goes with Linux distros/environments, "when it works, it works well". There's still more testing that needs to be done.

DamianSuess commented 1 year ago

To properly track the multiple feature requests, I've split them apart as separate tasks on the backlog.

The first request has been put into the backlog task board for consideration of a future release. The second request is being tracked as #37 (experimental feature) and #49 (release feature) in the backlog as well for v2.x.

Closing the issue.

HakanL commented 1 year ago

@DamianSuess Please let me know if you need help testing any of these features.

DamianSuess commented 1 year ago

@HakanL thank you for the offer, go for it!