Attach to process to a running process on a remote PC

I'm working on a C# application, which is running on a remote PC. I have a VPN connection and using an RDP session, I can login to that computer.

On that computer, next to the running process, there are also two "msvsmon.exe" processes, having the following "Command line" entry in task manager:

• C:\Program Files\...\Common\IDE\Remote Debugger\x86\msvsmon.exe
• C:\Program Files\...\Common\IDE\Remote Debugger\x86\msvsmon.exe /CHILDSERVER 428 "+:4022" {...}

(I suppose this means that the monitoring server is running and that the monitoring server is listening to port 4022.)

I have checked my application: the task manager clearly states that my application is 32-bit, so the x86 "msvsmon.exe" should be the good one.

On my local PC, I try to open a remote connection, but that seems not to work: I use the "Default" Connection type, but in the "Find ..." dialog box in the "Remote Connections" window, I have tried different possibilities:

• 10.39.50.50
• 10.39.50.50:4022
• Address:"10.39.50.10"
• Address:"10.39.50.10:4022"
• Address:"10.39.50.10":4022

=> after refreshing, all those attempts resulted in "Showing 0 of 0 connection(s)"

I have opened a Developer Command Prompt for VS 2017 and I've typed ping 10.39.50.10, which clearly showed results (this is normal as a I have an RDP session open to that machine).

I believe that remote debugging uses some other "communication channel" than regular TCP/IP, which means that I need to alter the communication between my local PC and that remote one, but which "communication channel" and which command can I use (next to ping) in order to check the availability of the communication?

Further debugging: I have created (and deleted afterwards) the mentioned firewall rule, but now I'm dealing with following error message:

Unable to connect to the Microsoft Visual Studio Remote Debugger
named '10.39.50.10:4022'.
The Remote Debugger was unable to locate a resource dll 
(vsdebugeng.impl.resources.dll).
Please ensure that the complete remote debugger folder was copied 
or installed on the target computer.  

Searching for this file on the remote computer gives following result:

C:\>dir /S /B vsdebugeng.impl.resources.dll
C:\Program Files (x86)\Microsoft SQL Server Management Studio 19\
Common7\Packages\Debugger33\vsdebugeng.impl.resources.dll

=> Why is that file not found?

(I've checked and the msvsmon.exe processes are running as administrator (Elevated="Yes"))

Apparently, you can't rely on the "msvsmon.exe" installation, based on SQL server management studio:

On my computer, Visual Studio is installed, and hereby I can find "msvsmon.exe":

C:\>dir /S /B msvsmon.exe
C:\...\Microsoft Visual Studio17\...\Common7\IDE\Remote Debugger\x86\msvsmon.exe

The resources library:

C:\>dir /S /B vsdebugeng.impl.resources.dll
C:\...\Microsoft Visual Studio17\...\Common7\IDE\Remote Debugger\x8633\vsdebugeng.impl.resources.dll

In other words: the "1033" (English locale) directory is stored under the "x86" directory where "msvsmon.exe" can be found.

On the remote computer, "msvsmon.exe" was installed under SQL Server Management Studio, which have another structure (which is wrong):

C:\>dir /S /B msvsmon.exe
C:\...\Microsoft SQL Server Management Studio 19\Common7\IDE\Remote Debugger\x86\msvsmon.exe

C:\>dir /S /B vsdebugeng.impl.resources.dll
C:\...\Microsoft SQL Server Management Studio 19\Common7\Packages\Debugger33\vsdebugeng.impl.resources.dll

Apparently, "msvsmon.exe" looks into the "1033" subdirectory in order to find the resource dll, so that entire directory needs to be copied:

C:\>dir /S /B vsdebugeng.impl.resources.dll
C:\...\Microsoft SQL Server Management Studio 19\Common7\IDE\Remote Debugger\x8633\vsdebugeng.impl.resources.dll
C:\...\Microsoft SQL Server Management Studio 19\Common7\Packages\Debugger33\vsdebugeng.impl.resources.dll

The one, found after the whole "1033" directory has been copied under the "msvsmon.exe" directory, solves the problem.

Extra information: where does the 1033 come from?

This URL mentions the link between Visual Studio's language setting and the value of the mentioned subdirectory.