* Update dependencies from https://github.com/dotnet/installer build 20211004.5
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rtm.21480.21 -> To Version 6.0.100-rtm.21504.5
* Update dependencies from https://github.com/dotnet/installer build 20211005.64
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rtm.21480.21 -> To Version 6.0.100-rtm.21505.64
* [src] Bump bgen to .NET 6
* Update dependencies from https://github.com/dotnet/installer build 20211006.22
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rtm.21480.21 -> To Version 6.0.100-rtm.21506.22
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
I had to change the first argument from 'string' to 'IntPtr', because 'string'
isn't blittable. In order to diverge the code paths as little as possible, I
also made this change for the legacy Xamarin version.
Ref https://github.com/xamarin/xamarin-macios/issues/10470.
* Add an (IntPtr, bool) constructor so that AudioUnit works with Runtime.GetINativeObject.
* Keep track of ownership, so that AudioUnit doesn't free the native resources
when it doesn't own them.
* Update a test to verify that calling 'AVAudioIONode.AudioUnit' multiple
times and disposing the result between them works (this fails if AudioUnit
doesn't keep track of ownership).
Now that macOS runs on ARM64 (and also the simulators soon), we need to have to same logic for all platforms.
Fixes:
Introspection.iOSApiPInvokeTest
[FAIL] Could not find the field 'objc_msgSend_stret' in /usr/lib/libobjc.dylib
[FAIL] Could not find the field 'objc_msgSendSuper_stret' in /usr/lib/libobjc.dylib
[FAIL] SymbolExists : 2 errors found in 5300 functions validated: objc_msgSend_stret, objc_msgSendSuper_stret
Expected: 0
But was: 2
at Introspection.ApiPInvokeTest.SymbolExists() in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/introspection/ApiPInvokeTest.cs:line 182
Fixes this when running our test suites on macOS 10.14:
dyld: Library not loaded: /System/Library/Frameworks/AuthenticationServices.framework/Versions/A/AuthenticationServices
Referenced from: /Users/runner/work/1/s/artifacts/mac-test-package/tests/./introspection/dotnet/macOS/bin/Debug/net6.0-macos/osx-x64/introspection.app/Contents/MacOS/introspection
Reason: image not found
make[2]: *** [exec-mac-dotnet-x64-introspection] Abort trap: 6
Fixes warnings such as these:
ld: warning: object file ([...]/libxamarin-dotnet-coreclr-debug.a(coreclr-bridge-dotnet-coreclr-debug.x86_64.o)) was built for newer macOS version (11.0) than being linked (10.15)
ld: warning: object file ([...]/libxamarin-dotnet-coreclr-debug.a(runtime-dotnet-coreclr-debug.x86_64.o)) was built for newer macOS version (11.0) than being linked (10.15)
ld: warning: object file ([...]/libxamarin-dotnet-coreclr-debug.a(bindings-dotnet-coreclr-debug.x86_64.o)) was built for newer macOS version (11.0) than being linked (10.15)
ld: warning: object file ([...]/libxamarin-dotnet-coreclr-debug.a(bindings-generated-dotnet-coreclr-debug.x86_64.o)) was built for newer macOS version (11.0) than being linked (10.15)
ld: warning: object file ([...]/libxamarin-dotnet-coreclr-debug.a(xamarin-support-dotnet-coreclr-debug.x86_64.o)) was built for newer macOS version (11.0) than being linked (10.15)
ld: warning: object file ([...]/libxamarin-dotnet-coreclr-debug.a(shared-dotnet-coreclr-debug.x86_64.o)) was built for newer macOS version (11.0) than being linked (10.15)
ld: warning: object file ([...]/libxamarin-dotnet-coreclr-debug.a(trampolines-invoke-dotnet-coreclr-debug.x86_64.o)) was built for newer macOS version (11.0) than being linked (10.15)
ld: warning: object file ([...]/libxamarin-dotnet-coreclr-debug.a(nsstring-localization-dotnet-coreclr-debug.x86_64.o)) was built for newer macOS version (11.0) than being linked (10.15)
ld: warning: object file ([...]/libxamarin-dotnet-coreclr-debug.a(monotouch-main-dotnet-coreclr-debug.x86_64.o)) was built for newer macOS version (11.0) than being linked (10.15)
ld: warning: object file ([...]/libxamarin-dotnet-coreclr-debug.a(trampolines-dotnet-coreclr-debug.x86_64.o)) was built for newer macOS version (11.0) than being linked (10.15)
ld: warning: object file ([...]/libxamarin-dotnet-coreclr-debug.a(monotouch-debug-dotnet-coreclr-debug.x86_64.o)) was built for newer macOS version (11.0) than being linked (10.15)
ld: warning: object file ([...]/libxamarin-dotnet-coreclr-debug.a(trampolines-x86_64-dotnet-coreclr-debug.x86_64.o)) was built for newer macOS version (11.0) than being linked (10.15)
Return a non-zero exit code if tests fail on older macOS versions, but keep
running tests. This way the step shows up as orange if something fails (and
not green, which is confusing).
I recently deleted the generated makefile support for building and running our
test suites. It turned out that it was used for building the packaged
Xamarin.Mac tests, so it wasn't as unused as I thought.
So fix the building and packaging of Xamarin.Mac tests to not use the
(non-existent) makefile targets, but instead replicate it with manual make
code.
Also take the opportunity to add packaging and execution of the .NET versions
of these test suites we execute on other macOS versions (both for macOS and
the Mac Catalyst).
* [devops] Use stricter matching when finding the Xamarin.Mac pkg link.
Otherwise the branch name in any package could end up matching the pattern we
were looking for:
XM_PACKAGE=https://bosstoragemirror.blob.core.windows.net/wrench/tests-package-xamarin-mac-tests/15759261d425ae08494b0a26862a0b1356c5f8ec/5268864/package/Microsoft.iOS.Bundle.15.0.101-ci.tests-package-xamarin-mac-tests.68.pkg
is just clearly wrong.
This fixes a problem where the build from the different projects could stomp
on eachother in the obj/bin folders. It's technically possible to make this
work by setting up custom [Base][Intermediate][OutputPath] properties in the
project files, but the simplest solution is to just make sure there's no more
than a single project per directory.
In .NET 6 we can use the [UnmanagedCallersOnly] attribute to mark functions
that are called from native code (instead of the [MonoPInvokeCallback]
attribute). It turns out this is a rather major refactoring (in particular for
blocks), so start by doing it for just a single function, to make sure using
[UnmanagedCallersOnly] at least works somewhere.
Ref: https://github.com/xamarin/xamarin-macios/issues/10470
Using a condition will result in the template being generated which
results in the security check to run. We need to use a template and not
a condition to avoid it.
The "product assembly" is supposed to be Xamarin.iOS.dll, Xamarin.Mac.dll,
etc., not other assemblies, so fix the implementation to reflect this. The
original commit where MonoTouch.Dialog-1 and MonoTouch.NUnitLite were
introduced as platform assemblies is quite old [1], and doesn't explain much,
but I believe the intention was to make us treat these assemblies as *SDK*
assemblies and link them accordingly, so I made these assemblies SDK assemblies now.
Additionally remove "Xamarin.iOS" as a hardcoded platform assembly for Mac
Catalyst, because this particular code is exclusive to legacy Xamarin, and Mac
Catalyst support will only be included in our .NET release, which means this
code does not have any purpose here, and might even break something one day.
[1]: 0349f8d47f
Fixes https://github.com/xamarin/xamarin-macios/issues/12862.
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rtm.21480.9 -> To Version 6.0.100-rtm.21480.21
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Add support for 'dotnet pack', by:
1. Add a workaround for the fact that as soon as a project has a
'NativeReference' item, .NET's MSBuild logic wants to include a
'Native.$(AssemblyName).manifest' file in the NuGet. This obviously breaks,
because we don't create such a file, so we work around it by removing the
file in question from the corresponding item groups.
2. Add any binding resource packages to the NuGet.
3. Add tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/12631.
Rolf Bjarne Kvinge
dotnet-maestro[bot]
github-actions[bot]
Rachel Kang
Manuel de la Pena
VS MobileTools Engineering Service 2
Chris Hamons