Usually mono does this for other apps, but not for watchOS (where mono doesn't
use signals at all).
watchOS can still raise signals though, so we need to ignore at least SIGPIPE.
commit mono/mono@e4d33f70d4
Author: Rolf Bjarne Kvinge <rolf@xamarin.com>
Date: Wed May 18 14:21:23 2016 +0200
[System] Throw PlatformNotSupportedException if NetworkInformation.NetworkChange is used on watchOS. (#3010)
NetworkInformation.NetworkChange requires the SystemConfiguration framework,
which isn't available on watchOS.
And add the new file to the build.
commit spouliot/Touch.Unit@ffe2a6dcff
Author: Rolf Bjarne Kvinge <rolf@xamarin.com>
Date: Wed May 25 18:11:59 2016 +0200
Add a HttpTextWriter that can send logs over http.
There is no public API to create raw sockets with watchOS, so
we can't use Tcp directly, thus the need for using Http.
This prevents the watch from getting mightily confused when re-installing
watch apps/extensions.
Not having a CFBundleShortVersionString would cause the following:
* Build & install & run would work fine the first time.
* The second build & install would confuse the watch so that the
app wouldn't launch. Removing the app and reinstalling wouldn't
work; the potential options would be to either reboot the device,
or add a CFBundleShortVersionString to the Info.plists and install
that build twice.
* [XM] Teach XM's mmp tool to handle read only assemblies/native libs
- https://bugzilla.xamarin.com/show_bug.cgi?id=41037
- mmp should also promote any install_name_tool errors to "real" errors
* Bump maccore
Starting with Xcode 7, storyboards are output as
Interface.storyboardc/Interface.plist instead of Interface.plist
We can also safely link these storyboards as long as we pass
the storyboardc directory to ibtool.
Looks like Xcode isn't generating any UIDeviceRequiredCapabilities
for watchOS 1 extensions.
It used to have UIRequiredDeviceCapabilities = 'watch-companion'
but that *might* not be required anymore.
Commit 94e35a8570 on xamarin-macios/master
comes from those same assumptions.
Now regarding bug #41204:
User is getting error "ERROR ITMS-90563: "Missing UIRequiredDeviceCapabilities value"
when publish WatchKitCatalog sample.
(https://bugzilla.xamarin.com/show_bug.cgi?id=41204)
This might happen because we're still creating an empty array for the
UIDeviceRequiredCapabilities key.
In any case there's no need to create it.
Added the missing static factory methods and the missing property. In
order to give a clean API a new flag was added to the NSExpression class
to track if the Block property does return a block or a null ptr. The
idea is to avoid user from seeing an obj-c exception.
This commit fixes bug #35012:
https://bugzilla.xamarin.com/show_bug.cgi?id=35012
The evaluation of the NSExpression and the defition of the
NSExpressionHandler have also been fixed since both should be using
NSObjects.
The `_stret` API are not included in the ARM64 version of iOS (not
needed) but the removal of `dlsym` cause build failures*
So we're providing dummy symbols, just like what we did for tvOS,
to please the native linker (so nothing is undefined) and keep the
benefits of not using dlsym.
* Xamarin.iOS.dll (or other bindings) when the linker is disabled.
Normally the linker would remove the 32bits parts of the bindings
on a 64bits slice (and that would not be noticed). However we can
not assume this will be done for all binding projects, hence this
workaround.
[Xamarin.Hosting] Set a default simulator if nothing is provided to mlaunch. Fix#41083 part 3
The string to represent a specific simulator is not something you can
easily remember but it's often not very important.
This will start the most basic simulator, by default, instead of throwing
an NRE that does not mention a (now un-) required parameter is missing.
> Failed to launch the simulator: Object reference not set to an instance of an object
> error MT1008: Failed to launch the simulator: Object reference not set to an instance of an object
https://bugzilla.xamarin.com/show_bug.cgi?id=41083
In cycle 7 we turned off, by default, the `dlsym` option (i.e. looking
up symbols for p/invoke) for tvOS and watchOS.
However we decided to wait for iOS to see if this caused issues for
existing code base. There has not been such reports (for tvOS) so,
for cycle 8, we'll turn it off (and use direct calls) for iOS.
If problems arise during the alpha/beta of C8 then we still can
revert this change easily.