Kept the API as it was but added a new handler that will be called when
all the changes from the browser have been done. The old Set* method
could be deleted in a future release and just expose the property.
microsoft.com is doing user agent sniffing, and broke our our test since their
output is now different. Switch to example.com instead.
Fixes https://github.com/xamarin/maccore/issues/2006.
* Drop the Xcode 9.4 dependency. (#7044)
* Drop the Xcode 9.4 dependency.
Also bump mono to get the removal of the mac32 binaries.
New commits in mono/mono:
* mono/mono@beb9a1b182 [sdks] Remove the mac32 build.
* mono/mono@747a919a06 [ci] Make ios/mac sdks archive URL more predictable
* mono/mono@114013096e [ci] Build iOS/Mac Mono sdks archive using Xcode 11
* mono/mono@10a24f3ea1 Implement WriteCore and ReadCore in DeflateStream
* mono/mono@a925846b1f [offsets-tool] Install clang into the user-specific python directory. (#16933)
* mono/mono@fe64a4765e [2019-06] Bump msbuild and sdk versions to 3.0.1xx latest (#16870)
* mono/mono@7293597b90 [corlib] Fix building nunit-lite twice (#16910)
* mono/mono@1648e88687 Rename bundle identifier for the various Mono.frameworks we create for Xamarin.iOS. Fixesxamarin/xamarin-macios#7005. (#16896)
* mono/mono@a6b5187d76 [metadata] Fix leaks when handling a few attributes (#16675) (#16851)
* mono/mono@7da9a041b3 [2019-06] Bump to mono/corefx@e79cf5b
* mono/mono@2b7050bdf3 [2019-06] Add RenamedEvent* to FSW sources from CoreFX (#16758)
* mono/mono@4f5ed502c6 [msbuild] pick up p4 versions
* mono/mono@f04ee2219d [2019-06][msbuid][roslyn] Bump msbuild and roslyn-binaries to pick up dotnet 3.0.100-p9 toolset
* mono/mono@6b4b99e571 Vtable [i] can be null so this should be check before use it. Fixes#16712
Diff: 7af64d1ebe..beb9a1b182
* [tests] Add a fat macOS dylib for testing purposes.
Add a binary version of a fat macOS dylib (because we can't create one when we
need it since we can't create 32-bit slice anymore).
It was created like this (in tests/test-libraries):
$ cat test.m
int theUltimateAnswer ()
{
return 42;
}
$ /Applications/Xcode94.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang test.m -olibtest.i386.dylib -shared -isysroot /Applications/Xcode94.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -framework Foundation -framework CoreLocation -lz -arch i386
$ lipo -create libtest.i386.dylib .libs/macos/libtest.dylib -output libtest-fat.dylib
* [tests] Adjust XM tests to XM not having fat dylibs anymore.
* [tests] Adjust product tests to some libraries not being fat anymore.
* [tests] Don't treat an Xcode with the same major version number as old.
Fixes an issue in the MT0091 test, where it would fail on tvOS because the
test wanted to use an older Xcode, and we could end up returning Xcode 11.0
when the current Xcode is 11.1. Since the test depends on using the OS SDK as
it was designed for (technically using an OS SDK earlier than the latest), it
ended up failing because while the iOS SDK was bumped in Xcode 11.1, the tvOS
SDK was not.
Tests were failing because the manager was getting dispose and the
delegate was not. We ran into the failure because there was a device
close to the lab with the UUID that was being used.
The change uses a even more common UUID (heart monitor), which should
increase the chances to pick up a device and re-orgs the disposal of the
manager and the delegate.
This was confirmed with a BLE device, watchOS does not like us to try
and access it as a bluetooth device and is 'hacky'.
Fixes: https://github.com/xamarin/xamarin-macios/issues/7108
Types that are new in 64bits only OS are generated differently on 32bits
bindings. They mainly throw a `PlatformNotSupportedException` so it's
easier to diagnose (than a crash) what's happening at runtime.
This works well in all cases except one. When a new type, let's say
`UIMenuElement` is added **and** serves as a new base type for existing
types.
`UIKeyCommand` (iOS 7) -> `UICommand` (iOS 13)-> `UIMenuElement` (iOS 13)
This is _correct_ as new base types can be added (in ObjC and C#).
However the generated code for the constructors of `UICommand` and
`UIMenuElement` would be throwing a `PlatformNotSupportedException`
which breaks the `UIKeyCommand` on 32 bits devices.
We fixed this in a few places by tweaking the availability attribute
but that requires spotting the new base type while doing bindings and
that is error prone [1][2].
This PR simply does let the `protected` constructor, using when chaining,
be generated normally. It's simpler and will cover all the cases (without
requiring hacks in the availability of those types)
[1] https://github.com/xamarin/xamarin-macios/issues/7083
[2] https://github.com/xamarin/xamarin-macios/issues/7084
In iOS 13 it's no longer possible to get PACs from file:// urls (this is
explained in the release notes, so it's expected). So launch a local
httpserver and serve the PAC that way.
link-framework-1 ensures that we link away as many frameworks as possible.
Unfortunately there are things we can't link away when using the dynamic
registrar, so switch to testing the Release configuration instead, since that
automatically uses the static registrar (and the release configuration is the
better option to test anyway, since it's closer to what customers use to
release).
This should let us provide a nicer API for the GM change about
`CBManager authorization` moving from an instance to a static
property (in all but iOS 13.0 / watchOS 6.0)
For some reason (likely to be added back later ?) Xcode 11 GM removed
most of new macOS 10.15 API for FileProvider.
So instead of deleting stuff this uses a lot of `[NoMac]` even if some
API are actually not part of any platform anymore, e.g. you can see the
following line in the GM headers
```
API_UNAVAILABLE(watchos, tvos) API_UNAVAILABLE(ios, macos)
```
We ship a default, pre-built, simlauncher for iOS simulator applications.
This speeds up compilation for the default (non linked) simulator builds
quite a lot (no call to `clang` is needed). However it force us to keep
track of frameworks manually - `mtouch` can track them but requires
calling clang/ld to finish things up (killing the optimization).
It's easy to forget some (new) frameworks since they can be loaded
dynamically (on demand) _most_ of the time. Sadly there are a few cases
where doing so cause (hard to diagnose) problems - so we can't depend
on them being loaded, correctly for us.
The new test case loads the `otool -L` output (make when we build
simlauncher[32|64]-sgen) and compares it with mtouch's GetFramework
logic *and* with our namespaces (which is pretty close, with a few
exceptions, to the framework names). This will make it harder to
forget [weak] frameworks when adding new bindings :)
Fixes https://github.com/xamarin/xamarin-macios/issues/6951
Pramit Mallick
Manuel de la Pena
Vincent Dondain
Waleed Chaudhry
monojenkins
Rolf Bjarne Kvinge
Sebastien Pouliot
Alex Soto
Whitney Schmidt