* AppleTLS is the default since C7 and support up to TLS 1.2.
* MonoTLS is limited to SSLv3 and TLSv1: both are being deprecated.
* Note: C9 release notes already mention MonoTLS is deprecated and that it will be removed in the future.
The BundleId property is used by the code that generates the mSYM directory,
but its value was always the default value 'com.yourcompany.sample' instead of
looked up in the app's Info.plist.
So fix the BundleId property to do the expected.
Also fix the mSYM test (SymbolicationData) to actually test mSYM stuff (it was
partially disabled when we disabled automatic mSYM generation for C8, and
never re-enabled), and port it to the new and better test syntax, and add a
few more asserts to check the manifest.xml generation.
-lsqlite3 is a linker flag, not a file to be linked with, so when
automatically determining that we need to pass -lsqlite3 we need to put it in
the right list of linker information.
Otherwise we may end up passing `-force_load -lsqlite3` to the linker (if the
assembly's ForceLoad flag is set), which won't compile.
https://bugzilla.xamarin.com/show_bug.cgi?id=49220
dontlink/64-bit release times out on our Sierra bots, so try to bump the
timeout to see if this is working on other bots because those other bots are
faster.
- https://bugzilla.xamarin.com/show_bug.cgi?id=43236
- In Xcode 8b3, Apple changed this property to depend on the deployment target
for weak/strong'ness
+#if MAC_OS_X_VERSION_MIN_REQUIRED < MAC_OS_X_VERSION_10_12
@property (nullable, strong) NSTextView *textView;
+#else
+@property (nullable, weak) NSTextView *textView;
+#endif
@end
- We could parse the MacO headers to get this and change
strong/weak'ness but:
- It is easier to default to weak, the "safe" option. It introduces a possible
leak but you can null it out in that rare case.
- If Apple does this more regularly, we may have to readdress
* [msbuild] Added a PropertyListEditor task which works like PlistBuddy
This is a convenience Task for customers and isn't currently used
by the core MSBuild targets.
* [msbuild] The PropertyListEditor task does not need a SessionId property
* [msbuild] Added support for non-container root plist elements
* [msbuild] Catch & log exceptions loading plist document
If the watchOS dll app is not copied to the output directory, the watchOS app project will be outdated for VS and it'll be built all the time. That will also cause the iOS app project to be built.
* [tests] Fix framework-test to actually work.
* [xharness] Properly replace 'ios' with corresponding platform for paths to our test frameworks as well.
* [framework-test] Fix watchOS build.
* Bump maccore to get new mlaunch.
A new mlaunch that:
* Should have fewer random failures when launching watchOS apps.
* Supports launching extensions on device.
* Supports uninstalling apps from devices.
* [jenkins] Automatically detect mono bumps and enable device build.
And do this before fetching labels, so that we can skip fetching labels if we
know we're already enabling the device build.
* [tests] Bumping LLVM merits enabling device build and running mtouch + BCL tests.
e.g. running twice
> make run-ios-sim32-introspection
results in
Unhandled Exception:
System.AggregateException: One or more errors occurred. ---> System.IO.IOException: /Users/poupou/git/master/xamarin-macios/tests/logs/exec-ios-sim32-introspection/iPhone 5.log already exists
at System.IO.File.Copy (System.String sourceFileName, System.String destFileName, System.Boolean overwrite) [0x001bd] in /private/tmp/source-mono-4.8.0/bockbuild-mono-4.8.0-branch/profiles/mono-mac-xamarin/build-root/mono-x86/mcs/class/corlib/System.IO/File.cs:109
at System.IO.File.Copy (System.String sourceFileName, System.String destFileName) [0x00000] in /private/tmp/source-mono-4.8.0/bockbuild-mono-4.8.0-branch/profiles/mono-mac-xamarin/build-root/mono-x86/mcs/class/corlib/System.IO/File.cs:69
at xharness.CaptureLog.StopCapture () [0x00019] in /Users/poupou/git/master/xamarin-macios/tests/xharness/Log.cs:252
Also:
* some refactoring to reduce the reflection usage for each field-based
introspection tests;
* some fixes for existing bindings, mostly missing [Notification]
* removal of `unsafe` in the notification binding generation (not needed)
* Ignore the new test on XM until the API have been fixed
When creating a CVPixelBuffer with planar bytes, we create one GCHandle for
every byte[] of planar data, as well as one GCHandle for a custom object that
has an array of all the other GCHandles.
All these GCHandles were freed properly if the CFPixelBuffer was successfully
created, but in the case of failure, only the GCHandle for the custom object
was freed.
So make sure to free all the GCHandles even in the case of failures by calling
the free callback function.
This reduce the metadata size and this information, even if part of the
header files, is not required (as some types are just not refcounted)
E.g.
public bool MicrophoneEnabled {
[Export ("isMicrophoneEnabled", ArgumentSemantic.UnsafeUnretained)]
should be
public bool MicrophoneEnabled {
[Export ("isMicrophoneEnabled")]
This could have been done in different places but not generating them has
the smallest impact versus:
1. Check bindings input and report them as errors
- con: break existing binding code;
- con: sharpie outputs them;
2. Removed by the linker
- con: linking not always enabled, e.g. 3rd party bindings
- con: extra logic == extra time for each build
Generator diff
https://gist.github.com/spouliot/cc36e68bf7bd6097064ed6ba0bb3275a
Commit ba37aa44 workaround around a signature clash incorrectly and
turned the selector to static ones (and incorrectly set the handle)
Also fix a typo in the [Advice] attribute of the old API
https://bugzilla.xamarin.com/show_bug.cgi?id=48382
That logic wrongly assumed that mtouch will always output a new
native executable file and that the dSYMs will need to be regenerated,
but that is not the case.
Move the rm -rf logic into the _GenerateDebugSymbols target instead,
so that we only delete the dSYMs if we've already committed to
regenerating them.
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=41231
For a walk-through of the problem, see
https://bugzilla.xamarin.com/show_bug.cgi?id=47803#c9