Also introduce a few other improvements:
* Add an varation that takes an 'out bool' instead of a 'ref bool'. According
to the documentation the value is out-only.
* Name this variation according to our guidelines (with a verb).
* Deprecate the old version.
Contributes towards https://github.com/xamarin/xamarin-macios/issues/15684.
This PR brings all the changes from the new Metal APIs. During the
review pay special attention to the changes done in the Protocols in
order to add tvOS support.
The main problem we have had doing this PR is that tvOS was not done on
time before the NET branching, that left us with a lot of memebers that
were NOT added in tvOS that are abstract on dotnet, which has left use
in a pickle.
Lets use the following code as an example.
Code found before this commit:
```csharp
[Mac (11, 0), iOS (14, 0), NoTV]
[MacCatalyst (14, 0)]
#if NET
[Abstract]
#endif
[Export ("accelerationStructureCommandEncoder")]
IMTLAccelerationStructureCommandEncoder CreateAccelerationStructureCommandEncoder ();
```
A naive approach would be to add just the tvOS suppor as follows:
```csharp
[Mac (11, 0), iOS (14, 0), TV (16,0)]
[MacCatalyst (14, 0)]
#if NET
[Abstract]
#endif
[Export ("accelerationStructureCommandEncoder")]
IMTLAccelerationStructureCommandEncoder CreateAccelerationStructureCommandEncoder ();
```
The above change represents and API braking change on the donet tvOS dll
because it adds a new Abstrtact members, so this is no an acceptable
solution.
There is a second naive approach we can take which is as follows:
```csharp
[Mac (11, 0), iOS (14, 0), TV (16,0)]
[MacCatalyst (14, 0)]
#if NET &!TVOS
[Abstract]
#endif
[Export ("accelerationStructureCommandEncoder")]
IMTLAccelerationStructureCommandEncoder CreateAccelerationStructureCommandEncoder ();
```
Yet again, the naive approach has an issue with it. In this case, all
the extension methods that are generated for tvOS (something the
generator writes when methods are not abstract) will be decorated with
availability attributes for all the other platforms, which is incorrect
and will make developers life worse.
That leaves us with the following approach:
```csharp
#if NET
#if !TVOS
[Mac (11, 0), iOS (14, 0), NoTV, MacCatalyst (14, 0)]
[Abstract]
#else
[NoMac, NoiOS, TV (16,0), NoMacCatalyst]
#endif
#else
[Mac (11, 0), iOS (14, 0), TV (16,0), MacCatalyst (14, 0)]
#endif
[Export ("accelerationStructureCommandEncoder")]
IMTLAccelerationStructureCommandEncoder CreateAccelerationStructureCommandEncoder ();
```
With the above change, we do not add an abstract method in tvOS and we
only add the tvOS abailabity attribute to the extension methods, and use
NoiOS etc for all the other platforms.
The change had to be done to ALL methods that added tvOS support. The
good news are that our cecil tests and our introspection tests catch the
two naive approaces :)
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Haritha Mohan <harithamohan@microsoft.com>
Co-authored-by: Alex Soto <alex@alexsoto.me>
Similar to https://github.com/xamarin/xamarin-macios/pull/19529 we need
this for all the avfoundation to be landed.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
* Convert xharness.csproj and Xharness.Tests.csproj to .NET/sdk-style projects.
* Fix numerous nullability issues that came up.
* Adjust Make logic to do the correct thing now that the executable is named differently.
* Port usage of WebClient to HttpClient, since WebClient is deprecated.
* Find an alternative solution to System.Web.MimeMapping.GetMimeMapping, which
doesn’t exist in .NET.
* Fix misc other warnings and errors.
Remove the need to pass the BT. More importantly fix an issue with the
errors when more than one attribute was expected. The eng that wrote the
code did not consider translations, and therefore the current errors
seen by a non-english speaker will result in part of the error in her
native language and the rest in english. On top of that, in english the
error is broken with words repited or broken sentences.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
It seems targets are ran in a different order in .NET 9, which means that we
ran into a different one that the one we expected. So fix that error, which
means we're now getting the error the test is checking for again.
Fixes:
Xamarin.Tests.DotNetProjectTest.InvalidArchProperty(TVOS,"MtouchArch","arm64"): Error count
Expected: 1
But was: 2
Xamarin.Tests.DotNetProjectTest.InvalidArchProperty(MacCatalyst,"MtouchArch","x64"): Error count
Expected: 1
But was: 2
Xamarin.Tests.DotNetProjectTest.InvalidArchProperty(MacOSX,"XamMacArch","x64"): Error message
Expected string length 172 but was 50. Strings differ at index 0.
Expected: "The property 'XamMacArch' is deprecated, please remove it fro..."
But was: "Could not parse TargetArchitectures 'x64'\n "
-----------^
Xamarin.Tests.DotNetProjectTest.InvalidArchProperty(iOS,"MtouchArch","armv7s"): Error count
Expected: 1
But was: 2
Also improve error reporting a bit.
It uses reflection, so it upsets NativeAOT, so just move it to cecil-test instead.
This will make it run faster, and also more predictable (it's supposed to
check all types, but types in monotouch-test may have been linked away).
Ref: https://github.com/dotnet/runtime/issues/95444
Closes#19505
We transform `[Preserve(AllMembers = true)]` into
`[DynamicDependency(DynamicallyAccessedMemberTypes.All, typeof(T))]`.
There is difference between which members are preserved in these two
cases. The `DynamicallyAccessedMemberTypes.All` preserves many more,
especially nested types and their members. This manifested with the
`IL3050` AOT analysis warning we got from ILC when building any app:
1. `NSObject_Disposer` has `[Preserve(AllMembers = true)]`
2. `NSObject_Disposer` is a subclass of NSObject
3. `NSObject` has nested enums `Flags` and `XamarinGCHandleFlags`
4. the base class `Enum` has a public static method `GetValues(Type)`
5. the `GetValues` method is annotated with `RequiresDynamicCode` and
ILC produces a warning because even though it isn't used anywhere in the
codebase, it could be used via reflection
I changed two things when transforming Preserve:
- For enums, we only need to preserve public fields. We especially want
to avoid `PublicMethods` since that would preserve public methods in the
base class which includes the `GetValues(Type)` method.
- For other types, I list explicitly the member types that should be
preserved instead of using `All`.
- The code is verbose, but in the end, I chose the explicit list instead
of `All ^ PublicNestedTypes ^ NonPublicNestedTypes` since that would
automatically include any new flag added to the enum in the future.
Make RuntimeIdentifier explicit in
CollectAppManifestsTests.PartialAppManifest, because we later try to look for
a path that depends on the runtime identifier, and setting the runtime
identifier explicitly is easier than figuring out the default runtime
identifier (which depends on the host architecture).
Fixes this failure on arm64 machines:
1) Failed : Xamarin.MacDev.Tasks.CollectAppManifestsTests.PartialAppManifest
App manifest existence
Expected: file or directory exists
But was: "xamarin-macios/tests/msbuild/Xamarin.MacDev.Tests/bin/Debug/net472/tmp-test-dir/Xamarin.MacDev.Tasks.CollectAppManifestsTests.PartialAppManifest/bin/Debug/net8.0-macos/osx-x64/PartialAppManifest.app/Contents/Info.plist"
at Xamarin.MacDev.Tasks.CollectAppManifestsTests.PartialAppManifest () [0x0011d] in xamarin-macios/tests/msbuild/Xamarin.MacDev.Tests/TargetTests/CollectAppManifestsTests.cs:71
The ResolveNativeReferences task would incorrectly set Kind=Framework for static
libraries and dylibs if these files came from an XCFramework in the runtimes/native
directory in a NuGet (as opposed to a binding project, or the NuGet built from a
binding project).
Fix this by properly assigning the Kind and PublishFolderType metadata for such static
libraries and dylibs.
Also add a test.
Add a cecil test to verify a few common capitalization issues:
* All APIs must start with an upper-cased letter (except parameter names, which must start with a lower-cased letter).
* The term "URL" should always be capitalized as "Url".
Sonoma is pickier now with the way we create a CoreGraphics.CGImage,
meaning that if we do not pass the correct flags, the OS will return a
nil object (might be a good idea to move away from constructors to
factory methods).
Before this change we would get the following errors:
* CAKeyFrameAnimation_ValuesTests: System.Exception : Could not
initialize an instance of the type 'CoreGraphics.CGImage': handle is
null. It is possible to ignore this condition by setting
ObjCRuntime.Class.ThrowOnInitFailure to false.
* CALayer_ValuesTests: System.Exception : Could not initialize an
instance of the type 'CoreGraphics.CGImage': handle is null. It is
possible to ignore this condition by setting
ObjCRuntime.Class.ThrowOnInitFailure to false.
Before this commit we had the following failing test:
```
Error: Exception Message
Expected: String matching "Objective-C exception thrown. Name: _HKObjectValidationFailureException Reason: Type HKSample can not have endDate of NSDate.distantFuture"
But was: "Objective-C exception thrown. Name: _HKObjectValidationFailureException Reason: startDate (0001-01-01 00:00:00 +0000) and endDate (4001-01-01 00:00:00 +0000) exceed the maximum allowed duration for this sample type. Maximum duration for type
```
The new exception does not happen on macOS but does on iOS.
We currently detect/resolve binding resource packages (the sidecar) in two places:
* The ResolveNativeReferences MSBuild task.
* Inside mtouch/mmp/dotnet-linker.
Which means we end up passing every native library or framework twice to the native linker.
This is usually not a problem, the native linker will ignore duplicated
arguments, except when building remotely from Windows, in which case the build
process may end up with native libraries in different locations, because files
may end up in multiple places on the remote Mac if using absolute paths (see
https://github.com/xamarin/xamarin-macios/issues/18997 for a thorough explanation).
So completely remove the logic to detect/resolve binding resource packages in
mtouch/mmp/dotnet-linker, which will avoid the issue completely.
A few mtouch tests also needed updating, since they're calling mtouch directly instead
of going through the msbuild targets.
Fixes https://github.com/xamarin/xamarin-macios/issues/19378.
First take at refactoring parts of the Generator:
1. RemoveArity() is now a string extension method with a test
2. FormatType, FormatTypeUsedIn, and part of PrimitiveType methods have
been moved into the TypeManager class.
3. TypeManager now has access to BindingTouch (similar to the other
Manager classes) so that it may call methods from NamespaceManager,
which also had to be made into a public property of BindingTouch vs
being passed through the Generator constructor.
---------
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Co-authored-by: Alex Soto <alex@alexsoto.me>
When migrating Xamarin projects to .NET projects, somewhat frequently people
will leave the MtouchArch/XamMacArch properties in their project files with
old values. This won't work, since we use RuntimeIdentifier(s) now to control
the target architecture, so remove support for MtouchArch/XamMacArch, and show
an error if we detect that they're set.
This will hopefully prevent some really confusing problems, especially in the IDEs.
Example: https://github.com/xamarin/xamarin-macios/issues/19258
Rolf Bjarne Kvinge
Manuel de la Pena
Šimon Rozsíval
GitHub Actions Autoformatter
dustin-wojciechowski
Haritha Mohan
TJ Lambert