Kudos and Suggestions for Improvement #76
Description
Hello,
thanks for this VS extension. It is well designed (kind of "by-the-books") and superior to the others on the VS Marketplace which are claiming to do the same - without fulfilling these promises.
(e.g. the one from comfiletech runs 'dotnet publish' which - unconditionally - makes no sense and takes a long time and it also makes synchronous calls which are blocking the whole VS UI; the VsRemoteDebugger extension cannot even launch properly; and none of them seems to be able to do a differential deployment).
Nonetheless, I had a lot of trouble in getting it set up to work. I hope the following will be useful in order to further improve the user experience:
Unknown host name softworkz@1.2.3.4
I cannot reproduce this anymore, but that's the first issue I had (VS 2022). It somehow tried to connect to a host with the user name included.
Then I tried with VS 2026 (same configuration) and the error didn't occur there.
At some point I switched to the host name (like fedoravm.local) and with that I got rid of the error in VS 2022. fedoravm.local was the NetBios name of the VM. The confusing part was that it's been working just partially. It seems the extension is doing multiple things and it worked for one but not another.
After adding it to the hosts file on Windows, I got to the same point like on VS 2026:
Deployment was working but debugging always hung: It didn't launch the app and didn't engage the debugger. Just nothing happened and the logs didn't show anything.
RSA Keys
Then I tried to launch manually and attach manually with the VS debugger. But establishing the connection never worked in the VS Connection Manager dialog: Trying to connect led to the question whether I want to accept the host key, but clicking OK resulted in an error.
That's not directly the fault of your plugin, but a Visual Studio inconsistency/bug:
VS stopped accepting RSA keys in versions 17.10 and 17.11 and also - the documentation is wrong about that - in 17.12:
But even worse - and the docs do not say that - while 17.13 is allowing RSA keys again, it still doesn't accept a host key when you connect with an RSA client key. The only way I found for using an RSA key with VS remote debugging is to:
- Use an ecdsa key to connect via VS ConnectionManager
- Accept the host key (will succeed)
- Then you can change to an RSA key and it will work (since the host key is already accepted)
Takeaway
Don't even try using RSA keys - always use ecdsa keys only.
Suggestion
Update your documentation (and probably code) for key generation as documented by MS: ssh-keygen -m pem -t ecdsa -f <key-name>
Reason for "The Hang"
After fiddling around long enough (and a few other hurdles, see below) I got it working eventually, and from that moment on, everything was perfect and I've been very delighted about the quick deployments.
But then I wanted to set up another VM and it was hanging again. Since I didn't know what actually fixed it, I was back to zero. I tried to repeat all the things I had done before - which burned several hours of time again.
The Problem
Long story short: the hang was caused by the SSH client, asking about whether to trust the host key. In both cases I had successful ssh connections to the target from the command line, but unfortunately, ssh stops and waits for user input in many cases, even when you've trusted the host key already, like: When the IP address changes or when you have trusted the key for a connection via host name and then you are connecting to the ip address, or even when you've trusted via hostname but the underlying IP address changes.
No Logging
What makes all this really bad is that there's no log output which is showing that ssh.exe is asking about acceptance of the host key. What you see is just nothing and I just found out by experiment.
Suggestion 1
Add these parameters to the ssh command:
ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=NUL -o GlobalKnownHostsFile=NUL ...I even would make this the default (with an option to change.
Suggestion 2
Or make a test connection (Process.Start) with the same parameters that you are passing to the adapter. Kill it (or send CTRL-C) after a few seconds, so that you can cancel the debugging and show an error to the user.
The dotnet folder problem
You have that as an extension setting with a default of ~/.dotnet
That's a typical location for manual installs, but in case of Ubuntu (latest) - where dotnet is installed via system packages - the path is /usr/lib/dotnet and sometimes it can be /usr/lib64/dotnet or somewhere under /usr/share/....
The consequence is that when I switch between different targets, I always need to change that setting as well - it doesn't work otherwise.
Suggestion 1
Always just run dotnet without specifying a path.
Suggestion 2
If a path is needed, run dotnet --info - it tells you the right path.
Suggestion 3
If you think the path should be user-configurable, then it should be a property of the debug profile, not a global property.
EDIT: Sorry, just noticed this is possible already.
Finally
I have one more, but that would be more of the "sugar on top" kind than "onboarding woes".
Thanks again for this great extension!
sw