This pull request updates the following dependencies
## Coherency Updates
The following updates ensure that dependencies with a *CoherentParentDependency*
attribute were produced in a build used as input to the parent dependency's build.
See [Dependency Description Format](https://github.com/dotnet/arcade/blob/master/Documentation/DependencyDescriptionFormat.md#dependency-description-overview)
- **Coherency Updates**:
- **Microsoft.NET.Workload.Emscripten.net7.Manifest-7.0.100**: from 7.0.2 to 7.0.2 (parent: Microsoft.NETCore.App.Ref)
## From https://github.com/dotnet/runtime
- **Subscription**: 38d2313f-22d5-4062-c8e1-08dabd6d8c77
- **Build**: 20230109.16
- **Date Produced**: January 10, 2023 8:35:10 AM UTC
- **Commit**: 2f7c3f4a4f4a49362055d45751756eb4224c7414
- **Branch**: refs/heads/release/7.0
- **Updates**:
- **Microsoft.NETCore.App.Ref**: [from 7.0.3 to 7.0.3][3]
- **Microsoft.NET.Workload.Emscripten.net7.Manifest-7.0.100**: [from 7.0.2 to 7.0.2][4]
[3]: a790868...2f7c3f4
[4]: d71ea7c...00fbd97
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Add an SdkDevPath property to the DSymUtil task, and use it to set DEVELOPER_DIR when calling dsymutil.
Should fix this:
> xcrun: error: unable to find utility "dsymutil", not a developer tool or in PATH
when `xcode-select -p` and VSMac are configured with two different Xcodes.
We no longer need two have overridable logic for remote builds, so the
non-abstract task class and the abstract base class can be merged.
First out is the Mmp task.
Add support to xtro-sharpie for where to look for referenced assemblies, and
adjust assembly resolution to only look in those directories.
This makes sure xtro-sharpie loads the expected references, and fixes a
problem where the (broken) assembly resolution wouldn't find a .NET assembly
because it doesn't exist in legacy Xamarin (where it would look by default).
Fixes this problem that showed up in a different PR (due to new .NET API
referencing the System.Runtime.Loader assembly, which doesn't exist in legacy
Xamarin):
mono64 --debug bin/Debug/xtro-sharpie.exe --output-directory api-annotations-dotnet appletvos16.1-arm64.pch ../../_build/Microsoft.tvOS.Runtime.tvos-arm64/runtimes/tvos-arm64/lib/net7.0/Microsoft.tvOS.dll
Mono.Cecil.AssemblyResolutionException: Failed to resolve assembly: 'System.Runtime.Loader, Version=7.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
at Mono.Cecil.BaseAssemblyResolver.Resolve (Mono.Cecil.AssemblyNameReference name, Mono.Cecil.ReaderParameters parameters) [0x000ff] in C:\src\cecil\Mono.Cecil\BaseAssemblyResolver.cs:172
at Mono.Cecil.BaseAssemblyResolver.Resolve (Mono.Cecil.AssemblyNameReference name) [0x00000] in C:\src\cecil\Mono.Cecil\BaseAssemblyResolver.cs:117
at Mono.Cecil.DefaultAssemblyResolver.Resolve (Mono.Cecil.AssemblyNameReference name) [0x0001d] in C:\src\cecil\Mono.Cecil\DefaultAssemblyResolver.cs:33
at Mono.Cecil.MetadataResolver.Resolve (Mono.Cecil.TypeReference type) [0x0003a] in C:\src\cecil\Mono.Cecil\MetadataResolver.cs:110
at Mono.Cecil.ModuleDefinition.Resolve (Mono.Cecil.TypeReference type) [0x00000] in C:\src\cecil\Mono.Cecil\ModuleDefinition.cs:748
at Mono.Cecil.TypeReference.Resolve () [0x0000f] in C:\src\cecil\Mono.Cecil\TypeReference.cs:280
at Extrospection.Helpers.GetName (Mono.Cecil.MethodDefinition self) [0x00051] in /Users/rolf/work/maccore/whatever/xamarin-macios/tests/xtro-sharpie/Helpers.cs:332
at Extrospection.DesignatedInitializerCheck.VisitManagedMethod (Mono.Cecil.MethodDefinition method) [0x00001] in /Users/rolf/work/maccore/whatever/xamarin-macios/tests/xtro-sharpie/DesignatedInitializerCheck.cs:43
at Extrospection.AssemblyReader.ProcessType (Extrospection.BaseVisitor v, Mono.Cecil.TypeDefinition type) [0x0002b] in /Users/rolf/work/maccore/whatever/xamarin-macios/tests/xtro-sharpie/Runner.cs:104
at Extrospection.AssemblyReader.Process () [0x0008e] in /Users/rolf/work/maccore/whatever/xamarin-macios/tests/xtro-sharpie/Runner.cs:93
at Extrospection.Runner.Execute (System.String pchFile, System.Collections.Generic.IEnumerable`1[T] assemblyNames, System.String outputDirectory) [0x001af] in /Users/rolf/work/maccore/whatever/xamarin-macios/tests/xtro-sharpie/Runner.cs:52
at Extrospection.MainClass.Main (System.String[] arguments) [0x0008f] in /Users/rolf/work/maccore/whatever/xamarin-macios/tests/xtro-sharpie/Program.cs:28
make: *** [.stamp-dotnet-classify-tvOS] Error 1
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Create an MSBuild property for the minimum OS version
(`SupportedOSPlatformVersion`) we support for a given platform (named
`[platform]MinSupportedOSPlatformVersion`), and use it in most tests instead
of hardcoding the min OS version (which would otherwise have to be updated
every time we bump the min OS version).
In .NET, we changed the API for creating a NSTextList with a specified
NSTextListMarkerFormats, making NSTextListMarkerFormats a strongly typed enum,
and not allowing any other value except those in NSTextListMarkerFormats.
This was a mistake, because NSTextList can be created with other format values
than those available in NSTextListMarkerFormats.
So fix this by:
* Adding another NSTextListMarkerFormats enum value that specifies that the
actual format is a custom one (NSTextListMarkerFormats.CustomString).
* Resurface an 'NSTextListMarkerFormats(string)' constructor that can be used
to create an NSTextListMarkerFormats with a custom string.
* Add a NSTextListMarkerFormats.CustomMarkerFormat property that always
retrieves the underlying string value for the format.
* Add a NSTextListOptions.None enum value, which means no options (since
NSTextListOptions is a set of flags, it should be possible to specify no
flags).
* Add two convenience constructors that don't take a NSTextListOptions value,
defaulting to NSTextListOptions.None.
* Add tests!
Fixes https://github.com/xamarin/xamarin-macios/issues/15766.
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).
Rolf Bjarne Kvinge
dotnet-maestro[bot]
Manuel de la Pena
Steve Hawley
Mauro Agnoletti
github-actions[bot]
TJ Lambert
VS MobileTools Engineering Service 2
Timothé Larivière
Andoni Morales Alastruey
dustin-wojciechowski
Alex Soto