Something in VSTS changed, and now fake branch names don't work anymore.
So instead use real branch names (and for pull requests I've created a
'pull-request' branch we can use).
- Fixes#4441: [generator] Binding with return value of Class [] do not do the right thing
(https://github.com/xamarin/xamarin-macios/issues/4441)
- Turns out the logic to put INativeObjects into NSArrays was already in place. We simply needed to add the missing (IntPtr handle, bool owns) overload to `Class`.
- Uncommented AppKit `registeredImageRepClasses` since it was using `Class []`. Tested locally and it works fine.
- Reimplemented `Foundation`'s `NSSecureUnarchiveFromDataTransformer` and its test which were also using `Class []`.
If the Http Client value isn't set in the csproj, we should default to `NSUrlSessionHandler` which is also what the Xamarin.iOS Analysis rules try to enforce.
Fixes this HarnessException when all simulator tasks for an aggregated run
simulator task fails to build (i.e. there is nothing to run):
Harness exception for 'Tests for iOS_Unified32': System.InvalidOperationException: Sequence contains no elements
at System.Linq.Enumerable.First[TSource] (System.Collections.Generic.IEnumerable`1[T] source) [0x0000b] in /Users/builder/jenkins/workspace/build-package-osx-mono/2018-04/external/bockbuild/builds/mono-x64/external/corefx/src/System.Linq/src/System/Linq/First.cs:16
at xharness.AggregatedRunSimulatorTask+<ExecuteAsync>d__9.MoveNext () [0x00312] in /work/maccore/master/xamarin-macios/tests/xharness/Jenkins.cs:3582
--- End of stack trace from previous location where exception was thrown ---
at xharness.TestTask+<RunInternalAsync>d__92.MoveNext () [0x00113] in /work/maccore/master/xamarin-macios/tests/xharness/Jenkins.cs:2352
* Store the minimum mono version for Xamarin.Mac in one place only (Make.config) and bump it to 5.14. Fixes#4120.
I've verified that we fail at launch of running on 5.12, while 5.14 works fine
(to launch at least), so the minimum system mono version is _at least_ 5.14.
Fixes https://github.com/xamarin/xamarin-macios/issues/4120.
* [mmp] Load mono's version file instead of using pkg-config to get mono's version.
pkg-config will only get three parts of the version, while the version file
has all four parts.
This is important, since we're now verifying the four parts of the version
file, and without loading those four from the system, we'll fail builds like
this:
error MM0001: This version of Xamarin.Mac requires Mono 5.14.0.136 (the current Mono version is 5.14.0).
because the three part version's fourth number is assumed to be 0.
* Only verify mono runtime version when running with system/dynamic mono.
There should be no need to verify the mono runtime version when embedding mono:
* If it's a mono we're shipping, something very bad happened in our
build/package for it to be an invalid mono.
* If it's a system mono that's being embedded, then we verify in mmp at build
time.
In the first scenario (a mono we're shipping), the problem is that the mono
we've built does not report back the full version number (with four parts) [1],
which means we'll fail any check whose requirements are identical for the
first three parts, and non-zero for the last.
[1] The fourth part of the version number is created/calculated when packaging
mono, and we're not packaging it.
Fixes an issue where MTouch test would seemingly fail immediately:
Failure: Execution timed out after 0 minutes.
when it's just saying that it failed out after [2 hours and] 0 minutes.
Fix it by showing the total number of minutes in the failure message.
This is more future-proof, since the list of packages may change, or there may
be other tasks that need doing in addition to installing packages.
Fixes https://github.com/xamarin/maccore/issues/952.
This is a backport of the PRs #4662 and #4681.
* [src] Fix bgen build to support custom output directory for api comparison. Fixes maccore#959.
This broke in 87c27e0c3f, which made bgen
compile using a project file (I forgot to verify that it wouldn't affect the
API comparison, and the PR build didn't complain because problems with the API
comparison typically show up in subsequent PRs).
https://github.com/xamarin/maccore/issues/959
* [src] Fix response file usage to use BUILD_DIR, so that API comparison can redirect as expected.
* [src] Fix generation of generator.csproj's dependency file to use BUILD_DIR, so that API comparison can redirect as expected.
* [src] Fix bgen.exe's dependencies.
* Use full paths to create-makefile-fragment.sh.
- Fixes#4694: NSString.GetLocalizedUserNotificationString not working with .stringsdict files
(https://github.com/xamarin/xamarin-macios/issues/4694)
- Updated `UNNotificationCategory.FromIdentifier`'s iOS 12 overload to take a `NSString` category format to preserve localization.
- Change `GetLocalizedUserNotificationString` to only use NSString to preserve localization (similar fix to https://github.com/xamarin/xamarin-macios/pull/3266).
This makes it possible to build mmp (the partial static registrar code) with
the wrong system Xcode (which is not supported, but that doesn't mean we can't
try to make it mostly work to ease our lives).
causing
```
Introspection.MacApiCtorInitTest.ApiCtorInitTest.DefaultCtorAllowed: 1 potential errors found in 925 default ctor validated:
Default constructor not allowed for CoreData.NSCoreDataCoreSpotlightDelegate : Could not create an native instance of the type 'CoreData.NSCoreDataCoreSpotlightDelegate': the native class hasn't been loaded.
It is possible to ignore this condition by setting ObjCRuntime.Class.ThrowOnInitFailure to false.
```
when running intro for mac unified 32 bits
Rolf Bjarne Kvinge
Vlad Brezae
Manuel de la Pena
Vincent Dondain
Sebastien Pouliot
Curtis Wensley
Marek Safar
Sebastien Pouliot