Fetch debugger port number from running game code

Hello,

Is there any way to fetch or calculate the debugger's port number from within the application's code?
Visual Studio > Attach Unity Debugger and the Profiler in the Unity Editor can fetch this port, how do they do it?

I am trying to show the debugger port in the title bar of the running standalone application. While debugging / profiling, often multiple running instances of the game are needed, and it is difficult to identify which running instance is the target for debugging or profiling since they cannot be differentiated from each other and matched to the list of processes in Visual Studio or the Profiler.

I found this thread, but the solutions mentioned here do not seem to apply. The port numbers I see are 55000 and upwards, while the calculation there is upwards from 56000. There also does not seem to be any usable log output. https://forum.unity.com/threads/uwp-il2cpp-debug-port-number.808776/

There was this thread also, but no response. https://forum.unity.com/threads/get-debugger-listening-port-from-code.776318/

Any help appreciated.

----

I have tried the following since posting:

- Enumerating all ports in use and matching associated PID to the application PID; there is no way to tell which port is the debugger port, I am left with multiple possible ports.

 

Thanks! I think I remember seeing something like this in the source code for the Unity extension for Rider.

It's unfortunate something as complicated as this is required just to get the debugger port from the process it belongs to. Would there be there interest in exposing this through e.g. Application or some other class? The debugger port is used between a couple of editor tools and it's very hard to match running instances to the list of instances in these tools (e.g. Profiler in the Unity editor does not report PID, and the extension in older versions of Visual Studio does not report PID either)

Something else concerning however is that I've noticed the Profiler in the Unity editor, and in the Visual Studio > Attach Unity Debugger menu report different ports for what should be the same running instance. Is one of these incorrect, or are there multiple possible debugger ports? If these are inconsistent this makes it much harder and perhaps impossible for me to show relevant information to help match running instances to the list of instances in both the Profiler and VS.

 

That's good to know! Does the Unity player broadcast the Profiler port in the same way?

Really appreciate it, thanks! It would definitely be useful for these to be exposed to the running process when available, or at the very least for the Profiler in the editor to report PID in addition to the port. I can ask people to update Visual Studio to see the PID and solve half of my problem, but that still leaves the Profiler only identifying running instances with the port and machine; to solve the problem here I would still need to write the entire listener.

 

Good to hear about those changes for 2021.2, that sounds like a good step forward. It would just take us a while to get to that early of a version since we're on LTS.

I wasn't aware player logs went there actually, we have different logs going out somewhere else and it looks like that's what I was looking at, so that's very helpful. I don't know if I can read this file from the player while the player is also writing to it (another user mentioned they could not do this), so I will have to experiment, but this sounds promising.

Otherwise, that source code looks a lot more useful than what I found, definitely a good reference for writing the listener if I have to, thank you.

Thanks for noting this in the backlog!

 

Hello again,
unfortunately I've been trying to get this multicast listener working, but it looks like calling IPInterfaceProperties.GetIPv4Properties() like the monodevelop code does (and all other code that does this) results in the application crashing immediately with nothing logged. This looks like it might be an issue with Unity?

I found this, but the symptoms are slightly different from me (I am using mono and not il2cpp, the crashes also happen in editor) on Unity 2020.3.6f1.
https://issuetracker.unity3d.com/is...etipv4properties-is-called-in-an-il2cpp-build

I can't seem to find a workaround for this so I am starting to think I'm blocked. Any advice is appreciated.

I cannot look at logs because when you run multiple build processes, player.log gets overridden.

---

Nevermind, it looks like I have it working, I switched from iterating nics to just passing IPAddress.Any instead of the nic index.

 

This exactly. It would help so much to just have the port in the title bar (or accessible from code so we can display it on the UI somewhere at least).
A more detailed list in the profiler or a compile-time set identifier won't help much if you run the same compiled game multiple times at once. Still need to open the log each time to identify which window uses what debugger port.

Any chance this could be added (i.e. either a way to show it in the window handle bar or allow fetching the port-number from within the game's code)?

 

I could not find any hint on where to set the EditorUserBuildSettings.managedDebuggerFixedPort.
I want to debug our server under a fixed port.

Would you tell me?

 

For the next person in line: The following script I put under Assets/Editor.

Code (CSharp):

1. using UnityEditor;
2. using UnityEditor.Build;
3. using UnityEditor.Build.Reporting;
4.  
5. namespace Editor {
6.   class BuildProcessor : IPreprocessBuildWithReport {
7.     public int callbackOrder {
8.       get { return 0; }
9.     }
10.  
11.     public void OnPreprocessBuild(BuildReport report) {
12.       EditorUserBuildSettings.managedDebuggerFixedPort = 50000;
13.     }
14.   }
15. }

 

By the way, I have noticed that it's common for Unity to advertise the wrong port. If you ever get stuck and can't figure out why MSVC won't connect to Unity, you can run TCPView (from Microsoft) and show what port Unity.exe is listening on. It's often NOT the same port MSVC is trying to connect to. This is after having first killing all the Unity and UnityHub processes and relaunching Unity and MSVC clean. In my case, I saw Unity connecting to 0.0.0.0:56190 and MSVC says:

No connection could be made because the target machine actively refused it 127.0.0.1:56188

Which is clearly wrong.