The container app may not reference the same third-party frameworks as
extensions, which means that we must make sure the extension's frameworks are
also included in the app bundle.
So when building extensions save a list of all third-party frameworks, and
then read that list and include those frameworks when building the main app.
https://bugzilla.xamarin.com/show_bug.cgi?id=45800
This fixes the following mmptests:
1) Classic_NewRefCount_Warns (Xamarin.MMP.Tests.MMPTests.Classic_NewRefCount_Warns)
2) SystemMono_SmokeTest (Xamarin.MMP.Tests.MMPTests.SystemMono_SmokeTest)
That fails like this with earlier versions of Mono 4.8:
Undefined symbols for architecture i386:
"_mono_btls_x509_lookup_method_mono_init", referenced from:
-u command line option
"_mono_btls_x509_name_list_add", referenced from:
-u command line option
"_mono_btls_x509_name_list_free", referenced from:
-u command line option
"_mono_btls_x509_name_list_get_count", referenced from:
-u command line option
"_mono_btls_x509_name_list_get_item", referenced from:
-u command line option
"_mono_btls_x509_name_list_new", referenced from:
-u command line option
ld: symbol(s) not found for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)
error MM5109: Native linking failed with error code 1. Check build log for details.
Managed exception marshaling interferes with the debugger, because it adds
exception handlers to executing code, which makes the Mono runtime think an
exception is handled when logically it's not (although technically it is).
The consequence is that the IDEs will only be notified when we re-throw the
exception after catching it, making it impossible for the IDEs to stop when
the exception is thrown (they will instead stop when we re-throw the
exception).
So disable managed exception marshaling (unless the user changed the default
behavior) when a debugger is attached.
This is the same behavior as Xamarin.Android.
https://bugzilla.xamarin.com/show_bug.cgi?id=45116
* [AVFoundation] Add new constructor for AVAssetExportSession.
Add a new constructor that takes an enum instead of a string to have
a strong typed version of the default constructor to reduce possible
errors when passing a random string.
Fixes bug https://bugzilla.xamarin.com/show_bug.cgi?id=44443
* Use smart enums as requested in the PR review.
* Set manually the enum int values.
This makes it possible to set linker flags per assembly:
[assembly: LinkWith (LinkerFlags = "-lsqlite3")]
Which is required when incremental builds is enabled and a particular assembly
needs special linker flags (because we don't propagate the global -gcc_flags
to each dylib we build when doing incremental builds).
Also add an option to set the dlsym mode for an assembly (using the LinkWith
attribute).
Duration before: 1,60s
Duration after: 1,54s
Difference: -0,06s = -3,8%
Memory usage hardly changed (-21 kb of 540 MB), but the number of method calls
shrunk significantly.
Method calls before: 86.720.379
Method calls after: 74.390.061
Difference: -12.330.318 = -14,2%
The call to `GetSystemVoidType` was #2 on the list of method calls (whens
sorted by 'self'), called 1072 times taking 1429 ms each time. After this
change it's only called once (and obviously pushed way down the list).
- BuildAndLaunchTime is replacing AppLaunchTime as it calculates both
build time and launch time for different linker modes.
* [mtouch/tests] Add RegistrarTime test
- Also fix MTouchTool --registrar:dynamic
* [system-dependencies] Add support for installing Xcode's first-launch installs.
* [system-dependencies] Use the Archive Utility to extract Xcode xips.
Apple changed their format (again), so don't try to process the xip manually,
just invoke Apple's Archive Utility.
Another advantage is that the Archive Utility compresses the output (to about
half), saving multiple GB of hard disk space (from ~10 GB to ~5 GB).
* [system-dependencies] Add Xcode testing comment.
* [system-dependencies] Check if an Xcode package is in ~/Downloads, and if so use it.
This makes it easier to verify that provisioning works correctly whenever a new Xcode comes out.
Setting this option prints this to stdout:
> Mono Warning: option gen-compact-seq-points is deprecated.
and it's ignored, so just don't set this option.
- https://bugzilla.xamarin.com/show_bug.cgi?id=45764
- _CompileToNative's output in msbuild was incorrectly set to:
$(_AppBundlePath)Contents\MacOS\$(TargetFileName) when the generated
file lives at $(_AppBundlePath)Contents\MonoBundle\$(TargetFileName).
- This means we'd always try to rebuild, which can be rather time consuming.
- The XI target file is just different enough to require a seperate fix.
Example code:
public override void ViewDidLoad ()
{
throw new Exception ("USELESS");
}
Current output with unhandled exceptions that are marshaled:
Unhandled Exception:
System.Exception: USELESS
at (wrapper managed-to-native) AppKit.NSApplication:NSApplicationMain (int,string[])
at AppKit.NSApplication.Main (System.String[] args) [0x00041] in /work/maccore/master/xamarin-macios/src/AppKit/NSApplication.cs:98
at UselessExceptions.MainClass.Main (System.String[] args) [0x00007] in /Users/rolf/Downloads/filed-bug-test-cases-master/Xamarin/bxc45742/Main.cs:10
[ERROR] FATAL UNHANDLED EXCEPTION: UselessExceptions.CustomException: USELESS
at (wrapper managed-to-native) AppKit.NSApplication:NSApplicationMain (int,string[])
at AppKit.NSApplication.Main (System.String[] args) [0x00041] in /work/maccore/master/xamarin-macios/src/AppKit/NSApplication.cs:98
at UselessExceptions.MainClass.Main (System.String[] args) [0x00007] in /Users/rolf/Downloads/filed-bug-test-cases-master/Xamarin/bxc45742/Main.cs:10
Note how the managed frame where the exception was thrown does not show up.
This is because we technically catch exceptions when marshaling them, and then
later we call mono_raise_exception to raise the same exception. Unfortunately
that leads to overwriting the initial stack trace, and we end up with a stack
trace that does not include the location where the original exception was
thrown.
So instead of calling mono_raise_exception to rethrow the same exception, we
use ExceptionDispatchInfo, which is able to capture the stack trace for both
the original exception and the new exception, producing the following output:
System.Exception: USELESS
at UselessExceptions.ViewController.ViewDidLoad () [0x0000c] in /Users/rolf/Downloads/filed-bug-test-cases-master/Xamarin/bxc45742/ViewController.cs:27
--- End of stack trace from previous location where exception was thrown ---
at (wrapper managed-to-native) AppKit.NSApplication:NSApplicationMain (int,string[])
at AppKit.NSApplication.Main (System.String[] args) [0x00041] in /work/maccore/master/xamarin-macios/src/AppKit/NSApplication.cs:98
at UselessExceptions.MainClass.Main (System.String[] args) [0x00007] in /Users/rolf/Downloads/filed-bug-test-cases-master/Xamarin/bxc45742/Main.cs:10
[ERROR] FATAL UNHANDLED EXCEPTION: UselessExceptions.CustomException: USELESS
at UselessExceptions.ViewController.ViewDidLoad () [0x0000c] in /Users/rolf/Downloads/filed-bug-test-cases-master/Xamarin/bxc45742/ViewController.cs:27
--- End of stack trace from previous location where exception was thrown ---
at (wrapper managed-to-native) AppKit.NSApplication:NSApplicationMain (int,string[])
at AppKit.NSApplication.Main (System.String[] args) [0x00041] in /work/maccore/master/xamarin-macios/src/AppKit/NSApplication.cs:98
at UselessExceptions.MainClass.Main (System.String[] args) [0x00007] in /Users/rolf/Downloads/filed-bug-test-cases-master/Xamarin/bxc45742/Main.cs:10
Incidently this is how Xamarin.Android does it [1].
[1]: 9387f2fe16https://bugzilla.xamarin.com/show_bug.cgi?id=45742
* [mtouch/tests] Add TimingTests
- New MLaunchTool.
- AppLaunchTime (mlaunch): time to launch an application on the simulators.
How it works: we first open the simulator by launching a dummy app. This allows us to detect if there are any launch watchdogs.
Therefore, for consistency, all measurements are done with the simulator already open.
In the case of the AppLaunchTime test, we build the app with the default config and launch it. It's automatically killed by the simulator
because it does not have a valid entry point but this is fine because it also kills the process and lets us stop the stopwatch.
We then simply log the time performance.
The ProjectDir could exist under certain circumstances (e.g. referenced assemblies are being copied to the Mac in the same folder path that those are located in Windows) so we cannot assume the existence or not of ProjectDir means the build comes from VS.
The only way to ensure we're building from VS is to check the SessionId parameter.
https://bugzilla.xamarin.com/show_bug.cgi?id=44724
SDK assemblies might contain P/Invokes to libmono, but unless we link with
mono (which we don't do if we're not embedding mono), the native linker will
complain if we ask it to keep those symbols (using `-u symbol`).
So don't look for __Internal P/Invokes in SDK assemblies in that case.
https://bugzilla.xamarin.com/show_bug.cgi?id=45902
The recent BTLS changes causes trouble for both XI and XM,
which should be fixed with this bump:
commit mono/mono@78619b1580
Author: Alexander Köplinger <alex.koeplinger@outlook.com>
Date: Tue Oct 25 18:44:33 2016 +0200
[System] Don't build managed BTLS code on monotouch
After 2fb07d6c6d5b3915ef4665391febbb7b8be09fb5 BTLS can be used as a shared lib,
but this caused an issue in some monotouch tools which grepped the P/Invokes for `__Internal`
since these icalls wouldn't resolve on monotouch since BTLS is disabled there.
Instead, we now completely leave out building the managed parts of BTLS when
BTLS is not enabled.
(cherry picked from commit db21455da9d74354b75accafc4e8e3c21466f048)
This bump also includes the fix for #45847:
commit mono/mono@c023b2b30a
Author: Rolf Bjarne Kvinge <rolf@xamarin.com>
Date: Mon Oct 24 19:50:16 2016 +0200
[System] Remove any CFNetwork usage from the watchOS profile. Fixes#45847.
The MacProxy class uses CFNetwork, but since CFNetwork is not a public
framework on watchOS, we can't use it.
So remove MacProxy completely (it only contains internal classes), and throw
PlatformNotSupportedException in any API that used it (the managed networking
stack is not supported on watchOS anyway, so this should be safe).
https://bugzilla.xamarin.com/show_bug.cgi?id=45847https://bugzilla.xamarin.com/show_bug.cgi?id=45902https://bugzilla.xamarin.com/show_bug.cgi?id=45847
commit mono/mono@c023b2b30a
Author: Rolf Bjarne Kvinge <rolf@xamarin.com>
Date: Mon Oct 24 19:50:16 2016 +0200
[System] Remove any CFNetwork usage from the watchOS profile. Fixes#45847.
The MacProxy class uses CFNetwork, but since CFNetwork is not a public
framework on watchOS, we can't use it.
So remove MacProxy completely (it only contains internal classes), and throw
PlatformNotSupportedException in any API that used it (the managed networking
stack is not supported on watchOS anyway, so this should be safe).
https://bugzilla.xamarin.com/show_bug.cgi?id=45847
Rolf Bjarne Kvinge
Chris Hamons
Sebastien Pouliot
Manuel de la Pena
Vincent Dondain
Sebastien Pouliot
Emanuel