You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Look into the Debug.StartWithoutDebugging:5EFC7975-14BC-11CF-9B2B-00AA00573819, 0x170 command again.
The problem is that launching the process will lock its program files on the remote machine which will block any subsequent binary uploads for the program. One possible way to deal with this would be to create separate temporary directories for each program run by adding a GUID to the program name or something. The problem with this is that these directories could accumulate quickly. Perhaps we could try to purge these directories when we first establish a connection for this command. The trick is to recursively verify that no files are locked in the program directory and any directories before deleting the directory.
This could probably be scripted pretty easily using lsof command.
Look into implementing the Debug.StartDebugTarget (aka Attach...):6E87CFAD-6C05-4ADF-9CD7-3B7943875B7C, 0x101 command again. This should be doable; it just didn't seem critical for the first release.
Jim Mullis 12/24/2020: Although I can see Console.WriteLine() results in the VS2019 Output window while debugging my RPi console app, I'm not sure how to get input for Console.ReadLine(). During debugging no terminal window displays. What am I not doing correctly to accomplish this?
This may be possible by deploying the app code to the Raspberry, starting it in the terminal Window and then attaching to it with the debugger. This is worth a look when I get back to this. Perhaps we'd add a checkbox in the Raspberry Project Settings dialog to enable this.
We don't currently support HTTPS for ASPNET applications. The issue here is certificate management. Visual Studio looks like it creates a development certificate for localhost on the local workstation and adds this to the trusted certificates so debugging an ASPNET app running on this URL will work seamlessly. It may be possible to do something similar for ASPNET apps running on a remote Raspberry.
The text was updated successfully, but these errors were encountered:
Support .NET 5.0 after it ships
Look into the Debug.StartWithoutDebugging:
5EFC7975-14BC-11CF-9B2B-00AA00573819, 0x170
command again.The problem is that launching the process will lock its program files on the remote machine which will block any subsequent binary uploads for the program. One possible way to deal with this would be to create separate temporary directories for each program run by adding a GUID to the program name or something. The problem with this is that these directories could accumulate quickly. Perhaps we could try to purge these directories when we first establish a connection for this command. The trick is to recursively verify that no files are locked in the program directory and any directories before deleting the directory.
This could probably be scripted pretty easily using lsof command.
Look into implementing the Debug.StartDebugTarget (aka Attach...):
6E87CFAD-6C05-4ADF-9CD7-3B7943875B7C, 0x101
command again. This should be doable; it just didn't seem critical for the first release.Jim Mullis 12/24/2020: Although I can see Console.WriteLine() results in the VS2019 Output window while debugging my RPi console app, I'm not sure how to get input for Console.ReadLine(). During debugging no terminal window displays. What am I not doing correctly to accomplish this?
This may be possible by deploying the app code to the Raspberry, starting it in the terminal Window and then attaching to it with the debugger. This is worth a look when I get back to this. Perhaps we'd add a checkbox in the Raspberry Project Settings dialog to enable this.
We don't currently support HTTPS for ASPNET applications. The issue here is certificate management. Visual Studio looks like it creates a development certificate for
localhost
on the local workstation and adds this to the trusted certificates so debugging an ASPNET app running on this URL will work seamlessly. It may be possible to do something similar for ASPNET apps running on a remote Raspberry.The text was updated successfully, but these errors were encountered: