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>
We already have a few attributes that can specify the native name for a type, whenever the native name doesn't match the managed name:
* [Register ("DifferentClassName"): specifies the Objective-C class name
* [Native ("DifferentEnumName")]: specifies the Objective-C enum name (and also that it's a native-sized enum)
* [Protocol ("DifferentProtocolName")]: specifies the Objective-C protocol name
* [Category ("DifferentCategoryName")]: specifies the Objective-C category name
Unfortunately this leaves (at least) two cracks:
* Objective-C structs.
* Objective-C enums which aren't native-sized.
So I'm adding a [NativeName] attribute for this purpose, and updating numerous
types to specify the native name (either using an existing [Native] attribute
for enums that already have one, or by adding a new [NativeName] attribute).
The static registrar needs to know the native name for such types, in case
they appear as parameter types in function signatures.
This also allows us to simplify xtro a bit, to not have a separate map of
managed name given a native name, because we can now build that map
dynamically.
Rename our product assemblies to:
* Microsoft.iOS.dll
* Microsoft.tvOS.dll
* Microsoft.macOS.dll
* Microsoft.MacCatalyst.dll
This makes it easy to distinguish between legacy Xamarin and .NET whenever the
product assembly is mentioned, and I've also chosen the platform part of the
name to match how the platforms are named elsewhere (this also makes it
possible to simplify our build logic, since we can remove a lot of special
casing).
Fixes https://github.com/xamarin/xamarin-macios/issues/13748.
* [xtro] Add support for Mac Catalyst. Fixes #10214.
Fixes https://github.com/xamarin/xamarin-macios/issues/10214.
* Update xtro.
* Bump Objective-Sharpie.
* Delete .todo files for frameworks we don't support.
* And another one bites the dust.
* [xtro] Update.
We were using the managed name, e.g. `NSUrl`, instead of the native name,
e.g. `NSURL`, when dealing with categories.
To fix this we must resolve the type and this caused issues as other
assemblies (e.g. OpenTK) were not already loaded/cached and some type
could not be resolved (and this throw exceptions)
The runner now loads all assemblies before starting to visit them.
The fix solved a known issue (iOS-NetworkExtension.ignore), some API
that were already bound (common-Foundation.ignore) and also caught an
additional API where we missed a `[NullAllowed]` on a return value
Enabling this will ensure that future bindings (and Xcode updates that
change nullability information) are spotted right away.
The binding fixes are **not** complete, i.e. what was done was mostly
to debug the xtro rule and find corner cases. The backlog will be
_ignored_ so the builds won't fail.
* Not every old annotations have been migrated (work in progress, to be completed in another PR);
* Sanitation of the data files (e.g. removal of dupes and fixed, by Apple, entries) is done, but not automated (also a work in progress)
Even then this is immediately useful, i.e. better merged before 15.6 gets branched.
Rolf Bjarne Kvinge
Sebastien Pouliot
Chris Hamons
Timothy Risi