* mono revision at fc99fc4313e7afd75a4605a48b47e7d1273aefe4
* watch-mono revision is more recent to include the BCL adjustments
for types not available on that platform
* Update two linksdk test cases that won't work _normally_ for watchOS
Some binding assemblies contains extra, unneeded code, generated by the C# compiler, e.g.
IL_002f: stloc.0
IL_0030: ldloc.0
which the binding optimizer did not expect.
https://bugzilla.xamarin.com/show_bug.cgi?id=44701
It was missing a few recent commits which broke the build with:
[8:45:24] make[5]: *** No rule to make target `/Users/builder/data/lanes/3426/8568b0c2/source/xamarin-macios/_mac-build/Library/Frameworks/Xamarin.Mac.framework/Versions/git/lib/mono/4.5/System.Numerics.Vectors.dll'. Stop.
At startup we send a request to all the IP addresses we have,
so we must make sure to not get confused if we get responses
from more than one of them.
This fix also requires an updated mlaunch.
https://bugzilla.xamarin.com/show_bug.cgi?id=44568
Bump Mono to pickup the BCL part of the fix (from temporary PR'ed branch)
commit 7ec55bdbe668b917dddab9996ddda372bcc9a561
Author: Martin Baulig <martin.baulig@xamarin.com>
Date: Fri Sep 23 17:42:05 2016 +0200
[AppleTls]: Flush the write queue before finishing the handshake.
It is possible for SSLHandshake() to return SslStatus.Success while we're still
having a pending write (AsyncOperationStatus.WantWrite).
This is because our managed write callback must never return 'WouldBlock', so
SSLHandshake() things that all data have been sent while we still have them in
our write queue.
When this happens, we currently flush the write queue then call SSLHandshake()
again via AsyncOperationStatus.WantWrite -> AsyncOperationStatus.Continue.
This returns SslStatus.Protocol on iOS 10.
(cherry picked from commit 2cc1b887c1c6e86b6844116c8010bac3305c84f9)
Bump Mono to pickup the BCL part of the fix.
commit 2a3e4002ead94aae6796c7eb7af9a850398beb51
Author: Martin Baulig <martin.baulig@xamarin.com>
Date: Fri Sep 23 17:42:05 2016 +0200
[AppleTls]: Flush the write queue before finishing the handshake.
It is possible for SSLHandshake() to return SslStatus.Success while we're still
having a pending write (AsyncOperationStatus.WantWrite).
This is because our managed write callback must never return 'WouldBlock', so
SSLHandshake() things that all data have been sent while we still have them in
our write queue.
When this happens, we currently flush the write queue then call SSLHandshake()
again via AsyncOperationStatus.WantWrite -> AsyncOperationStatus.Continue.
This returns SslStatus.Protocol on iOS 10.
(cherry picked from commit 2cc1b887c1c6e86b6844116c8010bac3305c84f9)
https://bugzilla.xamarin.com/show_bug.cgi?id=37175
NSUrlSession's Create*Task methods may return an object of the wrong
type (NSUrlSessionTask instead of NSUrl[Data|Download|Upload]SessionTask),
so we need to bypass our type check when creating the managed object,
otherwise we end up throwing InvalidCastExceptions randomly. We will
return the type that is declared on the headers so if the native side
returns a cat and headers says it barks we'll we make it bark :).
https://bugzilla.xamarin.com/show_bug.cgi?id=44322
AVAssetDownloadUrlSession.CreateSession according to headers it
should return an AVAssetDownloadUrlSession but it is returning
an apple internal type NSURLBackgroundSession so with our
current bindings it throws an InvalidCastException, adding
ForcedTypeAttribute will create the managed type wihout
the actual typecheck. Added test verifing that the API
no longer throws.
https://bugzilla.xamarin.com/show_bug.cgi?id=37175https://bugzilla.xamarin.com/show_bug.cgi?id=44322
Sometimes iOS API is returning objects of the wrong type for example
- (NSURLSessionDownloadTask *)downloadTaskWithRequest:(NSURLRequest *)request
It clearly states that it will return an NSURLSessionDownloadTask
instance, but yet it returns a NSURLSessionTask and we throw an
InvalidCastException when creating the managed object. This is
fine in ObjC but for us in a type-safety context is not.
Introducing ForcedTypeAttribute when applying this attribute
we will use GetINativeObject instead of GetNSObject which
the former does not perfom a type check on the underlying object
The nested Parallel.ForEach loops don't take into account the outer
MaxDegreeOfParallelism value, causing us to spawn more concurrent tasks than
we want to.
So refactor the code to have one static list of tasks, which each subtask adds
to.
* Update branch name
* Update SDK version for iOS and watchOS (but not tvOS)
* [xharness] Add support for watchOS Series 2 simulators. (#812)
* [xharness] Add Jenkins support for watchOS Series 2 simulators. (#885)
The nested Parallel.ForEach loops don't take into account the outer
MaxDegreeOfParallelism value, causing us to spawn more concurrent tasks than
we want to.
So refactor the code to have one static list of tasks, which each subtask adds
to.
* Fix default http message handler for watchOS.
Fix default http message handler for watchOS to be NSUrlSessionHandler (the
previous attempt at eb7c2fd was quite incomplete), and make sure
HttpClientHandler is never used (show errors if someone tries).
* [tests] Remove explicit http client handler from project files.
Just use the default instead, since the set of valid http client handlers varies between platforms.
We've used the dynamic registrar for years now when selecting the IL registrar
(and I've never heard about anybody doing it), so just remove all the related
(and in fact dead) code.
Rolf Bjarne Kvinge
Alex Soto
Sebastien Pouliot
Chris Hamons
Sebastien Pouliot
Alex Soto
Alexander Köplinger
Martin Baulig
Jeffrey Stedfast
Artur Shamsutdinov