Created attachment 17144 [details]
Xamarin Studio log files

This is unlikely to be something we can affect

Marking as low/minor as there is a trivial workaround - restart the sim.

Apple broke a lot of stuff with the sim this time round and it is much less stable than it used to be. This is towards the bottom of the list of things we need to look at

One potential complication is whether Xamarin might need to switch around the failure mode to be a good citizen: rather than causing the simulator to become unresponsive, perhaps the designer could semi-gracefully refuse to initialize if the iOS 10 simulator is currently running.

There are some pros and cons either way from a perspective of "least surprise" for a user, but perhaps the "good citizen" consideration is enough to tip the balance slightly in favor of changing the failure mode.




## Possible adjustments for Cycle 8

For expediency for now, maybe it would be possible to do something similar to the following:



- Check if the iOS 10 simulator is running at each of the following times:

(a) During iOS project load in Xamarin Studio (when the designer normally initializes)

(b) During the build host connection from Visual Studio (when the `Designer.exe` process is starting up)

(c) When attempting to open a storyboard in Xamarin Studio



- If the iOS 10 simulator is running, cancel the designer initialization and output an error message in the IDE log file similar to the following:

> Initialization of the designer service has been aborted to avoid
> interfering with a running iOS 10 simulator.  If use of the designer
> service is desired, please quit the iOS 10 simulator and retry.  As
> soon as the designer service is initialized, the iOS 10 simulator can
> safely be relaunched.


- Additionally, if the error happens during (c) (when attempting to explicitly open a storyboard in Xamarin Studio), perhaps the error message can also be shown in the "standard" error dialog box within the designer surface.



### Potential complications


- If the new logic to detect the run state of iOS 10 simulator is sometimes incorrect (e.g., it thinks the iOS 10 simulator is running when it's not), then aborting the designer initialization based on that logic could block users from being able to use the designer at all.  And the error message would be frustratingly inaccurate in that case.


- The error message would potentially be a bit confusing to users because starting up the designer service is not something the user usually does directly.  It's also tricky to convey in only a few words that the conflict is only a problem during _initialization_, and that it's fine to start the iOS 10 simulator after that.  One of the problems is that the error message inevitably has to briefly teach the user that the designer has a distinct initialization phase that is separate from the normal usage phase.




## Possible further enhancements for Cycle 8 – Service Release 1 or later

One possible idea to combat the potential complications of a raw error message could be to display a dialog message instead.  The dialog could say something like:


> The designer service detected a running iOS 10 simulator during
> initialization.  Continuing with the initialization would likely cause the
> simulator to become non-responsive, so you would need to quit and restart the
> simulator after the designer service starts.
>  
> Please choose how to proceed:
> 
> ( ) Quit the iOS 10 simulator for me and then restart it after the designer
>     service is initialized.
> 
> ( ) Leave the iOS 10 simulator running _and_ start the designer service.
> 
> ( ) Cancel starting the designer service.
> 
> 
> ( ) Remember this option for next time.
> 
> (OK) (Cancel)

Adding detection for a running simulator is tricky for the visual studio case. We have to round trip from windows to mac before initialising the designer just to check its running. I suspect that any change would have to happen for the next service release. It's too big a change to rush this week.

We can review it when the GM is released. If it ends up being a common problem we could add a temporary notice when starting the designer or forms previewer.

since C8 is now closed, and is shipping this week, I will move this but to the C8SR1 milestone. We'll continue working on the issue seeking it's resolution as soon as possible.

Fixed in version 6.2.0.492 (master)

Author: Alan McGovern
Commit: 626ce66504b019adeca29fc4b6374a0b2cc14812 (xamarin/ios-sim-sharp)
Included in Commit: b81325eef8adf74178c7465ce4ea9979a558ba09 (mono/monodevelop)

Fixed in version 6.1.0.5442 (cycle8)

Author: Alan McGovern
Commit: 626ce66504b019adeca29fc4b6374a0b2cc14812 (xamarin/ios-sim-sharp)
Included in Commit: d3e6b3050a54e805ad4d8f0f2ba53d1afd1e7e3a (mono/monodevelop)

This has been mitigated to make it less frequent, but not completely resolved.

I'm marking this as resolved/fixed so we can test the mitigation that @Alan describes in the trello card:

"A mitigation to make the reset less frequent has been added to master and C8.

The full fix (never having to reset the services) falls outside the scope of SR0. We'll leave the bug open until we can properly resolve it."

We will track the full fix in bug 44373

lets do it the other way around. This has all the info i need. Let's use 44373 to verify the mitigation :)

44373 has been verified as fixed. Would this then also be considered fixed as per my understanding of comment 17?