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.
Rolf Bjarne Kvinge
Sebastien Pouliot
Zoltan Varga
Manuel de la Pena
Chris Hamons
Sebastien Pouliot
Vincent Dondain