Make sure we don't run 'nuget restore' for test-mac.sln multiple times in
parallel by creating a separate make target that runs 'nuget restore', and
making every build-mac-* target depend on that target.
Fixes https://github.com/xamarin/maccore/issues/1122.
Most characters should now work, including emojis.
Except for double quotes, that turned out too ugly.
Workaround: don't create branches with double quotes in their names.
Fixes https://github.com/xamarin/xamarin-macios/issues/5097.
* [tests] Point MSBuild to the right Xamarin.Mac location when building packaged Xamarin.Mac tests. Fixes maccore#1115.
Fixes https://github.com/xamarin/maccore/issues/1115.
* [xharness] Ensure all makefile targets set the proper environment variables.
Since we don't require projects to contain an Entitlement.plist file we cannot use that as input, because if that file does not exist the CompileEntitlements target will be skipped. This target runs the CompileEntitlements task that generates a new Entitlements file, and that file is required to deploy the app to a device because it contains the application-identifier entitlement.
Fixes#5094
* MIN_OSX_SDK_VERSION: the minimum macOS version we support for running macOS apps.
* MIN_OSX_VERSION_FOR_MAC: the minimum macOS version we support for running XM/XI themselves.
Change our build to make sure the above is respected, and in particular:
* The mac32 and mac64 builds must use MIN_OSX_SDK_VERSION.
* The runtime/ build must use MIN_OSX_SDK_VERSION.
* The tools64 build should use MIN_OSX_VERSION_FOR_MAC.
Also document a bit better the various version variables.
Share all the code to find and verify Xcode between mtouch and mmp.
Also print out the actual product version when logging which Xcode was used
(to make it easier to detect if a beta version is in use).
- https://github.com/xamarin/xamarin-macios/pull/4980 and the mono branch merge both added it
- However both copies were not the same, one was conditional and one added an extra -u option
- This collapses them into one check
If the challenge is for basic authentication then try to get the
credentials for this authentication type.
Also handle multiple WWW-Authenticate headers, such as:
WWW-Authenticate: Negotiate, NTLM
If the credentials provided on the NSUrlSessionHandler are not
available for a specific authentication type, or if the authentication
method is not supported, then reject the protection space. This allows
the next authentication challenge to be sent to the DidReceiveChallenge
method. Also handle a null reference exception that could occur if
there were no credentials available for the authentication type.
- Fixes#5065: [Xcode10.1]Could not get traitsetID for iPhone11,6 error while building with Xcode10.1 and new iOS device
(https://github.com/xamarin/xamarin-macios/issues/5065).
- `actool` in Xcode 10.1 now outputs some `com.apple.actool.notices` (we might not have hit that before) and those make the task fail because we log them as errors (we shouldn't).
* Lower notice to LogMessage
Update other LogMessage to output "tool notice :"
Most of these changes are needed from VS to make incremental builds work.
The problem here is VS runs MSBuild on Windows and remotes (most of) the task executions to the Mac. Since MSBuild is running on Windows the inputs and outputs are checked there, but the output files won't be created on Windows unless those are explicitly declared as output ITaskItems of a task. VS don't copy every file created on the Mac back to Windows because that will increase the build time unnecessarily.
For instance, the _GenerateFrameworkDebugSymbols target was using the Info.plist file created by the dsymutil tool as output, but that file was not declared as ITaskItem output of the DsymUtil task so VS didn't know that file should be created on Windows.
This doesn't mean every task should have an output property declaring ITaskItems, but if you're writing a target that will use certain files as output those files should be output of one of the tasks that target is running.
Partial fix for https://dev.azure.com/devdiv/DevDiv/_workitems/edit/710309.
I'm not sure why we have an entry in our list of frameworks claiming that
iTunesLibrary was introduced in macOS 10.9, when we didn't have any bindings
for the library back then.
In any case we also have an entry for iTunesLibrary in our list of frameworks
claiming that iTunesLibrary was introduced in macOS 10.14.
I looked at some of Apple's documentation for the types in iTunesLibrary, and
they all claim to be introduced in macOS 10.13 [2].
And to make matters even more interesting, Apple's documentation for the
framework itself states the library is in
/Library/Frameworks/iTunesLibrary.framework, and ships with iTunes 11.0+ [1]
(which is introduced in 2012).
Then I looked at a macOS 10.14 machine, and the framework is available at
/System/Library/Frameworks/iTunesLibrary.framework, and
/Library/Frameworks/iTunesLibrary.framework is just a symlink there
(/System/Library/Frameworks/iTunesLibrary.framework does not exist on my macOS
10.13 machines, while /Library/Frameworks/iTunesLibrary.framework does). From
this I conclude that the framework was converted into a
system framework in macOS 10.14, and as such our claim that the framework was
introduced in 10.14 is at least somewhat right.
So treat iTunesLibrary as any other framework introduced in macOS 10.14, and
remove our (duplicated) framework entry for 10.9 (for which we didn't have any
bindings anyway).
Also fix the path to the framework, I'm wonder how this got past our tests in
the first place.
[1] https://developer.apple.com/documentation/ituneslibrary: "... located at /Library/Frameworks/iTunesLibrary.framework ... The iTunes Library framework is available to users running iTunes v11.0 or above."
[2] https://developer.apple.com/documentation/ituneslibrary/itlibrary?language=objc
While trying to debug an msbuild unit tests it was not possible to
successfully copy/paste the command from the execution log and
run it in a shell.
It's not that hard to run xharness and figure it out - but the
same can happen on bots (which could be harder).
So that little change prints out the host and xharness changes
to the environment variables to make copy/pasters life even
lazier :)
The task itself should not throw. An invalid argument is an error that
should (and is) reported by `btouch` itself (and the task picks it up).
This makes the error reporting much more useful and the way an exception
is reported, from Windows, is also confusing
```
MessagingRemoteException: An error occured on client Build4110732 while executing a reply for topic xvs/Build/4.11.0.732/execute-task/ClassLibrary1/6e85b94002fBTouch ArgumentNullException: Value cannot be null.
```
Unit tests added.
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/656983
* Add optional mono_dangerous_add_raw_internal_call to exports.t4
* Use mono_dangerous_add_raw_internal_call on watchOS for icall registration
Internal calls added with mono_dangerous_add_raw_internal_call run in GC Unsafe
mode under cooperative and hybrid suspend, whereas internal calls added with
mono_add_internal_call run in GC Safe mode since
mono/mono@5756ba4b46 in order for hybrid suspend
to be a transparent replacement for preemptive suspend (the old default). The
icalls in GC Unsafe mode have a responsibility not to block indefinitely
without manually performing a thread state transition to GC Safe mode, and in
return they avoid a thread state transition when the icall is invoked from a
managed method.
* [introspection] MPSCnnBinaryKernel's kernelHeight/kernelWidth are missing on iOS too.
* [introspection] CoreNFC is not even available on all devices.
Rolf Bjarne Kvinge
Alex Soto
Emanuel Fernandez Dell'Oca
Sebastien Pouliot
Bernhard Urban
Sam Schwarz
Chris Hamons
Matt Ward
Vincent Dondain
Sebastien Pouliot
Michiel Sioen
monojenkins
Marek Safar
Aleksey Kliger (λgeek)