* Update `SdkVersions.cs` after the latest Xcode 14.2 bump.
* Rename `[SdkVersions|ProductConstants].cs.in` to `[SdkVersions|ProductConstants].in.cs`.
This way the autoformatter makes sure it's formatted correctly.
* Change the generator to not write the version in SupportedOSPlatform
attributes unless it's greater than min OS version.
* Fix a few redundant Mac Catalyst availability versions.
* Uncomment the test to verify that availability attributes don't include
useless version information.
Fixes https://github.com/xamarin/xamarin-macios/issues/11029.
Port the availability attribute test from introspection to cecil-tests. It's much
easier and faster to test attributes using Cecil using a desktop executable than
having to execute a test app on each target platform.
This also means that we can make the ApiAvailabilityTest in introspection
legacy-only.
Ref: https://github.com/xamarin/xamarin-macios/issues/10834
This hasn't been a problem until now because we've always had tvOS attributes on
most API, but when bumping min OS versions for .NET 8, we'll also remove a lot of
redundant availability attributes. This would break a case where a type is unavailable
on all platforms except tvOS (but without any tvOS availability attribute), and then
we'd get the (implied) iOS (un)availability attribute.
MKRoadWidthAtZoomScale is a P/Invoke we decided to put in the MKOverlayView
class a long time ago.
This is problematic, because the P/Invoke is available on more platforms than
MKOverlayView (and the MKOverlayView class is deprecated, while the P/Invoke
is not), which it impossible to get the availability attributes right.
So instead move the P/Invoke to the MKOverlayRenderer class (but keep the old
code around until XAMCORE_5_0 for backwards compat reasons). The
MKOverlayRenderer class is the replacement for the deprecated MKOverlayView
class, and it's also available on all the platforms the P/Invoke is available,
so the availability attributes are now trivial.
A long time ago, Apple created WebKit bindings for macOS, and we bound those in the webkit.cs and WebKit/*.cs files. These were later deprecated in macOS 10.14.
A bit later (iOS 8.0 / macOS 10.10) Apple created new (and severely limited) WebKit API for both iOS and macOS, and since these were quite different/new, we bound them in wkwebkit.cs and WKWebKit/*.cs files.
However, the actual namespace for both is WebKit, which leaves us with a few special-cases in our code to handle the fact that we've bound the same namespace in different files/directories.
Unifying these implementations in webkit.cs and WebKit/*.cs, makes it possible to avoid these special cases.
I've also explicitly added No* availability attributes to the old and deprecated macOS bindings for all other platforms than macOS, in order to avoid more special-casing when it comes to availability attributes (and that logic is already complicated enough as it is).
It's automatically done in the linker's MSBuild logic.
Not only is it no longer necessary (hasn't been for a while), it'll be wrong
in .NET 8 after https://github.com/dotnet/linker/pull/3124.
We need parts of tools/common/SdkVersions.cs when building tests on Windows.
In order to simplify our Windows-life, we're going to check in the generated
SdkVersions.cs file, that way it won't have to be re-generated on Windows (the
logic is very make-based, and not easily executed on Windows).
However, parts of SdkVersions.cs would change every commit, which would make
the above solution rather annoying. So split out those parts into a new file
(ProductConstants.cs), which is still generated during the build (and not
checked in).
Unify the source code for NSAttributedStringDocumentAttributes between
iOS and maOS.
As a result, we're now exposing a few APIs on macOS that were previously
only exposed on iOS.
This PR might be easier to review commit-by-commit.
Dynamic libraries might be deployed in subdirectories such as libclrjit.dylib from the nuget package cefglue.common:
Contents/MonoBundle/CefGlueBrowserProcess/libclrjit.dylib
The library ID for that library should be: @executable_path/../MonoBundle/CefGlueBrowserProcess/libclrjit.dylib
Instead of: @executable_path/../MonoBundle/libclrjit.dylib
Beside the library ID being wrong, when it's combined with the nuget package microsoft.netcore.app.runtime.osx-x64 providing a library with the same name, both uses the same `ReidentifiedPath`, which can cause a failure in the InstallNameTool tasks that are run in parallel operating on the same temporary file.
The following patch uses the `RelativePath` for the tempory file used by `InstallNameTool` so that there are no clashes with other files with the same name deployed in other directories. It also uses the `RelativePath` to create the correct library id: @executable_path/../../Contents/MonoBundle/CefGlueBrowserProcess/libclrjit.dylib
Partially fixes https://github.com/xamarin/xamarin-macios/issues/15173 for this scenario
* The iOS attribute is incorrect (iOS 10.10 doesn't exist), so fix that
according to headers (should be iOS 10.0).
* When looking at the header, I realized the enum is deprecated, so fix that
too.
- Renamed NativeString.cs -> TransientString.cs
- Added an encoding parameter for available Marshal methods
- Added encoding in the ctor
- Handled security strings
We had custom code with Console.WriteLine for macOS 10.12 for a while, but that was removed here:
a93bcdec34
So there's no need to skip the test that verifies we don't call Console.WriteLine anymore.
This property has also been added on macOS (where it didn't exist before), since
both documentation and headers reveal it's available there.
Also make the property nullable for macOS and XAMCORE_5_0.
The iOS code uses the NSDefaultAttributesDocumentAttribute key, while the macOS code
uses the NSDefaultAttributesDocumentOption key, but according to Apple's documentation
these keys have the same underlying string value, so just use NSDefaultAttributesDocumentAttribute
for all platforms to simplify code.
The iOS code uses the NSDocumentTypeDocumentAttribute key, while the macOS code uses
the NSDocumentTypeDocumentOption key, but according to Apple's documentation these
keys have the same underlying string value, so just use NSDocumentTypeDocumentAttribute
for all platforms to simplify code.
The iOS code uses the NSDocumentTypeDocumentAttribute key, while the macOS code uses
the NSDocumentTypeDocumentOption key, but according to Apple's documentation these
keys have the same underlying string value, so just use NSDocumentTypeDocumentAttribute
for all platforms to simplify code.
The iOS code uses the NSCharacterEncodingDocumentAttribute key, while the macOS code
uses the NSCharacterEncodingDocumentOption key, but according to Apple's documentation
these keys have the same underlying string value, so just use NSCharacterEncodingDocumentAttribute
for all platforms to simplify code.
Rolf Bjarne Kvinge
Alex Soto
Andoni Morales Alastruey
GitHub Actions Autoformatter
Steve Hawley