* [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
* NSMetadataItem initWithURL: is 10.9+ so we can't run this test on
earlier bots;
* NSRunningApplication.CurrentApplication.BundleUrl is 10.10 and it
seems wrench bots don't like it;
* Added missing helper properties for iOS
* Made NSItemDownloadingStatus a "smart enum", i.e. field aware;
* Disable default .ctor for XAMCORE_4_0, such instances are unusable;
* Added `initWithURL:` for macOS [2] as it made it easier to test the
changes since macOS it allows creating instances of `NSMetadataItem`
from an URL.
references:
[1] https://bugzilla.xamarin.com/show_bug.cgi?id=34248
[2] osx.unclassified:!missing-selector! NSMetadataItem::initWithURL: not bound