The version of Xamarin.iOS (184.108.40.206) that includes the fix has now been published to the stable channel.
Here is a Xamarin.iOS installer build that includes a candidate fix for the Mac build host. This has solved the problem for at least 6 different users. Please keep in mind that this build has only been lightly tested, and only for this particular problem. As a result, there is at least a small chance it might break some other functionality that would normally be caught before a hotfix release. Barring any unexpected test failures, it will be published to the stable channel during the next Xamarin.iOS stable update.
Be sure to quit and re-open the Xamarin.iOS Build Host app after installing this package.
Note that there are other a couple other possible causes of the "No Devices Attached" message (if the
mtbserver.log file does not contain the "Argument cannot be null" error):
The hotfix releases that were just published to the stable channel include some changes for how the device listing works. They might improve the success rate of the device listing process.
I can confirm Tim.Miller's excellent observation that enabling Wi-Fi sync for a device within Wi-Fi range is sufficient to cause this problem. I can reproduce the issue very reliably on the latest stable builds using this approach.
For anyone seeing this problem, be sure to try disabling this setting in iTunes for all nearby devices (or switching off Wi-Fi altogether on all of the devices).
Un-check the "Sync with this iPhone over Wi-Fi" option.
This might not resolve the problem in all cases, but it definitely solves a few of the cases. I've added this information to the bug report to help the developers investigate the problem. I think with this new reliable way to reproduce the issue, they will be able to make steady progress.
Starting with Xamarin 3.6, Xamarin.iOS 8.0, and Xcode 6, several users have been hitting a problem where iOS devices will not appear in the device list in Visual Studio. Instead the device list will always say "No Devices Attached".
Based on the corresponding exception message and stack trace, it seems likely that the in-progress fixes for the "(500) Internal Server Error" will help with this problem too. Those fixes are related to
Mtb.Server.Commands.ListDevices.GetDevices(). Candidate hotfix builds for that problem will hopefully be available soon.
In the mean time, here are a couple questions for any users who might be seeing this:
Are you by chance using a Parallels VM to run Windows? If the problem is more likely to happen in Parallels, that might help the developers reproduce and debug the problem.
Does switching to Xcode 5 (without downgrading Xamarin) avoid the problem?
If the problem depends on Xcode 6, then the same workarounds for the "(500) Internal Server Error" might help with this problem too. In particular, switching back to Xcode 5 might stop the problem. See http://forums.xamarin.com/discussion/25504/ios-designer-500-internal-server-error-avoid-by-using-xcode-5 for more details.
One user reported that downgrading to Xamarin 3.5.58, Xamarin.iOS 220.127.116.11, and Xcode 5 did successfully stop the problem, but there's a decent chance that downgrading just Xcode will help.
One user reported that reinstalling the current Xamarin version using the individual
.msi installer package helped.
Clearing the log files and caches and re-pairing has helped temporarily in some cases too:
Delete the following folders on the Mac build host:
Delete the following folder on the Windows machine:
Click the "Unpair" button on the Xamarin.iOS Build Host app, and then re-pair again with Visual Studio.
Here's the full error message from the
// Exception: Exception type: System.ArgumentNullException // Argument cannot be null. // Parameter name: version // at System.Version..ctor (System.String version) [0x00000] in <filename unknown>:0 // at Mtb.Server.DeviceListener.<GetDevices>m__1 (Xamarin.MacDev.IPhoneDevice d) [0x00000] in <filename unknown>:0 // at System.Linq.Enumerable+<CreateSelectIterator>c__Iterator10`2[Xamarin.MacDev.IPhoneDevice,Mtb.Server.Device].MoveNext () [0x00000] in <filename unknown>:0 // at System.Collections.Generic.List`1[Mtb.Server.Device].AddEnumerable (IEnumerable`1 enumerable) [0x00000] in <filename unknown>:0 // at System.Collections.Generic.List`1[Mtb.Server.Device]..ctor (IEnumerable`1 collection) [0x00000] in <filename unknown>:0 // at System.Linq.Enumerable.ToList[Device] (IEnumerable`1 source) [0x00000] in <filename unknown>:0 // at Mtb.Server.DeviceListener.GetDevices () [0x00000] in <filename unknown>:0 // at Mtb.Server.Commands.ListDevices.GetDevices () [0x00000] in <filename unknown>:0 // at Mtb.Server.Commands.ListDevices.HandleRequest (ILoggingHelper logger, System.Object commandRequestState) [0x00000] in <filename unknown>:0 // at Mtb.Server.BaseCommand.OnRequest (System.Net.HttpListenerContext context, System.Object commandRequestState) [0x00000] in <filename unknown>:0 // at Mtb.Server.Listener.OnRequest (System.Object state) [0x00000] in <filename unknown>:0 // Argument cannot be null.
For some reason the call to
Mtb.Server.DeviceListener.<GetDevices>m__1 (Xamarin.MacDev.IPhoneDevice d) is attempting to create a new
System.Version object with a null input:
Presumably this means that an earlier method call is failing silently and returning
null instead of a valid version string like "7.1.2". That kind of failure sounds like it could be the result of an Objective-C method call or a failed
as conversion. Just to make one guess, the explanation might be that Xcode 6 sometimes return
null when the build server queries it for the iOS versions of the attached simulators and devices. This could even be an intentional behavior of Xcode 6. If that is the case, then the Xamarin build server will need to be adjusted accordingly.
On at least a few users' machines, this problem is currently appearing and disappearing "unpredictably."
For example, in one case, the
Mtb.Server.DeviceListener.GetDevices() command would fail repeatedly with the
ArgumentNullException. But then, after both computers had been left untouched for a few minutes, the problem would eventually stop, and the device list in Visual Studio would refresh correctly. The
mtbserver process did not crash or restart during this time: the
mtbserver process ID stayed the same, and no new crash logs appeared in "Console.app -> User Diagnostic Reports". This system had Visual Studio installed in a Parallels VM on the Mac build host (OS X 10.9.5).
In another case, each time the user installed a new Xamarin update from the updater service, the problem would stop temporarily (for maybe a day or two).
EDIT October 16: Mention the new hotfix build. It includes some changes in the device listing code that might help with the problem.
EDIT October 17: The hotfix from October 16 did not solve the problem, but disabling Wi-Fi sync via iTunes can definitely help (at least in some cases).
EDIT October 24: Candidate hotfix build.
EDIT October 31: Fix published to the stable channel