* Adding PencilKit to the src
* forgot the mac constants
* adding PencilKit and fixed whitespace
* removing whitespace
* removed mac capabilities and added ignore for PencilKit.todo
* removed newline
* added the iOS-PencilKit.ignore file
* removed pencilkit.todo
* adding DesignatedDefaultCtor
No change in beta 2
This enable PushKit on watchOS and macOS.
Availability macros suggest this is available on tvOS 13 but the
headers are not in the tvOS SDK (at least in beta 2)
No change in beta 2
This enable some API in macOS. Headers are now present and some types are
marked as unavailable on macOS - but, sadly, nothing got marked as new
for 10.15 :|
There's no change in watchOS SDK headers... but they are marked as
available (to watchOS) inside iOS, tvOS and macOS. Not a new situation
and IIRC we reported it before (will check and report again if needed)
Archive Utility compresses into a directory specified by one of its
preferences, so we can't really say for sure where it will put the extracted
xip.
This is of course all sorts of fun, except none of the good ones.
So use the command-line xip utility to extract the xip instead, which is
documented to extract into the current directory.
The reason we didn't use the 'xip' tool from the beginning is that when Apple first started shipping Xcode as xips, the --expand option wasn't documented.
This boils down to the makefile-generation code having the information it
needs (and that information being correct).
This fixes running of tests on other macOS bots (older/newer), because now we
can build the test package again.
* [UIKit] Partial update to Xcode 11 Beta 1 and 2 - Part 1 of ?
Adds new classes included in Xcode 11 Beta 1 and 2, all stuff
included in this PR is up to date with Beta 2.
* Fix whitespace.
* Add tvOS availability attributes.
* UNNotificationResponse is public, it just need a using.
* Update xtro.
* [tests/.gitignore] Update ignored files
Avoid new generated csprojs
```
tests/apitest/apitest-unified-32.csproj
tests/apitest/apitest-unified.csproj
tests/apitest/apitest-unifiedXM45-32.csproj
tests/apitest/apitest-unifiedXM45.csproj
tests/introspection/Mac/introspection-mac-unified-32.csproj
tests/introspection/Mac/introspection-mac-unified.csproj
tests/linker/mac/dont link/dont link-mac-unified-32.csproj
tests/linker/mac/dont link/dont link-mac-unified.csproj
tests/linker/mac/dont link/dont link-mac-unifiedXM45-32.csproj
tests/linker/mac/dont link/dont link-mac-unifiedXM45.csproj
```
* Implement feedback
* More feedback
* [Tests] Fix Apple's lies in headers for tvOS
Whatch is fine
* adding Sound Analysis
* set up error domain and added CMTimeRange for all platforms except watch
* removed whitespaces
* removed more whitespaces
* edited framework files and constants. Changed header names and added todo files
* Apply feedback
* fixing head and skipping functions with class issues
* fixing spacing-tab issues
* [Network] Improve bindings for NWProtocolMetadata.
It turns out the NWProtocolMetadata can contain metadata for different
protocols (Ip/Tls/Tcp). This is important; if someone tries to get a value for
one protocol and the metadata is for another protocol, then they invoke the
wrath of superior beings who will smite that poor someone with uninitialized
memory.
At that point there's not much left but to pray.
I don't like to depend on divine intervention, so I've modified the API here
to check if the metadata's protocol is the required type for the native API
we're calling, and if the check fails, we throw a nice and dependable managed
exception.
This is a functional breaking change; but if there are any lost souls who
likes to pray, they can always re-implement the P/Invokes themselves and skip
the sanity checks.
In addition I've renamed a few properties whose name didn't clearly specify
which protocol type they operate on.
Ref: Apple feedback FB6155967.
Ref: https://trello.com/c/1TW0BSKJ/145-fb6155967-nwipcreatemetadata-returns-uninitialized-metadata-in-ios-13
* Fix casing in exception message.
* [tests] Adjust the SecProtocolMetadataTest according to new knowledge about the Network API.
* Fix alternative property name in obsolete attribute.
Re-running the same UnifiedTestConfig instance with just some of the
configuration changed doesn't work as expected, because in subsequent builds
there are files already in the build directory, and things break in unexpected
ways.
So create a new UnifiedTestConfig instance for every test variation.
* [builds] Build the BCL test assemblies. Fixes#6261.
Build the BCL test assemblies and copy them where xharness expects them to be.
Fixes https://github.com/xamarin/xamarin-macios/issues/6261.
* [builds] Copy nunitlite.dll to where it's expected too.
Currently we execute most of the same logic both during the configure phase
and when running tests, and the Harness.Mac value is only set in the configure
phase.
While it doesn't matter right now, this makes sure there aren't any future
surprises in this area, since otherwise we could end up with different
behavior between the configure phase and when running tests.
Harness.AutoConfigureMac now loads all the mac test projects both when
configuring and running tests, the only difference is that the test projects
that must be generated are only generated when configuring. This means that
the Harness.MacTestProject list contains the exact same test projects both
when configuring and when running tests.
This made it possible to remove logic to clone (mac) test projects the Jenkins
class (since Harness.MacTestProjects contains all the test projects already).
Consolidate logic to generate (mac) test projects:
* First we generate BCL and mono-native projects from their templates.
* Then we generate Full/System variations of any project that needs it.
This way we can remove logic to generate Full/System variations from the logic
to generate BCL/mono-native projects, which means less duplicated (and less
confusing) code.
To this purpose, significant changes were required:
* MacTestProject.TargetFrameworkFlavor has been modified to contain a bit mask
of the variations to generate.
* MacMonoNativeInfo has been significantly simplified, and some of the
generated code has been moved to the actual template instead.
* Some project generation (in MacTarget) to make things work as expected.
Fixes https://github.com/xamarin/xamarin-macios/issues/6322.
* Share code with GetInfoPListInclude to find the same Info.plist nodes, so
that FixInfoPListNode also finds existing nodes whose names isn't
"Info.plist".
* Add support for specifying the new Info.plist name.
Rename TestPlatform fields to be more in line with the rest of the code, and
drop the Unified prefix, since everything is Unified now.
* Unified -> Modern
* UnifiedXM45 -> Full
* UnifiedSystem -> System
Many people are running into problems building xcode11 because they have to
"./configure --disable-packaged-mono" first.
So disable the packaged mono by default (and add a way to enable it again
manually with "./configure--disable-packaged-mono=no").
* Bump VSMac to 8.1.0.2742 to fix msbuild issues (#6279)
* Bump VSMac to 8.1.0.2742 to fix msbuild issues
This is required to get the support for the msbuild `ToolsVersion`
change from `15.0` to `Current`.
* [tests][msbuild] Fix Binding resources test with updated msbuild
Test failure with updated msbuild and vsmac 8.1:
```
Xamarin.iOS.Tasks.NativeReferencesNoEmbedding("iPhone").ShouldNotUnnecessarilyRebuildBindingProject(True)
Binding project build did not create package?
Expected: True
But was: False
at Xamarin.iOS.Tasks.NativeReferencesNoEmbedding.ShouldNotUnnecessarilyRebuildBindingProject (System.Boolean framework) [0x000a0] in <74b8f7d8a53e40109916d305bb4d7403>:0
at (wrapper managed-to-native) System.Reflection.RuntimeMethodInfo.InternalInvoke(System.Reflection.RuntimeMethodInfo,object,object[],System.Exception&)
at System.Reflection.RuntimeMethodInfo.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo cul
ture) [0x0006a] in <0519fa732e8845b6a809ce9180f541db>:0
```
The test builds the project multiple times. Before the 3rd build, the project
file's timestamp is updated and expects that the binding package will be
rebuilt. But it is not, because the target `_CreateBindingResourcePackage`
doesn't depend on that project file. So, add that to the target inputs.
* [nuget] Use xibuild to run nuget
Fix errors seen during `nuget restore` for tests:
```
Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/xammac_tests/xammac_tests.csproj(213,3): error MSB4024: The imported project file "/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Mac/Xamarin.Mac.CSharp.targets" could not be loaded. Could not find file "/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Mac/Xamarin.Mac.CSharp.targets"
```
* [xibuild] Fix incorrect mscorlib.dll being used (#6068)
* [xibuild] Fix incorrect mscorlib.dll being used
The `GuiUnit_NET_4_5` project, when built with `xibuild` uses the wrong `mscorlib.dll`.
From https://github.com/xamarin/xamarin-macios/issues/5760#issuecomment-472457202 :
```
- mscorlib.dll is being used from mono/4.5 and the other system assemblies are from mono/4.5-api
- GuiNet* project is built with xibuild
What is happening here is:
xibuild sets[1] `SetToolsetProperty ("TargetFrameworkRootPath", FrameworksDirectory + Path.DirectorySeparatorChar);`
which points to `/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/xbuild-frameworks`.
This causes $(FrameworkPathOverride) to be set[2] to `/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/xbuild-frameworks/.NETFramework/v4.5`,
but that doesn't have a mscorlib.dll, so it gets reset[3] to /Library/Frameworks/Mono.framework/Versions/5.22.0/lib/mono/4.5/.
If we don't set TargetFrameworkRoothPath, then we get `FrameworkPathOverride = /Library/Frameworks/Mono.framework/Versions/5.22.0/lib/mono/4.5-api`,
causing `_ExplicitReference=/Library/Frameworks/Mono.framework/Versions/5.22.0/lib/mono/4.5-api/mscorlib.dll`(correct one) to be used.
```
Fixes https://github.com/xamarin/xamarin-macios/issues/5760
1. https://github.com/xamarin/xamarin-macios/blob/master/tools/xibuild/Main.cs#L209
2. https://github.com/mono/msbuild/blob/xplat-master/src/Tasks/Microsoft.Common.CurrentVersion.targets#L79
3. https://github.com/mono/msbuild/blob/xplat-master/src/Tasks/Microsoft.Common.CurrentVersion.targets#L84
* Revert "Workaround https://github.com/xamarin/xamarin-macios/issues/5760 in generator csproj"
This reverts commit 9bd927bb7f.
The previous commit for xibuild removes the need for this.
* [xibuild] Handle "incorrectly" cased msbuild property names (#6202)
msbuild property names are case insensitive. While generating the custom
app.config, in `SetToolsetProperty(..)` we try to update the property if
it already exists. But the name lookup was case sensitive, thus causing
the lookup to fail, resulting in two entries for the same property name
differing only in case. Eg. `MSBuildSDKsPath` vs `MSBuildSdksPath`.
Fixed to ignore case.
Fixes https://github.com/mono/mono/issues/14765 .
Rolf Bjarne Kvinge
TJ Lambert
Sebastien Pouliot
Sebastien Pouliot
Alex Soto
Manuel de la Pena
monojenkins