The canonical property we use for the interpreter is `MtouchInterpreter` - and
the interpreter is enabled if `MtouchInterpreter` is set to any value (the
`MtouchInterpreter` value is used to select which assemblies to interpret, the
only way to completely disable the interpreter is to not set
`MtouchInterpreter` at all).
So fix a couple of cases of wrong comparison:
* Don't use `UseInterpreter` - which is used to compute a specific value for
`MtouchInterpreter` - because developers don't have to set `UseInterpreter`
to enable the interpreter, they can set `MtouchInterpreter` directly.
* Don't compare `MtouchInterpreter` with `true`: that only checks if the
assembly "true" is interpreted (which it rarely is).
Fixes https://github.com/dotnet/runtime/issues/96920.
Changes:
- Updated Xamarin.Messaging to 1.13.8: bring fix for potential
NullReferenceException in TaskRunner.FixReferencedItems:
https://github.com/xamarin/Xamarin.Messaging/pull/694
- Updated MSBuild tasks that uses TaskRunner.FixReferencedItems from
Xamarin.Messaging: update needed to match new Xamarin.Messaging API
changes
Remote tests on macOS should currently not take more than a couple of
hours,
so adjust the timeout accordingly.
This avoids the CI waiting 16 hours before timing out if something goes
wrong.
This turned into a rather involved exercise, because the
MidiThruConnectionParamsStruct struct had several array fields that needed
marshalling to work.
The changes include:
* Unwrap the array fields with MarshalAs attributes to be individual fields
instead.
* Write a number of tests to ensure the changes work.
* Fix an overflow issue found by the tests for the Controls array if trying to
set to an array with more than 65535 elements.
* Fix an overflow issue found by the tests for the Maps array if trying to set
to an array with more than 65535 elements.
* Fix an issue found by the tests where we wouldn't deserialize the Maps array
correctly from a byte array / NSData if the Maps array had more than 1
element.
* Fix a consistency issue found in the tests where deserializing a serialized
structure doesn't yield the same result.
* In particular this happens with the ChannelMap property: behavior has
changed a little bit where setting the ChannelMap to an array with fewer
than 16 elements (including a null array) will not return the same array
anymore, but instead an array with 16 elements, where the extra elements
are all 0. I've also made the ChannelMap property non-nullable, since
the nullability state isn't serializable into the underlying struct.
Contributes towards #15684.
This is because it doesn't work on arm64 - it's trying to verify that we
handle a specific error condition gracefully, but we're rather evil in trying
to trigger the error condition (being kind doesn't trigger the error), and the
AOT compiler detects the same thing we do and errors out before we get a
chance to show our nice error.
In short: make this an x64-only test.
When passing -s to the csharp binary, the remaining arguments passed to the
script will be available in the global 'Args' variable.
This way makes it easier to consume arguments in the script, since we won't
have to call Environment.GetCommandLineArgs () and then manually skip the
arguments to the native executable (which would be: the path to mono, the path
to the csharp binary, and the '-s' argument if applicable).
A few facts:
* We very rarely bump Mono (which is really the only time we should run the BCL tests).
* At the moment we're not shipping legacy Xamarin packages from main anymore.
* The BCL tests only apply to legacy Xamarin.
means that there's no need to run the BCL tests on every commit, we can just
run them manually *if* we happen to ever bump Mono again *and* we start
shipping legacy Xamarin packages from main again.
The main reason is that NuGet isn't safe to run in parallel, so we need to
serially restore all projects, before they can be built in parallel.
This hopefully fixes a problem where the build would randomly fail because
NuGet would corrupt the packages folder when executed in parallel.
In .NET the 4 platforms are 4 separate products, so it makes sense that each
Versions.plist only contains information for the corresponding platform.
This means we can share the same logic for all .NET platforms, instead of
having to special-case macOS.
It also decouples legacy logic from .NET logic, which makes it easier to
remove legacy logic when that time comes.
This is a manual and squashed backport of
https://github.com/xamarin/xamarin-macios/pull/19717 and it was updated
to use Xcode 15.2 since Xcode 15.2 contains the same SDKs as Xcode 15.1
but Xcode 15.2 has visionOS SDK and it is the new stable release from
Apple.
---------
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Use the .NET version (the `*_NUGET_VERSION` variables) instead of the
Xamarin.iOS/Xamarin.Mac versions (the `IOS_PACKAGE_VERSION` /
`MAC_PACKAGE_VERSION` variables) for the buildinfo file we put in our .NET
NuGets.
This also means we can share the same logic for all .NET platforms, instead of
having to special-case macOS.
Besides this being the correct value to put in the file (the Xamarin versions
have nothing to do with the .NET versions), it also decouples legacy logic
from .NET logic, which makes it easier to remove legacy logic when that time
comes.
The current reults are hard/impossible to understand by a human. Fix the
way we report the error so that we go from:
```
(AVFoundation.AVAudioVoiceProcessingOtherAudioDuckingConfiguration ObjCRuntime.Messaging::AVAudioVoiceProcessingOtherAudioDuckingConfiguration_objc_msgSend(System.IntPtr,System.IntPtr), )
```
to
```
AVFoundation.AVAudioVoiceProcessingOtherAudioDuckingConfiguration ObjCRuntime.Messaging::AVAudioVoiceProcessingOtherAudioDuckingConfiguration_objc_msgSend(System.IntPtr,System.IntPtr) - The return type is AVFoundation.AVAudioVoiceProcessingOtherAudioDuckingConfiguration: (EnableAdvancedDucking: has a [MarshalAs] attribute)
at no match Mono.Cecil.MethodDefinition
```
fulle example here:
https://gist.github.com/mandel-macaque/30f54ac5b0e22454d57644d2b7b94eca
Add a much nicer error message and reuse code. There is not need to add
[Fail] at all in the messages.
Example of the changes:
https://gist.github.com/mandel-macaque/255597f2390804a5a1c2675959b2f35c
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
As with others, make the results more readable, in this case we just
need to re-use the already present method.
Diff in the ouputs can be found here:
https://gist.github.com/mandel-macaque/7015b2f9c7dfc857caa72f7c1ea19b0a
In this case we move to have the enumerated list.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Remove support for the Protocolize attribute from the generator, and remove
all usages of it in our api definitions - just use the protocol interface.
The Protocolize attribute was used to support binding stuff using the Model
class with Classic Xamarin code + and binding stuff using the protocol
interface with Unified Xamarin code, using the same source code.
Classic Xamarin has been dead for quite a few years ago now though, so there's
no need to keep his code around anymore, we can just upgrade the api
definitions to use the protocol interface directly.
Fixes https://github.com/xamarin/xamarin-macios/issues/14585.
---------
Co-authored-by: Alex Soto <alex@soto.dev>
The ToString of a named tuple does not make sense for a human, this
tests, while it does find issues with the API, it does not help the
developer to find the real reason.
This PR has 2 important fixes.
1. Add a generic constrain to the Assert.Failures. The developer that
wrote the code got lucky and always used T that are IComparable. I mean
lucky, because the OrderBy from Linq needs T to be IComparable, and I am
surprise we never got a rutime error with the test.
2. Use a record type with a reasonable ToString.
The following gist contains a diff between the output with the fix and
without it.
https://gist.github.com/mandel-macaque/ee1adab1bf0568a6e95d47e7f3b7970a
The diff is:
New code:
```
AVFoundation.AVAudioSessionRouteSharingPolicy AVFoundation.AVAudioSessionRouteSharingPolicy::LongForm: AVFoundation.AVAudioSessionRouteSharingPolicy AVFoundation.AVAudioSessionRouteSharingPolicy::LongForm is obsoleted on MacOSX but not on iOS, TVOS, MacCatalyst
```
Old code:
```
(AVFoundation.AVAudioSessionRouteSharingPolicy AVFoundation.AVAudioSessionRouteSharingPolicy::LongForm, AVFoundation.AVAudioSessionRouteSharingPolicy AVFoundation.AVAudioSessionRouteSharingPolicy::LongForm, Cecil.Tests.OSPlatformAttributes[], Cecil.Tests.OSPlatformAttributes[])
```
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
In order to make it easier to pass C-style strings to P/Invokes, we
introduced
a TransientString struct some time ago.
This works quite well, so I implemented the same for CFStrings - a
TransientCFString struct - and started using it in a few places. The
idea
would be to slowly start migrating our codebase to this new pattern.
Instead of:
var ptr = CFString.CreateNative ("somestring");
try {
CallPInvoke (ptr);
} finally {
CFString.ReleaseNative (ptr);
}
we'll do:
using var ptr = new TransientCFString ("somestring");
CallPInvoke (ptr);
Rolf Bjarne Kvinge
dotnet-maestro[bot]
Manuel de la Pena
Michael Cummings (MSFT)
Mauro Agnoletti
MSLukeWest
Alex Soto