note: AVFoundation is commented on watchOS 3 as this breaks the static
registrar .a helper built for watchOS.
AVFoundation does a file check to enable some types - but the watchSimulator
include that file, leading to compilation errors later (missing CMTime.h)
#if TARGET_OS_WATCH
#if ! __has_include(<AVFoundation/AVAnimation.h>)
#define AVF_IS_WATCHOS_SDK 1
#endif
#endif
The real fix for bug #43658 is in mono master, but the current
version of mono master doesn't build for us, so implement this
workaround instead.
The problem is that the linker doesn't preserve fields of nested types marked
in xml descriptions unless the declaring type is marked. So the workaround
(until we can bump mono) is to mark the declaring type.
https://bugzilla.xamarin.com/show_bug.cgi?id=43658
* Bump [watch-]mono to master to get fix for #43658.
https://bugzilla.xamarin.com/show_bug.cgi?id=43658
* [mtouch/mmp] Fix build after breaking cecil update in mono.
Also use mono's cecil instead of our own cecil submodule for mtouch.
* Bump [watch-]mono to get compilation fixes after cecil bump in mono.
* Remove cecil submodule, we only use the one in mono now.
This way we use the right version of any dependent dlls.
Otherwise we'd build with the cecil version from the mono repository,
and run with the system's cecil.
* [Mtouch] Use the mono tools to copy over the msym files.
* As per review:
* Do not create a DirectoryInfo when it is not needed.
* Do not throw exceptions for values that can be null, should never
happen.
* Remove unused import.
* Undo a wrong using removal and do the right thing.
* Fix build issues.
* [C8] Bump to latest Mono 4.6.0 commit
Brings in the netstandard updates from https://github.com/mono/mono/pull/3394
We also had to add a new assembly System.IdentityModel.dll to the mobile profiles while doing that work.
* Add System.IdentityModel to Sdk assemblies
Fixes the following mtouch test failure:
```
Xamarin.Linker.SdkTest.iOS_Classic : BCL
Expected:
But was: < "System.IdentityModel" >
at NUnit.Framework.CollectionAssert.IsEmpty (IEnumerable collection, System.String message, System.Object[] args) <0x47bec88 + 0x00047> in :0
at NUnit.Framework.CollectionAssert.IsEmpty (IEnumerable collection, System.String message) <0x47bec58 + 0x0001f> in :0
at Xamarin.Linker.SdkTest.BCL (System.String path) <0x47bccf0 + 0x003f3> in :0
at Xamarin.Linker.SdkTest.iOS_Classic () <0x47bcc50 + 0x0001b> in :0
```
Fixes the following mtouch test failure:
```
Xamarin.Linker.SdkTest.iOS_Classic : BCL
Expected:
But was: < "System.IdentityModel" >
at NUnit.Framework.CollectionAssert.IsEmpty (IEnumerable collection, System.String message, System.Object[] args) <0x47bec88 + 0x00047> in :0
at NUnit.Framework.CollectionAssert.IsEmpty (IEnumerable collection, System.String message) <0x47bec58 + 0x0001f> in :0
at Xamarin.Linker.SdkTest.BCL (System.String path) <0x47bccf0 + 0x003f3> in :0
at Xamarin.Linker.SdkTest.iOS_Classic () <0x47bcc50 + 0x0001b> in :0
```
- Linking breaks extensions for as long as we have the "extensions must be use static registrar" hack.
- So let's ignore it with a warning. Better that random brokeness.
- https://bugzilla.xamarin.com/show_bug.cgi?id=43197
- Linking breaks extensions for as long as we have the "extensions must be use static registrar" hack.
- So let's ignore it with a warning. Better that random brokeness.
- https://bugzilla.xamarin.com/show_bug.cgi?id=43197
* Enable some SceneKit-related WatchKit API
* Enable some SceneKit-related SpriteKit API
* Enable some SceneKit-related Foundation API
* Fix generator to include `using SceneKit;` on watchOS
* Adjust xtro tests since watchOS headers include some stuff that's not available in reality
* Lots of [Watch (3,0)] attributes
This is only applicable to tvOS 10 (i.e. the xcode8 branch),
but applying the patch already helps avoiding merge failures
for other fixes in the same area.
* Bump mono and watch-mono
* [mmp] Preserve TransparentProxy::StoreRemoteField
This is needed to prevent a mono assert when xamarin-macios is built
with mono master after mono/mono@6b8e96c
We tried disabling dlsym for all assemblies on iOS, but it turned
out to break a significant amount of customer code [1].
So re-enable it, but only for user assemblies (since we control
all assemblies we ship and can thus make sure those work with
dlsym disabled).
https://trello.com/c/guig1MF2/623-re-enable-dlsym-for-ios
We tried disabling dlsym for all assemblies on iOS, but it turned
out to break a significant amount of customer code [1].
So re-enable it, but only for user assemblies (since we control
all assemblies we ship and can thus make sure those work with
dlsym disabled).
https://trello.com/c/guig1MF2/623-re-enable-dlsym-for-ios
Fixes the Sdk test:
Errors and Failures:
1) Test Failure : Xamarin.Linker.SdkTest.iOS_Classic
System.Security.Cryptography.Algorithms
Expected: True
But was: False
at Xamarin.Linker.SdkTest.Facades (System.String path) <0x30d4640 + 0x0006f> in <filename unknown>:0
at Xamarin.Linker.SdkTest.iOS_Classic () <0x30d2808 + 0x0004b> in <filename unknown>:0
2) Test Failure : Xamarin.Linker.SdkTest.iOS_Unified
System.Security.Cryptography.Algorithms
Expected: True
But was: False
at Xamarin.Linker.SdkTest.Facades (System.String path) <0x30d4640 + 0x0006f> in <filename unknown>:0
at Xamarin.Linker.SdkTest.iOS_Unified () <0x30d5558 + 0x0004b> in <filename unknown>:0
3) Test Failure : Xamarin.Linker.SdkTest.tvOS
System.Security.Cryptography.Algorithms
Expected: True
But was: False
at Xamarin.Linker.SdkTest.Facades (System.String path) <0x30d4640 + 0x0006f> in <filename unknown>:0
at Xamarin.Linker.SdkTest.tvOS () <0x30d55d8 + 0x0004b> in <filename unknown>:0
4) Test Failure : Xamarin.Linker.SdkTest.watchOS
System.Security.Cryptography.Algorithms
Expected: True
But was: False
at Xamarin.Linker.SdkTest.Facades (System.String path) <0x30d4640 + 0x0006f> in <filename unknown>:0
at Xamarin.Linker.SdkTest.watchOS () <0x30d5658 + 0x0004b> in <filename unknown>:0
* [XM] Fix linker ability to deadstrip library loads from NSObject.mac.cd for new libraries
- Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=42177 in Release / Mobile since we can rip out GameController if not used
Fixes the Sdk test:
Errors and Failures:
1) Test Failure : Xamarin.Linker.SdkTest.iOS_Classic
System.Security.Cryptography.Algorithms
Expected: True
But was: False
at Xamarin.Linker.SdkTest.Facades (System.String path) <0x30d4640 + 0x0006f> in <filename unknown>:0
at Xamarin.Linker.SdkTest.iOS_Classic () <0x30d2808 + 0x0004b> in <filename unknown>:0
2) Test Failure : Xamarin.Linker.SdkTest.iOS_Unified
System.Security.Cryptography.Algorithms
Expected: True
But was: False
at Xamarin.Linker.SdkTest.Facades (System.String path) <0x30d4640 + 0x0006f> in <filename unknown>:0
at Xamarin.Linker.SdkTest.iOS_Unified () <0x30d5558 + 0x0004b> in <filename unknown>:0
3) Test Failure : Xamarin.Linker.SdkTest.tvOS
System.Security.Cryptography.Algorithms
Expected: True
But was: False
at Xamarin.Linker.SdkTest.Facades (System.String path) <0x30d4640 + 0x0006f> in <filename unknown>:0
at Xamarin.Linker.SdkTest.tvOS () <0x30d55d8 + 0x0004b> in <filename unknown>:0
4) Test Failure : Xamarin.Linker.SdkTest.watchOS
System.Security.Cryptography.Algorithms
Expected: True
But was: False
at Xamarin.Linker.SdkTest.Facades (System.String path) <0x30d4640 + 0x0006f> in <filename unknown>:0
at Xamarin.Linker.SdkTest.watchOS () <0x30d5658 + 0x0004b> in <filename unknown>:0
Category methods are exposed like extension methods, and the first parameter
specifies the class, which means we need to skip the first type when generating
the ObjC signature.
https://bugzilla.xamarin.com/show_bug.cgi?id=42489
There can be circular dependencies between Objective-C classes,
so make sure we don't fail compilation when that occurs by
forward declaring any Objective-C classes/protocols.
The test case in question does not contain a circular dependency,
but the same issue occurs due to types not being generated in the
correct order (a correct order could be constructed for the test
case, but there's no general solution since circular dependencies
can exist).
https://bugzilla.xamarin.com/show_bug.cgi?id=42454
Category methods are exposed like extension methods, and the first parameter
specifies the class, which means we need to skip the first type when generating
the ObjC signature.
https://bugzilla.xamarin.com/show_bug.cgi?id=42489
There can be circular dependencies between Objective-C classes,
so make sure we don't fail compilation when that occurs by
forward declaring any Objective-C classes/protocols.
The test case in question does not contain a circular dependency,
but the same issue occurs due to types not being generated in the
correct order (a correct order could be constructed for the test
case, but there's no general solution since circular dependencies
can exist).
https://bugzilla.xamarin.com/show_bug.cgi?id=42454
Fixes NSCharacterSetTest.NSMutableCharacterSet_TestStaticSets when
running with the P/Invoke wrapper (for exceptions) enabled (i.e.
watchOS), since otherwise the wrapper would truncate char parameters
to byte.
* Added Speech Framework bindings
* Ensured introspection test pass
* Ensured we link against Speech framework
* FIXME: SFSpeechRecordingRecognitionRequest is not in the public api
filled radar://26799291 https://trello.com/c/s6s6YKua
* Added CallKit Bindings
* Ensure CallKit.framework is linked
* Ensure CallKit passes introspection tests
* FIXME: https://trello.com/c/afWXDZ3A
Headers says CallKit is available on macOS 10.12
but uses AVAudioSession and it is iOS only
Opened Radar awaiting response.
There's a clang bug [2] where if a selector is marked as unavailable,
it's marked as unavailable for every class, not just the class where
the unavailable selector is.
This means that we can't do `[super initWithCoder:x]` anywhere,
because `initWithCoder:` is marked as unavailable for UIActivityViewController.
So instead rewrite the call to super to call objc_msgSendSuper
directly, circumventing clang's broken availability checks.
[1] https://bugzilla.xamarin.com/show_bug.cgi?id=41319
[2] https://llvm.org/bugs/show_bug.cgi?id=28058
[XM] Add release value option to msbuild/mmp to resolve XM 4.5 assemblies from system GAC
- This option "reverts" a C7 fix that prevented resovling assemblies from the GAC, which is unsafe
- If you use this option, you need to know what you are doing. The mono BCL and the XM BCL need to be compatible
- Use strictly puts you in the no support "you get to keep the pieces if it breaks" category.
This is because Mono doesn't build a libmono-profiler-log.dylib when
bitcode is enabled, so we can't support profiling + fastdev at the same
time.
Hopefully mono will fix this (see bug#41428) soon, in which case
this code can be removed.
https://bugzilla.xamarin.com/show_bug.cgi?id=41428
* [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
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.
Also bump maccore to get new test.
commit xamarin/maccore@eb9c34d875
Author: Rolf Bjarne Kvinge <rolf@xamarin.com>
Date: Fri May 13 12:46:04 2016 +0200
[monotouch-test] Add test to ensure mtouch properly links with CoreAudioKit when not using simlauncher.
It is apparently common to have references to assemblies that can't
be resolved when building apps with the linker disabled, so we need
to support that.
So add a custom reference loading step that only shows a warning
for unresolvable assemblies.
Also bump maccore to add a test.
commit xamarin/maccore@190c67d855
Author: Rolf Bjarne Kvinge <rolf@xamarin.com>
Date: Tue May 10 18:14:04 2016 +0200
[tests] Add test case for bug #40786.
https://bugzilla.xamarin.com/show_bug.cgi?id=40786https://bugzilla.xamarin.com/show_bug.cgi?id=40786
Traverse directories to find the locally build XamMac directory
when DEBUG is defined (which is only defined in the csproj, which
is only built when running from Xamarin Studio, since the mmp we
ship is built manually in the Makefile).
When reading a plist using NSDictionary, getting a value for a key
that doesn't exist returns null.
This changed when we switched to using our own managed plist reader,
which returns an empty string if a key doesn't exist.
Unfortunately we have code that checks if CFBundleExecutable is null,
in which case we compute the executable name using the executable
assembly, but since we started getting an empty string for
CFBundleExecutable if the key wasn't available, we now ended up wanting
to create an executable named as an empty string.
This broke our bug-13945 test case.
The fix is to continue returning null if the plist key isn't present.
Watch apps are inside .dll (not .exe) and needs to be processed
differently (e.g. to register their content). The issue was that the
debugging symbols were not loaded by that code so it was not part of
the .appex for debugging.
https://bugzilla.xamarin.com/show_bug.cgi?id=40641
mtouch only uses Xamarin.Mac to read plists, so change to use
our purely managed plist reader in Xamarin.MacDev instead.
That makes us able to change mtouch to be a normal command-line
executable (and project).
Which makes it logical to not mkbundle mtouch anymore,
it executes just fine with the system mono (and there's
no code to protect anymore either).
And since mmp and mtouch share some files, do the same
for mmp.