This optimization can be enabled when it's not possible to use the
managed linker (e.g. **Don't link**) or when the managed linker cannot
remove references to deprecated types that would cause an application
to be rejected by Apple.
References to the existing types will be renamed, e.g. `UIWebView` to
`DeprecatedWebView`, in every assemblies.
The type definition is also renamed (for validity) and all custom
attributes on the types and their members will be removed.
Code inside the members will be replaced with a
`throw new NotSupportedException ();`.
The msbuild test app `MyReleaseBuild` has been updated to test that the
optimization is working as expected (device builds are slow so reusing
this test has little impact in test time).
Basically the test ensure that `UIWebView` is used and cannot be removed
by the compiler (optimization) or the managed linker (since it's
referenced). Since the optimization is enabled then we can `grep` then
final `.app` directory to ensure there's no mention of `UIWebView` inside
any of the files that would be submitted.
The application can be run, by itself, and will turn green if OK, red if
`DeprecatedWebView` can't be found (skeleton replacement for `UIWebView`)
or orange if a `NotSupportedException` is thrown.
Finally introspection tests have been updated to skip over the deprecated
(and renamed) types. It should not be an issue right now, since this
optimization is not enabled by default, but it made testing easier.
This is a case of NSString enum extensibility - even if this framework does not use the usual `NS_EXTENSIBLE_STRING_ENUM` macro (which is recent and have not been applied for all framework / headers).
Minimally we need to provide alternative, weakly typed, `NSString`-based API wherever the (extensible) enums types are used. Not the best API (even if we can minimize it's use with `[EditorBrowsable (EditorBrowsableState.Advanced)]`) but C# enums can't be extended this way.
Also, even if less urgent, we need to make the enum-generated helper aware of the extensibility so they do not throw, making it easier to mix strongly and weakly typed code (instead of choosing one over the other).
Taking the first step for `xcode92` with the enum-backed constants in HomeKit, i.e.
* HMAccessoryCategoryType
* HMCharacteristicType
* HMServiceType
* HMSignificantEvent
Reference
https://bugzilla.xamarin.com/show_bug.cgi?id=60303
* [tests] WeakSignificantEvent is a weakly typed alternative (not a weak argument semantic)
This reduce the metadata size and this information, even if part of the
header files, is not required (as some types are just not refcounted)
E.g.
public bool MicrophoneEnabled {
[Export ("isMicrophoneEnabled", ArgumentSemantic.UnsafeUnretained)]
should be
public bool MicrophoneEnabled {
[Export ("isMicrophoneEnabled")]
This could have been done in different places but not generating them has
the smallest impact versus:
1. Check bindings input and report them as errors
- con: break existing binding code;
- con: sharpie outputs them;
2. Removed by the linker
- con: linking not always enabled, e.g. 3rd party bindings
- con: extra logic == extra time for each build
Generator diff
https://gist.github.com/spouliot/cc36e68bf7bd6097064ed6ba0bb3275a
Those tests needs to be run with the linker disabled since they use
reflection for most of their work.
The original dontlink (for linker tests) was becoming too large in
some configuration (e.g. tvOS release with bitcode) but this was
due to other BCL assemblies (not the introspection tests)
Rolf Bjarne Kvinge
Sebastien Pouliot