Some are no longer part of the SDK (or converted into new ones
at build time), others were new (and missing).
A full list of attributes and their usage frequency in what we ship can
be seen in https://gist.github.com/spouliot/ca03c6da7d4d75670ca77749350eb8a2
Also update tests: no need to check for removals of stuff that does not
exists anymore.
Always add `libmono-profiler-log.dylib` if profiling is enabled and we
are building with dynamic libraries. The profiler code is not (meant to
be) shipped so it can be added even without a `Frameworks` directory.
This fix debugging too (if profiler is enabled) since the library was
linked (even if it was not included).
Fix https://github.com/xamarin/xamarin-macios/issues/8470
Co-authored-by: Sebastien Pouliot <sebastien.pouliot@microsoft.com>
The fact that the mobile profile allows linking doesn't mean it should be done
(it doesn't actually link because we run the registrar before linking happens,
but this way the code is less confusing and there are no unnecessary
differences between full and mobile).
`monotouch-glue.m` was replaced a while ago and the new code does not
need `Class.LookupFullName` to be preserved in debug builds.
Also `PreserveType` was unused code (left from even older times?)
Always add `libmono-profiler-log.dylib` if profiling is enabled and we
are building with dynamic libraries. The profiler code is not (meant to
be) shipped so it can be added even without a `Frameworks` directory.
This fix debugging too (if profiler is enabled) since the library was
linked (even if it was not included).
Fix https://github.com/xamarin/xamarin-macios/issues/8470
The native methods xamarin_get_[generic_]method_from_token are a bit unusual
in that they return an actual GCHandle. This is for performance reasons, since
in some cases their return value is passed as parameters to other function
calls to managed code, in which case we need the GCHandle. This way we avoid
round-tripping a GCHandle multiple times.
The previous pattern would match the output files we created from processing
these directories, and somehow the pattern would match such a file (even
though the pattern should only be executed before doing any processing, when
those files don't exist yet, so I don't know exactly why this is happening),
leading us to try to process those files as if they were directories with
sample data in, with the predictable (disastrous) result.
Fixes https://github.com/xamarin/maccore/issues/2202.
xamarin-storage can not be reachable or a network issue might happen
when we try to provision the dependencies. In that case, skip those
tasks that are skipped when we cannot provision the certs.
The provisioning dependencies will only execute in the provisioning
profiles was successful, therefore, the if statement is not stepping in
any value that was set by the profiles step.
Add timeouts to the steps to catch possible issues when a step takes
longer than expected. Numbers have been taken from common runs and
rounded up a little to have some buffer.
Not an experiment anymore - it works as expected.
This half-remove the optimization option (it must remain there to avoid
breaking all projects that have it defined) but it will always be `true`
so `Xamarin.Forms.Platform.iOS.dll` will **always** be considered as SDK
code by the linker.
Fix https://github.com/xamarin/xamarin-macios/issues/8407
* Rearrange files in Xamarin.Mac a bit to ease code sharing between mmp and
mtouch, by putting mono's static and dynamic libraries in
/Library/Frameworks/Xamarin.Mac.framework/Versions/Current/Sdks/Xamarin.macOS.sdk
to match how Xamarin.iOS does it.
* Don't use 'usr' as an intermediate directory. This removes another special
case.
* Share many of the functions and properties that return specific directories,
and document (as comments) what each function/property is supposed to
return.
* [mtouch] Handle a failure to launch the native linker better by showing better error messages.
dotnet will throw a Win32Exception if the command line is too long, so handle
that scenario. Also handle any other Win32Exceptions and show a better error
message.
* Make MT5217 an error to avoid multiple potentially confusing errors.
Cecil has a fall-back mode where it looks in the GAC / system mono for
assemblies when failing to find them elsewhere. This is not the expected
behavior when using Xamarin.Mac in the Full/XM mode, because then we should
only resolve to assemblies shipped with Xamarin.Mac.
Unfortunately doing so will break apps (our own tests break), so instead
change our resolution to be explicit about where we find assemblies, and if we
find assemblies in the GAC / system mono when we're not supposed to, then show
a warning.
Also add a fall-back mechanism, where we use the old logic instead, in case
the new logic is not 100% compatible with the old one.
This showed up when I tried to port mmp to dotnet, because then Cecil stopped
looking in the GAC / system mono for assemblies (Cecil has a special case when
running on Mono to look in Mono's GAC), and tests started failing.
Goals
* Reflect Apple nullability annotations in our bindings using C#8
* No warnings when building bindings
Non-Goals
* Update (add or fix) `[NullAllowed]` to match Apple headers (next phase)
* Make the generator or internal code fully nullable aware (`nowarn` is used)
Notes
* Apple's own annotations are not 100% accurate :(
* Where known issue exists we have _fixed_ our attributes to match reality :)
* We also do additional null-checks internally that might seems not required (better safe than sorry).
Rolf Bjarne Kvinge
Sebastien Pouliot
Sebastien Pouliot
Manuel de la Pena