In iOS 13 it's no longer possible to get PACs from file:// urls (this is
explained in the release notes, so it's expected). So launch a local
httpserver and serve the PAC that way.
link-framework-1 ensures that we link away as many frameworks as possible.
Unfortunately there are things we can't link away when using the dynamic
registrar, so switch to testing the Release configuration instead, since that
automatically uses the static registrar (and the release configuration is the
better option to test anyway, since it's closer to what customers use to
release).
This should let us provide a nicer API for the GM change about
`CBManager authorization` moving from an instance to a static
property (in all but iOS 13.0 / watchOS 6.0)
With xcode11 GM the tvOS and macOS headers drifted from the iOS ones.
It's not clear if they should be different (hopefully not) or if iOS
has been forgotten...
While waiting for Apple's feedback (and the avoid breaking changes)
the new (conflicting) enum values are not included.
Internal reference: https://github.com/xamarin/maccore/issues/1960
For some reason (likely to be added back later ?) Xcode 11 GM removed
most of new macOS 10.15 API for FileProvider.
So instead of deleting stuff this uses a lot of `[NoMac]` even if some
API are actually not part of any platform anymore, e.g. you can see the
following line in the GM headers
```
API_UNAVAILABLE(watchos, tvos) API_UNAVAILABLE(ios, macos)
```
* [msbuild] Use task assembly path via a property
Xamarin.Mac.Common.ImplicitFacade.msbuild.targets: $(_NETBuildExtensionsTaskAssembly)
* [msbuild] Fix path to NET.Build.Extensions task assembly
.. which is no longer available for `net46`. Instead use the latest
`net472` path.
The incorrect path effectively disabled the `GetDependsOnNETStandard`
task, causing the issue.
Partially fixes https://github.com/xamarin/xamarin-macios/issues/6552 .
* [msbuild] Fix XM builds which use netstandard libraries.
`Xamarin.Mac.Common.ImplicitFacade.msbuild.targets`:
`ImplicitlyExpandDesignTimeFacades` adds a reference to `netstandard.dll`
by expanding the facades, if any of the references depend on it. Usually,
this gets handled by msbuild SDKs but in case of XM, this doesn't happen
in all cases. So, we need to scan the references for a `netstandard`
dependency.
The `ResolveAssemblyReference` task does this for us and populates
`$(_DependsOnNETStandard)` property. If it does not, then we use
`GetDependsOnNETStandard` task to get the same information.
Issue:
- the target incorrectly uses `$(DependsOnNETStandard)` instead of
`($_DependsOnNETStandard)`.
- Fixing that means that condition `$(_DependsOnNETStandard) == ''` fails
whenever `ResolveAssemblyReference` task runs (setting the property
to `true` or `false`), causing `$(XM_DependsOnNETStandard)` to be unset.
- thus failing the following logic to expand the facades when `$(_DependsOnNETStandard) == true`
So, we use the `$(_DependsOnNETStandard)` as the default value for
`$(XM_DependsOnNETStandard)`, so that it is correctly set to `true`,
irrespective of how we got that information, allowing us to correctly
expand facades when required.
Partially fixes https://github.com/xamarin/xamarin-macios/issues/6552 .
* [msbuild] Fix XI builds which use netstandard libraries.
`Xamarin.iOS.Common.targets`:
Issue:
- the target incorrectly uses `$(DependsOnNETStandard)` instead of
`($_DependsOnNETStandard)`.
- Fixing that means that condition `$(_DependsOnNETStandard) == ''` fails
whenever `ResolveAssemblyReference` task runs (setting the property
to `true` or `false`), causing `$(XI_DependsOnNETStandard)` to be unset.
- thus failing the following logic to expand the facades when `$(_DependsOnNETStandard) == true`
So, we use the `$(_DependsOnNETStandard)` as the default value for
`$(XI_DependsOnNETStandard)`, so that it is correctly set to `true`,
irrespective of how we got that information, allowing us to correctly
expand facades when required.
Prompted by: https://github.com/xamarin/xamarin-macios/issues/6552
We ship a default, pre-built, simlauncher for iOS simulator applications.
This speeds up compilation for the default (non linked) simulator builds
quite a lot (no call to `clang` is needed). However it force us to keep
track of frameworks manually - `mtouch` can track them but requires
calling clang/ld to finish things up (killing the optimization).
It's easy to forget some (new) frameworks since they can be loaded
dynamically (on demand) _most_ of the time. Sadly there are a few cases
where doing so cause (hard to diagnose) problems - so we can't depend
on them being loaded, correctly for us.
The new test case loads the `otool -L` output (make when we build
simlauncher[32|64]-sgen) and compares it with mtouch's GetFramework
logic *and* with our namespaces (which is pretty close, with a few
exceptions, to the framework names). This will make it harder to
forget [weak] frameworks when adding new bindings :)
Fixes https://github.com/xamarin/xamarin-macios/issues/6951
* [registrar] Report a warning when the registrar export an abstract INativeObject type to Objective-C.
Exporting abstract types to Objective-C can lead to problems when at runtime
we're asked to create an instance of such a type (which we can't), so warn
when this happens.
This would have caught #6655, and the problems explained in #4969 as well.
Since this may trigger for code that's currently working fine, I'm making it a
warning instead of an error (which means adding some extra code to be able to
easily report warnings from the generator code).
* Don't assume a TypeReference can be successfully resolved every time.
* [msbuild] Use task assembly path via a property
Xamarin.Mac.Common.ImplicitFacade.msbuild.targets: $(_NETBuildExtensionsTaskAssembly)
* [msbuild] Fix path to NET.Build.Extensions task assembly
.. which is no longer available for `net46`. Instead use the latest
`net472` path.
The incorrect path effectively disabled the `GetDependsOnNETStandard`
task, causing the issue.
Partially fixes https://github.com/xamarin/xamarin-macios/issues/6552 .
* [msbuild] Fix XM builds which use netstandard libraries.
`Xamarin.Mac.Common.ImplicitFacade.msbuild.targets`:
`ImplicitlyExpandDesignTimeFacades` adds a reference to `netstandard.dll`
by expanding the facades, if any of the references depend on it. Usually,
this gets handled by msbuild SDKs but in case of XM, this doesn't happen
in all cases. So, we need to scan the references for a `netstandard`
dependency.
The `ResolveAssemblyReference` task does this for us and populates
`$(_DependsOnNETStandard)` property. If it does not, then we use
`GetDependsOnNETStandard` task to get the same information.
Issue:
- the target incorrectly uses `$(DependsOnNETStandard)` instead of
`($_DependsOnNETStandard)`.
- Fixing that means that condition `$(_DependsOnNETStandard) == ''` fails
whenever `ResolveAssemblyReference` task runs (setting the property
to `true` or `false`), causing `$(XM_DependsOnNETStandard)` to be unset.
- thus failing the following logic to expand the facades when `$(_DependsOnNETStandard) == true`
So, we use the `$(_DependsOnNETStandard)` as the default value for
`$(XM_DependsOnNETStandard)`, so that it is correctly set to `true`,
irrespective of how we got that information, allowing us to correctly
expand facades when required.
Partially fixes https://github.com/xamarin/xamarin-macios/issues/6552 .
* [msbuild] Fix XI builds which use netstandard libraries.
`Xamarin.iOS.Common.targets`:
Issue:
- the target incorrectly uses `$(DependsOnNETStandard)` instead of
`($_DependsOnNETStandard)`.
- Fixing that means that condition `$(_DependsOnNETStandard) == ''` fails
whenever `ResolveAssemblyReference` task runs (setting the property
to `true` or `false`), causing `$(XI_DependsOnNETStandard)` to be unset.
- thus failing the following logic to expand the facades when `$(_DependsOnNETStandard) == true`
So, we use the `$(_DependsOnNETStandard)` as the default value for
`$(XI_DependsOnNETStandard)`, so that it is correctly set to `true`,
irrespective of how we got that information, allowing us to correctly
expand facades when required.
Prompted by: https://github.com/xamarin/xamarin-macios/issues/6552
Rolf Bjarne Kvinge
Waleed Chaudhry
Alex Soto
Manuel de la Pena
Vincent Dondain
Whitney Schmidt
Sebastien Pouliot
monojenkins
Chris Hamons
Ankit Jain