Automated PR. Bring new translated changes in the lcl files for
OneLocBuild to create translated resx files.
Co-authored-by: csigs <csigs@users.noreply.github.com>
Co-authored-by: CSIGS <csigs@outlook.com>
This is the pull request automatically created by the OneLocBuild task
in the build process to check-in localized files generated based upon
translation source files (.lcl files) handed-back from the downstream
localization pipeline. If there are issues in translations, visit
https://aka.ms/ceLocBug and log bugs for fixes. The OneLocBuild wiki is
https://aka.ms/onelocbuild and the localization process in general is
documented at https://aka.ms/AllAboutLoc.
* If there's both an UnsupportedOSPlatform and ObsoletedOSPlatform attribute with
the same version, then remove the UnsupportedOSPlatform attribute. This is because
in the past we used [UnsupportedOSPlatform] + [Obsolete] to indicate that an API
is obsolete, but then the [ObsoletedOSPlatform] attribute was added, and we replaced
the [Obsolete] attributes with [ObsoletedOSPlatform] attributes, which makes the
[UnsupportedOSPlatform] attributes redundant/incorrect.
* If there's [UnsupportedOSPlatform] with a version or [ObsoletedOSPlatform] with
a version, then also add [SupportedOSPlatform] in a few cases.
* If there's an [UnsupportedOSPlatform] with a version for API that's obsolete/non-working,
then remove the version.
Closes#16822
This PR adds an F# template to the basic Microsoft.iOS.iOSApp template.
This should allow being able to do either:
```
dotnet new ios -lang C# -n MyApp
dotnet new ios -lang F# -n MyApp
```
I had to move the C# template into a `csharp` folder.
Also added the `groupIdentity` `Microsoft.iOS.iOSApp` and set the identity for both C# and F# respectively to `Microsoft.iOS.iOSApp.CSharp` and `Microsoft.iOS.iOSApp.FSharp`
Co-authored-by: Timothé LARIVIERE <timothe.lariviere@fundourselves.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
NSWindow.ReleasedWhenClosed is a rather annoying API, because it interferes with
reference counting. In effect it behaves kind of like autoreleasing does, except
that the object (window) is released at a different time (when the window is closed,
as opposed to when the autorelease pool drains).
We've tried to fix this in the past in several ways:
* Forcefully disable ReleasedWhenClosed in all the constructors, and if it's set
in the Close method, then add an extra Retain call to offset the imminent extra
release. The unfortunate side-effect is that we also call Dispose, which might
be too early (see #8606).
* Rewrite the code to correctly override the native 'close' method, so we get the
supposedly correct semantics (our special Close code is called) when the window
is closed by Objective-C (for instance when the user hits the red X to close the
window). This doesn't really solve the previous problem (we're calling Dispose
too early), and it doesn't work for non-subclassed NSWindows (see #8717).
So I'm trying another approach: track the value of ReleasedWhenClosed, and call Retain/Release
when the value switches between true/false. This way we don't need any special logic
in the Close method.
I've also:
* Marked the ReleasedWhenClosed property as obsolete, and added a DangerousReleasedWhenClosed
property, to match how we bind the other reference counting methods (retain ->
DangerousRetain, release -> DangerousRelease, etc.).
* Added a ReleaseWhenClosed(bool) method, to be called instead of the ReleasedWhenClosed
property, and this method will call DangerousRetain/DangerousRelease as described
above when the ReleasedWhenClosed property changes value.
This new tracking behavior is opt-in for now, but will become opt-out in .NET 9,
and hopefully we'll be able to make it the only behavior at some point (in .NET 10
maybe?).
Fixes https://github.com/xamarin/xamarin-macios/issues/8606.
Fixes https://github.com/xamarin/xamarin-macios/issues/8607.
Ref: https://github.com/xamarin/xamarin-macios/pull/8717.
Fixes#16865
```
➜ test dotnet build -bl:msbuild.binlog
MSBuild version 17.3.2+561848881 for .NET
/usr/local/share/dotnet/sdk/6.0.403/MSBuild.dll -bl:msbuild.binlog -consoleloggerparameters:Summary -distributedlogger:Microsoft.DotNet.Tools.MSBuild.MSBuildLogger,/usr/local/share/dotnet/sdk/6.0.403/dotnet.dll*Microsoft.DotNet.Tools.MSBuild.MSBuildForwardingLogger,/usr/local/share/dotnet/sdk/6.0.403/dotnet.dll -maxcpucount -restore -verbosity:m ./test.csproj
Determining projects to restore...
All projects are up-to-date for restore.
/usr/local/share/dotnet/packs/Microsoft.macOS.Sdk/12.3.471/targets/Xamarin.Shared.Sdk.targets(284,3): error : WinExe is not a valid output type for macOS [/Users/andoni/Downloads/test/test.csproj]
Build FAILED.
/usr/local/share/dotnet/packs/Microsoft.macOS.Sdk/12.3.471/targets/Xamarin.Shared.Sdk.targets(284,3): error : WinExe is not a valid output type for macOS [/Users/andoni/Downloads/test/test.csproj]
0 Warning(s)
1 Error(s)
Time Elapsed 00:00:01.14
```
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Added GetterExceptionTest, which examines IL of Property Getters for exceptions.
Fixes#16669
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Completely remove a workaround for an issue with the thread pool in Mono.
We've previously turned this workaround off by default, and we got no reports
of any problems.
Fixes https://github.com/xamarin/xamarin-macios/issues/7080.
Move the remaining field in NSAttributedStringDocumentReadingOptionKeys into
NSAttributedStringDocumentReadingOptionKey to share more code, and update code
accordingly.
Also remove redundant [Internal] attributes on
NSAttributedStringDocumentReadingOptionKey fields, because the type itself is
[Internal].
This has no effect on public API, because it's all internal.
Fixes:
xamarin-macios/tests/framework-test/dotnet/shared.csproj(43,3): warning MSB4011: "xamarin-macios/tests/nunit.framework.targets" cannot be imported again. It was already imported at "xamarin-macios/tests/common/shared-dotnet.csproj (69,2)". This is most likely a build authoring error. This subsequent import will be ignored.
* 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.
dotnet-maestro[bot]
Rolf Bjarne Kvinge
github-actions[bot]
Steve Hawley
TJ Lambert
VS MobileTools Engineering Service 2
Timothé Larivière
Andoni Morales Alastruey
dustin-wojciechowski
Alex Soto
GitHub Actions Autoformatter