… supporting XPC on File Provider instance
File Provider Service can act as an standalone XPC that you can
establish the connection with.
To open up the capability this new signature has to be exposed
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Co-authored-by: Alex Soto <alex@alexsoto.me>
* The 'copyCGImageAtTime:actualTime:error:' selector is deprecated, so
replicate that.
* Bind the 'generateCGImageAsynchronouslyForTime:completionHandler:'
selector.
Fixes parts 1 and 2 of https://github.com/xamarin/xamarin-macios/issues/18452.
Change all null checking expressions to use 'is null' and 'is not null'
instead of '== null' and '!= null'.
This was mostly done with sed, so code can probably be improved in many
other ways with manual inspection, but that will come over time.
Also add code to the autoformat script to automatically fix these issues in the future.
The original implementation for the MidiCIDeviceIdentification struct uses
public byte[] fields with a MarshalAs attribute to set the array size. This is
not blittable, but unfortunately these are _public_ fields, which means we
can't change them.
Instead introduce an internal intermediate struct, which is blittable, and
convert to and from this struct when marshalling to and from native code.
Then in XAMCORE_5_0 we can make the intermediate struct public and use it
instead of the non-blittable struct everywhere.
Provided manual binding of AVAudioPlayer::initWithContentsOfURL:error: and AVAudioPlayer::initWithData:error: to prevent an issue where AVAudioPlayer::FromData() and FromUrl() do not throw exceptions when returning null.
Fixes#16229
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Add support to xtro-sharpie for where to look for referenced assemblies, and
adjust assembly resolution to only look in those directories.
This makes sure xtro-sharpie loads the expected references, and fixes a
problem where the (broken) assembly resolution wouldn't find a .NET assembly
because it doesn't exist in legacy Xamarin (where it would look by default).
Fixes this problem that showed up in a different PR (due to new .NET API
referencing the System.Runtime.Loader assembly, which doesn't exist in legacy
Xamarin):
mono64 --debug bin/Debug/xtro-sharpie.exe --output-directory api-annotations-dotnet appletvos16.1-arm64.pch ../../_build/Microsoft.tvOS.Runtime.tvos-arm64/runtimes/tvos-arm64/lib/net7.0/Microsoft.tvOS.dll
Mono.Cecil.AssemblyResolutionException: Failed to resolve assembly: 'System.Runtime.Loader, Version=7.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
at Mono.Cecil.BaseAssemblyResolver.Resolve (Mono.Cecil.AssemblyNameReference name, Mono.Cecil.ReaderParameters parameters) [0x000ff] in C:\src\cecil\Mono.Cecil\BaseAssemblyResolver.cs:172
at Mono.Cecil.BaseAssemblyResolver.Resolve (Mono.Cecil.AssemblyNameReference name) [0x00000] in C:\src\cecil\Mono.Cecil\BaseAssemblyResolver.cs:117
at Mono.Cecil.DefaultAssemblyResolver.Resolve (Mono.Cecil.AssemblyNameReference name) [0x0001d] in C:\src\cecil\Mono.Cecil\DefaultAssemblyResolver.cs:33
at Mono.Cecil.MetadataResolver.Resolve (Mono.Cecil.TypeReference type) [0x0003a] in C:\src\cecil\Mono.Cecil\MetadataResolver.cs:110
at Mono.Cecil.ModuleDefinition.Resolve (Mono.Cecil.TypeReference type) [0x00000] in C:\src\cecil\Mono.Cecil\ModuleDefinition.cs:748
at Mono.Cecil.TypeReference.Resolve () [0x0000f] in C:\src\cecil\Mono.Cecil\TypeReference.cs:280
at Extrospection.Helpers.GetName (Mono.Cecil.MethodDefinition self) [0x00051] in /Users/rolf/work/maccore/whatever/xamarin-macios/tests/xtro-sharpie/Helpers.cs:332
at Extrospection.DesignatedInitializerCheck.VisitManagedMethod (Mono.Cecil.MethodDefinition method) [0x00001] in /Users/rolf/work/maccore/whatever/xamarin-macios/tests/xtro-sharpie/DesignatedInitializerCheck.cs:43
at Extrospection.AssemblyReader.ProcessType (Extrospection.BaseVisitor v, Mono.Cecil.TypeDefinition type) [0x0002b] in /Users/rolf/work/maccore/whatever/xamarin-macios/tests/xtro-sharpie/Runner.cs:104
at Extrospection.AssemblyReader.Process () [0x0008e] in /Users/rolf/work/maccore/whatever/xamarin-macios/tests/xtro-sharpie/Runner.cs:93
at Extrospection.Runner.Execute (System.String pchFile, System.Collections.Generic.IEnumerable`1[T] assemblyNames, System.String outputDirectory) [0x001af] in /Users/rolf/work/maccore/whatever/xamarin-macios/tests/xtro-sharpie/Runner.cs:52
at Extrospection.MainClass.Main (System.String[] arguments) [0x0008f] in /Users/rolf/work/maccore/whatever/xamarin-macios/tests/xtro-sharpie/Program.cs:28
make: *** [.stamp-dotnet-classify-tvOS] Error 1
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
* If there's both an UnsupportedOSPlatform and ObsoletedOSPlatform attribute with
the same version, then remove the UnsupportedOSPlatform attribute. This is because
in the past we used [UnsupportedOSPlatform] + [Obsolete] to indicate that an API
is obsolete, but then the [ObsoletedOSPlatform] attribute was added, and we replaced
the [Obsolete] attributes with [ObsoletedOSPlatform] attributes, which makes the
[UnsupportedOSPlatform] attributes redundant/incorrect.
* If there's [UnsupportedOSPlatform] with a version or [ObsoletedOSPlatform] with
a version, then also add [SupportedOSPlatform] in a few cases.
* If there's an [UnsupportedOSPlatform] with a version for API that's obsolete/non-working,
then remove the version.
JonnHard
Rolf Bjarne Kvinge
Alex Soto
Haritha Mohan
dustin-wojciechowski