Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
When you attempt to connect to the soft debugger on the iPhone device, if your HostIP properties key is blank in your settings file (or possibly if MonoDevelop guesses the wrong IP), you will get a mysterious dialog box stating:
"Could not open port for debugger. Another process may be using the port."
1. It does not tell you which port is unavailable, so you don't know which port to check.
2. The error is incorrect. My problem was that my HostIP was blank in my settings file, not that the port was blocked.
3. There is no way in the MonoDevelop UI to set your debug port address or host IP, or even check it. This should be a settings in your project settings pages.
4. MonoDevelop should always use your primary internet connection port (the port which returns a valid response if you ping a well known public address).
I solved this problem by searching StackOverflow and the forums, inferring what was wrong, and going into my settings.xml file and editing it.
*** Bug 25 has been marked as a duplicate of this bug. ***
We just pick the first ip available on the machine.
But if we pick one particular ip, no matter how smart we try to be, there will always be cases where we pick the wrong one, so I suggest we just give all of them to the application. The application on the device can then try to connect to each ip, eventually it'll find the right one.
Adding a UI to manually specify the host ip can somewhat mitigate this, but there are issues (machines with DHCP needs periodic updates, you have machine-specific information in the project file so your co-workers will have to change it which will lead to everybody having different project files, etc).
We could do two things:
Issue the connect to all known IP addresses and select on those and pick the first one that responds.
Or we could try advertising the service with Bonjour and have the client try to find it.
The host IP should not be a project setting, since that would break other developers of the same project. Nor is is specific to individual projects - it would be IDE-wide. I did considered adding a user preference to MD to allow specifying an IP or a preferred network interface, but decided that a more robust solution would be one of the following:
1) have MD embed all the machine's IPs in the compiled app and listen on all of them, and have the app attempt to connect to all of them. This would no longer guess the wrong IP, but would still break if the host IP changed after compiling the app, or if there's a firewall between the host and the device.
2) Have MD embed the machine's MDNS name into the app, and have the app attempt to resolve it. This would fail if the host and device were not on the same subnet or had a firewall between them.
3) Reverse-engineer Apple's private MobileFramework APIs and tunnel a port from the device to the host. This would require a cable, and would break if Apple change their APIs.
Of course, for the most reliability we could do all three of the above. Unfortunately they're not easy to implement correctly, which is why we haven't done them yet.
The specific bug here is not just that it fails to connect, but that it fails to open the port (and also gives you an unhelpful error message which doesn't tell you what IP address/port it was trying to open when it failed).
In other words, the code seems like it's using a blank string as the IP address to try and open the port, and getting a socket error. The settings property in my MonoDevelopProperties.xml file was blank, and that could possibly have been the cause of the unable to open port error.
Once I set the IP manually, not only did the port open, but the debugger connected, and everything worked fine.
Yes, seems likely we don't give the correct error message when the property exists but is empty. Ordinarily the property should not be there at all, and it is never modified by MD. It was provided as a temporary manual workaround for MD not using the correct address.
(In reply to comment #4)
> 1) have MD embed all the machine's IPs in the compiled app and listen on all of
> them, and have the app attempt to connect to all of them. This would no longer
> guess the wrong IP, but would still break if the host IP changed after
> compiling the app, or if there's a firewall between the host and the device.
I think this would be a good start, I can try to fix it.
> Of course, for the most reliability we could do all three of the above.
> Unfortunately they're not easy to implement correctly, which is why we haven't
> done them yet.
Unless I'm missing something I can't see why connecting to several ips is much harder than just connecting to one?
> Unless I'm missing something I can't see why connecting to several ips is much
> harder than just connecting to one?
It requires coordinating changes in a few places.
1) Modify MD's debugger session to support listening on all multiple IPs.
2) Have MD embed the IPs in the app bundle in a way understood by MT. Bad idea to keep using the settings plist once it's an unbounded list of values. It was useful for users who need to override the IP on the device, so we could still provide the settings plist but leave its values empty.
3) Have MT read the list of IPs and attempt to connect to them all. This needs to be done in parallel - the watchdog means startup time is critical, so we can't afford to wait for timeouts. We could also try to use bonjour to resolve the host's mdns hostname - I verified that mdns on a device can detect a host - but this would be tricky to do in the startup path.
MT will now try to connect to all IPs of the mac. The support requires MonoTouch 4.0.5 and MonoDevelop 2.6 beta 4, soon to be released (you'll need both updated for this new support to work).