A new parameter has been added to allow the unified pipeline to skip
classic signing jobs.
The jobs that would sign and notarize the custom workload .pkg and .zip
files have been removed, as we do not ship these anywhere and do not
need to wait on signing for them. The `dotnet-signed` artifact has been
removed as a result, and the `not-signed-package` artifact is used in
its place.
1. Mono changed dyld lookup to start looking in directories in
NATIVE_DLL_SEARCH_DIRECTORIES before the actual given path, even when the
given path is absolute [1].
2. This turned out to break Mac Catalyst, because when a DllImport says a
P/Invoke is in "/System/Library/Frameworks/SceneKit.framework/SceneKit",
Mono would try loading by prefixing the directories in
NATIVE_DLL_SEARCH_DIRECTORIES. We add the Contents/MonoBundle directory to
NATIVE_DLL_SEARCH_DIRECTORIES, so Mono would try to load
"/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit",
and things would go wrong.
3. We found a workaround: add "/" to NATIVE_DLL_SEARCH_DIRECTORIES. This works
on Ventura, but apparently not on older macOS version, because the actual
path we pass to dlopen ends up being "///System/Library/Frameworks/SceneKit.framework/SceneKit"
(note the three initial slashes instead of a single slash).
4. Add a second workaround, where we add a dll import resolver to load exactly
the path we want to load.
[1]: 5a1baebc09
[2]: https://github.com/dotnet/runtime/pull/85255
Technical sidenote:
Why trying to load "/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit"
turned out so bad on Mac Catalyst is not obvious. What happens is this:
* The app calls 'dlopen ("/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit")'
* dlopen checks if this is a Mac Catalyst override of a macOS system
framework, by prefixing "/System/iOSSupport" and trying to load that. So
dlopen would try to load "/System/iOSSupport/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit",
which would obviously fail.
* Then dlopen would try a few more fallbacks, eventually trying
"/System/Library/Frameworks/SceneKit.framework/SceneKit", and successfully
loading that library.
* Unfortunately "/System/Library/Frameworks/SceneKit.framework/SceneKit" is
the wrong library to load for Mac Catalyst ("/System/iOSSupport/System/Library/Frameworks/SceneKit.framework/SceneKit"
is the correct version). These two libraries are incompatible, and calling
one when you mean to call the other will do nasty things like corrupting the
stack.
The calli instruction calls a function pointer on the stack, not a specific
managed function, so don't include it when looking for calls to managed functions.
This fixes ~1600 warnings like these:
warning CS0436: The type 'Messaging' in 'xamarin-macios/tests/monotouch-test/ObjCRuntime/Messaging.cs' conflicts with the imported type 'Messaging' in 'bindings-test, Version=1.0.0.0, Culture=neutral, PublicKeyToken=84e04ff9cfb79065'
It fails to update:
Coherency updates failed for the following dependencies:
Unable to update Microsoft.NET.Workload.Emscripten.net7.Manifest-7.0.100 to have coherency with Microsoft.NETCore.App.Ref: https://github.com/dotnet/runtime @ db7ca5d87eb3cd83bbc77487eb97dec07f74abf8 does not contain dependency Microsoft.NET.Workload.Emscripten.net7.Manifest-7.0.100
- Add the dependency to https://github.com/dotnet/runtime.
- Pin the dependenency.
- Remove the CoherentParentDependency attribute.
Once removed, bumping the .NET 8 dependency works again, so do that.
Fixes these test failures (which only happen on the bots):
[FAIL] AddressBook.InitConstants .cctor could not execute properly: System.TypeInitializationException: The type initializer for 'AddressBook.InitConstants' threw an exception.
---> System.EntryPointNotFoundException: ABAddressBookCreate
at AddressBook.InitConstants..cctor()
--- End of inner exception stack trace ---
at System.Runtime.CompilerServices.RuntimeHelpers.RunClassConstructor(RuntimeTypeHandle type)
at Introspection.ApiTypeTest.StaticCtor() in /Users/builder/azdo/_work/4/s/xamarin-macios/tests/introspection/ApiTypeTest.cs:line 51
[FAIL] AddressBook.ABGroupProperty .cctor could not execute properly: System.TypeInitializationException: The type initializer for 'AddressBook.ABGroupProperty' threw an exception.
---> System.TypeInitializationException: The type initializer for 'AddressBook.InitConstants' threw an exception.
---> System.EntryPointNotFoundException: ABAddressBookCreate
at AddressBook.InitConstants..cctor()
--- End of inner exception stack trace ---
at AddressBook.ABGroupProperty..cctor()
--- End of inner exception stack trace ---
at System.Runtime.CompilerServices.RuntimeHelpers.RunClassConstructor(RuntimeTypeHandle type)
at Introspection.ApiTypeTest.StaticCtor() in /Users/builder/azdo/_work/4/s/xamarin-macios/tests/introspection/ApiTypeTest.cs:line 51
[FAIL] AddressBook.ABPersonPropertyId .cctor could not execute properly: System.TypeInitializationException: The type initializer for 'AddressBook.ABPersonPropertyId' threw an exception.
---> System.TypeInitializationException: The type initializer for 'AddressBook.InitConstants' threw an exception.
---> System.EntryPointNotFoundException: ABAddressBookCreate
at AddressBook.InitConstants..cctor()
--- End of inner exception stack trace ---
at AddressBook.ABPersonPropertyId..cctor()
--- End of inner exception stack trace ---
at System.Runtime.CompilerServices.RuntimeHelpers.RunClassConstructor(RuntimeTypeHandle type)
at Introspection.ApiTypeTest.StaticCtor() in /Users/builder/azdo/_work/4/s/xamarin-macios/tests/introspection/ApiTypeTest.cs:line 51
[FAIL] AddressBook.ABPersonAddressKey .cctor could not execute properly: System.TypeInitializationException: The type initializer for 'AddressBook.ABPersonAddressKey' threw an exception.
---> System.TypeInitializationException: The type initializer for 'AddressBook.InitConstants' threw an exception.
---> System.EntryPointNotFoundException: ABAddressBookCreate
at AddressBook.InitConstants..cctor()
--- End of inner exception stack trace ---
at AddressBook.ABPersonAddressKey..cctor()
--- End of inner exception stack trace ---
at System.Runtime.CompilerServices.RuntimeHelpers.RunClassConstructor(RuntimeTypeHandle type)
at Introspection.ApiTypeTest.StaticCtor() in /Users/builder/azdo/_work/4/s/xamarin-macios/tests/introspection/ApiTypeTest.cs:line 51
[FAIL] AddressBook.ABPersonDateLabel .cctor could not execute properly: System.TypeInitializationException: The type initializer for 'AddressBook.ABPersonDateLabel' threw an exception.
---> System.TypeInitializationException: The type initializer for 'AddressBook.InitConstants' threw an exception.
---> System.EntryPointNotFoundException: ABAddressBookCreate
at AddressBook.InitConstants..cctor()
--- End of inner exception stack trace ---
at AddressBook.ABPersonDateLabel..cctor()
--- End of inner exception stack trace ---
at System.Runtime.CompilerServices.RuntimeHelpers.RunClassConstructor(RuntimeTypeHandle type)
at Introspection.ApiTypeTest.StaticCtor() in /Users/builder/azdo/_work/4/s/xamarin-macios/tests/introspection/ApiTypeTest.cs:line 51
[FAIL] AddressBook.ABPersonKindId .cctor could not execute properly: System.TypeInitializationException: The type initializer for 'AddressBook.ABPersonKindId' threw an exception.
---> System.TypeInitializationException: The type initializer for 'AddressBook.InitConstants' threw an exception.
---> System.EntryPointNotFoundException: ABAddressBookCreate
at AddressBook.InitConstants..cctor()
--- End of inner exception stack trace ---
at AddressBook.ABPersonKindId..cctor()
--- End of inner exception stack trace ---
at System.Runtime.CompilerServices.RuntimeHelpers.RunClassConstructor(RuntimeTypeHandle type)
at Introspection.ApiTypeTest.StaticCtor() in /Users/builder/azdo/_work/4/s/xamarin-macios/tests/introspection/ApiTypeTest.cs:line 51
[FAIL] AddressBook.ABPersonPhoneLabel .cctor could not execute properly: System.TypeInitializationException: The type initializer for 'AddressBook.ABPersonPhoneLabel' threw an exception.
---> System.TypeInitializationException: The type initializer for 'AddressBook.InitConstants' threw an exception.
---> System.EntryPointNotFoundException: ABAddressBookCreate
at AddressBook.InitConstants..cctor()
--- End of inner exception stack trace ---
at AddressBook.ABPersonPhoneLabel..cctor()
--- End of inner exception stack trace ---
at System.Runtime.CompilerServices.RuntimeHelpers.RunClassConstructor(RuntimeTypeHandle type)
at Introspection.ApiTypeTest.StaticCtor() in /Users/builder/azdo/_work/4/s/xamarin-macios/tests/introspection/ApiTypeTest.cs:line 51
[FAIL] AddressBook.ABPersonInstantMessageService .cctor could not execute properly: System.TypeInitializationException: The type initializer for 'AddressBook.ABPersonInstantMessageService' threw an exception.
---> System.TypeInitializationException: The type initializer for 'AddressBook.InitConstants' threw an exception.
---> System.EntryPointNotFoundException: ABAddressBookCreate
at AddressBook.InitConstants..cctor()
--- End of inner exception stack trace ---
at AddressBook.ABPersonInstantMessageService..cctor()
--- End of inner exception stack trace ---
at System.Runtime.CompilerServices.RuntimeHelpers.RunClassConstructor(RuntimeTypeHandle type)
at Introspection.ApiTypeTest.StaticCtor() in /Users/builder/azdo/_work/4/s/xamarin-macios/tests/introspection/ApiTypeTest.cs:line 51
[FAIL] AddressBook.ABPersonInstantMessageKey .cctor could not execute properly: System.TypeInitializationException: The type initializer for 'AddressBook.ABPersonInstantMessageKey' threw an exception.
---> System.TypeInitializationException: The type initializer for 'AddressBook.InitConstants' threw an exception.
---> System.EntryPointNotFoundException: ABAddressBookCreate
at AddressBook.InitConstants..cctor()
--- End of inner exception stack trace ---
at AddressBook.ABPersonInstantMessageKey..cctor()
--- End of inner exception stack trace ---
at System.Runtime.CompilerServices.RuntimeHelpers.RunClassConstructor(RuntimeTypeHandle type)
at Introspection.ApiTypeTest.StaticCtor() in /Users/builder/azdo/_work/4/s/xamarin-macios/tests/introspection/ApiTypeTest.cs:line 51
[FAIL] AddressBook.ABPersonUrlLabel .cctor could not execute properly: System.TypeInitializationException: The type initializer for 'AddressBook.ABPersonUrlLabel' threw an exception.
---> System.TypeInitializationException: The type initializer for 'AddressBook.InitConstants' threw an exception.
---> System.EntryPointNotFoundException: ABAddressBookCreate
at AddressBook.InitConstants..cctor()
--- End of inner exception stack trace ---
at AddressBook.ABPersonUrlLabel..cctor()
--- End of inner exception stack trace ---
at System.Runtime.CompilerServices.RuntimeHelpers.RunClassConstructor(RuntimeTypeHandle type)
at Introspection.ApiTypeTest.StaticCtor() in /Users/builder/azdo/_work/4/s/xamarin-macios/tests/introspection/ApiTypeTest.cs:line 51
[FAIL] AddressBook.ABPersonRelatedNamesLabel .cctor could not execute properly: System.TypeInitializationException: The type initializer for 'AddressBook.ABPersonRelatedNamesLabel' threw an exception.
---> System.TypeInitializationException: The type initializer for 'AddressBook.InitConstants' threw an exception.
---> System.EntryPointNotFoundException: ABAddressBookCreate
at AddressBook.InitConstants..cctor()
--- End of inner exception stack trace ---
at AddressBook.ABPersonRelatedNamesLabel..cctor()
--- End of inner exception stack trace ---
at System.Runtime.CompilerServices.RuntimeHelpers.RunClassConstructor(RuntimeTypeHandle type)
at Introspection.ApiTypeTest.StaticCtor() in /Users/builder/azdo/_work/4/s/xamarin-macios/tests/introspection/ApiTypeTest.cs:line 51
[FAIL] AddressBook.ABLabel .cctor could not execute properly: System.TypeInitializationException: The type initializer for 'AddressBook.ABLabel' threw an exception.
---> System.TypeInitializationException: The type initializer for 'AddressBook.InitConstants' threw an exception.
---> System.EntryPointNotFoundException: ABAddressBookCreate
at AddressBook.InitConstants..cctor()
--- End of inner exception stack trace ---
at AddressBook.ABLabel..cctor()
--- End of inner exception stack trace ---
at System.Runtime.CompilerServices.RuntimeHelpers.RunClassConstructor(RuntimeTypeHandle type)
at Introspection.ApiTypeTest.StaticCtor() in /Users/builder/azdo/_work/4/s/xamarin-macios/tests/introspection/ApiTypeTest.cs:line 51
[FAIL] AddressBook.ABSourcePropertyId .cctor could not execute properly: System.TypeInitializationException: The type initializer for 'AddressBook.ABSourcePropertyId' threw an exception.
---> System.TypeInitializationException: The type initializer for 'AddressBook.InitConstants' threw an exception.
---> System.EntryPointNotFoundException: ABAddressBookCreate
at AddressBook.InitConstants..cctor()
--- End of inner exception stack trace ---
at AddressBook.ABSourcePropertyId..cctor()
--- End of inner exception stack trace ---
at System.Runtime.CompilerServices.RuntimeHelpers.RunClassConstructor(RuntimeTypeHandle type)
The callback to the AVAudioSinkNode constructor was declared incorrectly, and
if used, the app would crash at runtime.
This fix does a few things:
* Creates an overload with callback signature that matches the native API
(using IntPtrs).
* Writes a custom version for the broken callback signature to make it work
(and this overload is obsoleted, and removed in XAMCORE_5_0).
* Adds a third overload with the ideal signature.
* Adds tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/17575.
Also fix a nullability warning.
Fixes these warnings:
"tests/generator/generator-tests.csproj" (default target) (1:7) ->
(CoreCompile target) ->
tests/generator/AttributeFactoryTests.cs(43,29): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.
tests/generator/AttributeFactoryTests.cs(44,29): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.
tests/generator/AttributeFactoryTests.cs(45,29): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.
tests/generator/ConstructorArgumentsTests.cs(17,19): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.
tests/generator/ConstructorArgumentsTests.cs(34,19): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.
tests/generator/AttributeFactoryTests.cs(53,39): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.
tests/generator/AttributeFactoryTests.cs(54,39): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.
tests/generator/AttributeFactoryTests.cs(55,39): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.
tests/generator/AttributeFactoryTests.cs(56,39): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.
tests/generator/AttributeFactoryTests.cs(64,34): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.
tests/generator/AttributeFactoryTests.cs(69,11): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.
tests/generator/AttributeFactoryTests.cs(76,34): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.
tests/generator/ConstructorArgumentsTests.cs(55,19): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.
tests/generator/AttributeFactoryTests.cs(83,34): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.
tests/generator/ConstructorArgumentsTests.cs(78,19): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.
tests/generator/AttributeFactoryTests.cs(111,16): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.
tests/generator/AttributeFactoryTests.cs(138,16): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.
tests/generator/ConstructorArgumentsTests.cs(95,19): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.
tests/generator/AttributeFactoryTests.cs(178,16): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.
tests/generator/ConstructorArgumentsTests.cs(116,19): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.]
tests/generator/ConstructorArgumentsTests.cs(194,18): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.]
tests/generator/ConstructorArgumentsTests.cs(210,18): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.]
tests/generator/ConstructorArgumentsTests.cs(197,44): warning CS8602: Dereference of a possibly null reference.
tests/generator/ConstructorArgumentsTests.cs(201,43): warning CS8602: Dereference of a possibly null reference.
This makes it unnecessary to special-case this file for it to copied
correctly when building on Windows (once we've fixed the Windows build to use
ResolvedFileToPublish as the source of truth, like we do on macOS).
This is the first part of a fix for
https://github.com/xamarin/xamarin-macios/issues/17579.
The ReadAppManifest task doesn't need the SdkVersion, because it's only used to compute
the path to the sdk on disk, and that path can be calculated without an sdk version
now:
$ ls -la /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs
total 0
drwxrwxr-x 4 rolf staff 128 Dec 14 10:58 .
drwxr-xr-x 5 rolf staff 160 Nov 11 01:38 ..
drwxrwxr-x 8 rolf staff 256 Dec 14 10:48 iPhoneOS.sdk
lrwxr-xr-x 1 rolf staff 12 Dec 14 10:56 iPhoneOS16.2.sdk -> iPhoneOS.sdk
In fact, the path with the version just symlinks to the path without.
The original implementation for the MidiCIDeviceIdentification struct uses
public byte[] fields with a MarshalAs attribute to set the array size. This is
not blittable, but unfortunately these are _public_ fields, which means we
can't change them.
Instead introduce an internal intermediate struct, which is blittable, and
convert to and from this struct when marshalling to and from native code.
Then in XAMCORE_5_0 we can make the intermediate struct public and use it
instead of the non-blittable struct everywhere.
This will hopefully fix the following errors:
[FAIL] TrustUsingNewCallback : System.Net.WebException : nodename nor servname provided, or not known (dotnet.microsoft.com:443)
----> System.Net.Http.HttpRequestException : nodename nor servname provided, or not known (dotnet.microsoft.com:443)
----> System.Net.Sockets.SocketException : nodename nor servname provided, or not known
at System.Net.HttpWebRequest.GetResponse()
at System.Net.WebClient.GetWebResponse(WebRequest )
at System.Net.WebClient.DownloadBits(WebRequest , Stream )
at System.Net.WebClient.DownloadDataInternal(Uri , WebRequest& )
at System.Net.WebClient.DownloadString(Uri )
at System.Net.WebClient.DownloadString(String )
at LinkSdk.CryptoTest.TrustUsingNewCallback()
at System.Reflection.MethodInvoker.InterpretedInvoke(Object , Span`1 , BindingFlags )
--HttpRequestException
at System.Net.Http.HttpConnectionPool.ConnectToTcpHostAsync(String , Int32 , HttpRequestMessage , Boolean , CancellationToken )
at System.Net.Http.HttpConnectionPool.ConnectAsync(HttpRequestMessage , Boolean , CancellationToken )
at System.Net.Http.HttpConnectionPool.CreateHttp11ConnectionAsync(HttpRequestMessage , Boolean , CancellationToken )
at System.Net.Http.HttpConnectionPool.AddHttp11ConnectionAsync(QueueItem )
at System.Threading.Tasks.TaskCompletionSourceWithCancellation`1[[System.Net.Http.HttpConnection, System.Net.Http, Version=7.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a]].WaitWithCancellation(CancellationToken )
at System.Threading.Tasks.TaskCompletionSourceWithCancellation`1[[System.Net.Http.HttpConnection, System.Net.Http, Version=7.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a]].WaitWithCancellationAsync(Boolean , CancellationToken )
at System.Net.Http.HttpConnectionPool.HttpConnectionWaiter`1.<WaitForConnectionAsync>d__5[[System.Net.Http.HttpConnection, System.Net.Http, Version=7.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a]].MoveNext()
at System.Net.Http.HttpConnectionPool.SendWithVersionDetectionAndRetryAsync(HttpRequestMessage , Boolean , Boolean , CancellationToken )
at System.Net.Http.RedirectHandler.SendAsync(HttpRequestMessage , Boolean , CancellationToken )
at System.Net.Http.HttpMessageHandlerStage.Send(HttpRequestMessage , CancellationToken )
at System.Net.Http.SocketsHttpHandler.Send(HttpRequestMessage , CancellationToken )
at System.Net.Http.HttpMessageInvoker.Send(HttpRequestMessage , CancellationToken )
at System.Net.Http.HttpClient.Send(HttpRequestMessage , HttpCompletionOption , CancellationToken )
at System.Net.HttpWebRequest.SendRequest(Boolean )
at System.Net.HttpWebRequest.GetResponse()
--SocketException
at System.Net.Dns.GetHostEntryOrAddressesCore(String , Boolean , AddressFamily , Int64 )
at System.Net.Dns.GetHostAddressesCore(String , AddressFamily , Int64 )
at System.Net.Dns.GetHostAddresses(String , AddressFamily )
at System.Net.Dns.GetHostAddresses(String )
at System.Net.Sockets.Socket.Connect(String , Int32 )
at System.Net.Sockets.Socket.Connect(EndPoint )
at System.Net.HttpWebRequest.<>c__DisplayClass219_0.<<CreateHttpClient>b__1>d.MoveNext()
--- End of stack trace from previous location ---
at System.Net.Http.HttpConnectionPool.ConnectToTcpHostAsync(String , Int32 , HttpRequestMessage , Boolean , CancellationToken )
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.ILLink.Tasks**: from 8.0.0-preview.3.23171.4 to 8.0.0-preview.4.23176.4 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.AspNetCore.App.Ref**: from 8.0.0-preview.4.23171.7 to 8.0.0-preview.4.23176.6 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.NETCore.App.Ref**: from 8.0.0-preview.3.23171.4 to 8.0.0-preview.4.23176.4 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.NET.Workload.Emscripten.Current.Manifest-8.0.100.Transport**: from 8.0.0-preview.3.23167.1 to 8.0.0-preview.4.23170.1 (parent: Microsoft.NETCore.App.Ref)
- **Microsoft.NETCore.App.Ref**: from 8.0.0-preview.3.23171.4 to 8.0.0-preview.4.23176.4 (parent: Microsoft.Dotnet.Sdk.Internal)
## From https://github.com/dotnet/installer
- **Subscription**: 9a2944cb-7dee-4bf2-a65c-08dabd10ae64
- **Build**: 20230328.2
- **Date Produced**: March 28, 2023 10:27:20 AM UTC
- **Commit**: 69e28735b98581f2ee0825953de83a8581df7563
- **Branch**: refs/heads/main
- **Updates**:
- **Microsoft.Dotnet.Sdk.Internal**: [from 8.0.100-preview.4.23172.3 to 8.0.100-preview.4.23178.2][21]
- **Microsoft.NET.ILLink.Tasks**: [from 8.0.0-preview.3.23171.4 to 8.0.0-preview.4.23176.4][22]
- **Microsoft.AspNetCore.App.Ref**: [from 8.0.0-preview.4.23171.7 to 8.0.0-preview.4.23176.6][23]
- **Microsoft.NETCore.App.Ref**: [from 8.0.0-preview.3.23171.4 to 8.0.0-preview.4.23176.4][22]
- **Microsoft.NET.Workload.Emscripten.Current.Manifest-8.0.100.Transport**: [from 8.0.0-preview.3.23167.1 to 8.0.0-preview.4.23170.1][24]
- **Microsoft.NETCore.App.Ref**: [from 8.0.0-preview.3.23171.4 to 8.0.0-preview.4.23176.4][22]
[21]: 27622e3898...69e28735b9
[22]: edb161ab06...8d5f520838
[23]: 16907a1efa...c2350729d0
[24]: 25d9f7a5e3...a464820353
There's a 'link all' test that's verifying that the IntroducedAttribute is
linked away. It does so by verifying that the linked app doesn't have a
'IntroducedAttribute' type - but the test was constructing the fully qualified
type name to look for incorrectly:
ObjCRuntime.IntroducedAttribute, , Microsoft.iOS
Note the double comma: that meant we wouldn't find the type, even if it wasn't linked away.
The fix is easy (use a single comma), with one caveat (don't use a constant
string, because the linker sees the reference to
"ObjCRuntime.IntroducedAttribute" and _helpfully_ preserves it, exactly what
we don't want), but it revealed that the tested behavior regressed: a fully
linked app wouldn't link away the IntroducedAttribute.
So a fix is also needed: properly remove TVAttribute, WatchAttribute and
MacCatalystAttribute, which are subclasses of IntroducedAttribute (and what
would make the linker keep IntroducedAttribute).
Interestingly this showed up because of a bug in the runtime, where parsing
the invalid assembly name would now throw an exception
(https://github.com/dotnet/runtime/issues/84118).
This fixes a test failure when not including all platforms:
Cecil.Tests.BlittablePInvokes.CheckForNonBlittablePInvokes: Known failures that aren't failing anymore - remove these from the list of known failures: In the file tests/cecil-tests/BlittablePInvokes.cs, read the guide carefully.
Expected: <empty>
But was: < "AudioUnit.AudioComponentStatus AudioUnit.AudioUnit::AudioOutputUnitPublish(AudioUnit.AudioComponentDescription,System.IntPtr,System.UInt32,System.IntPtr)", ...
Fixes this test failure when building only for iOS (and similar for tvOS):
Xamarin.Tests.DotNetProjectTest.LibraryReferencingBindingLibrary(iOS): Existence
Expected: file or directory exists
But was: "/Users/builder/azdo/_work/4/s/xamarin-macios/tests/dotnet/LibraryReferencingBindingLibrary/iOS/bin/Debug/net7.0-ios/BindingWithDefaultCompileInclude.resources.zip"
Previously, we'd do this:
* Collect all possible native references.
* Extract any compressed native references (*.framework.zip, *.xcframework.zip,
*.resources.zip) to disk.
* Resolve the resulting native references.
This doesn't work very well on Windows (in non-connected/Hot Restart mode),
because some compressed files may contain symlinks (in particular compressed
xcframeworks). If those symlinks are for any other platform than the one we're
building for, they shouldn't matter, but if we extract the entire compressed
xcframework before figuring out what we need from it, we'd run into symlinks
and not knowing whether they should be ignored or not.
So rework the process to:
* Collect all possible native references.
* Resolve the resulting native references, peeking into zip files if need be.
* Extract any compressed native references, but only the parts of the zip we need.
This way we won't run into any symlinks unless we really need them, and it
should also improve build performance slightly, even on macOS, since we're not
extracting files we won't need (which can be significant for xcframeworks).
Additionally:
* Add support for unzipping on Windows by using System.IO.Compression.
* Show an error if attempting to extract a symlink in the last step in the
reworked process on Windows.
* Some tests had to be updated (since they poked into internals of the
ResolveNativeReferences task, and those internals have changed).
This fixes an issue in the BundleStructure tests:
> error MSB3030: Could not copy the file
"/Users/builder/azdo/_work/4/s/xamarin-macios/tests/dotnet/BundleStructure/NoneP.dll"
because it was not found.
This fixes a warning when documentation is enabled for a project:
> The file '~/.nuget/packages/fsharp.core/6.0.0/contentFiles/any/netstandard2.1/FSharp.Core.xml' does not specify a 'PublishFolderType' metadata, and a default value could not be calculated. The file will not be copied to the app bundle.
This doesn't change any behavior (as the warning says, the file wasn't copied
to the app bundle before either), but it makes the behavior explicitly
documented and silences the warning.
Fixes https://github.com/xamarin/xamarin-macios/issues/14939.
Fixes https://github.com/xamarin/xamarin-macios/issues/15897.
Context: https://dotnet.microsoft.com/platform/support/policy/maui
> A major version of .NET MAUI receives support for a minimum of 6
> months after a successor (the next major release) ships. For
> example, .NET MAUI 6.0 will be supported for 6 months after .NET
> MAUI 7.0 ships. Similarly, .NET MAUI 7.0 will receive support for 6
> months after .NET MAUI 8.0 ships.
By the time .NET 8 GA ships, .NET 6 MAUI projects will not be supported.
Remove .NET 6 support from our .NET 8 workloads.
Some changes:
1. Move all the static attr related methods to the attr factory.
2. Make it simpler to see the diff between NET and not by using a
partial class.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Set the GenerateRuntimeConfigurationFiles (GRCF) property to true
to avoid warnings at build time + add test for change.
Diving deeper into the fix...
- This warning only occurs with .NET apps which is why GRCF
is only updated in the dotnet directory and not msbuild (legacy)
- After examining the binlog (see issue), it was found that the GRCF
was contingent upon the HasRuntimeOutput property, which is only
defined for executable projects. And in this case, the user's project
output type is library thus both the RuntimeOutput and consequently
GRCF properties were not enabled.
- By setting the GRCF to true we can address the original warning of
concern while ensuring the rest of the projects's behavior is not
altered
in mysterious ways (i.e. by touching the RuntimeOutput property or the
project output type instead, these changes could have extraneous
effects).
Fixes#17543
---------
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
We have some code that verifies a list of failures against a known set of
failures and:
* Fails if any known failure is fixed.
* Fails if there any new (unknown) failures.
Create a helper method that contains this logic, since it's duplicated quite a
few times across various tests.
With a project structure like this:
* Executable project references a library project.
* The library project references a binding project (or assembly).
The binding project's assembly will be copied to the library project's
output directory during the build. Unless we also make sure any binding
resource packages are copied as well, the executable project won't find those,
and the final app won't contain any native bits from the binding project.
The solution is to add any binding resource packages to the list of
files to be copied to the library's output directory.
Fixes https://github.com/xamarin/xamarin-macios/issues/13910.
It seems we can get different results depending on OS versions, but I had no
success figuring out the conditions that make the results differ, so just
accept all variations we get.
There's not a finite list if measurement units, apps can create their own, so
we have to allow weakly typed measurement units (the normal property is bound
using a strong enum to NSRulerViewUnits).
Fixes https://github.com/xamarin/xamarin-macios/issues/17742.
## siminstaller
We are getting a `System.IO.IOException: Resource busy`
when trying to detach with hdiutil on Ventura. When reaching
this spot we are really done with the mounted resource so
let's force detaching and in the event that it fails let's
just log since at this point the simulator is installed.
## CI
Bump bots to use the Ventura images, and Add `macOSName`
parameter to our yaml templates.
`macOSName` maps to the `macOS.Name` capability in our bots, this
way we can set the macOS name we want to use on the bots in bot build and tests.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Change the generated block callbacks so that we only use blittable types
(so that the callbacks can become [UnmanagedCallersOnly]).
This involved two changes:
* Use pointer types instead of ref/out types ('int*' instead of 'ref/out int').
* Use 'byte' instead of 'bool'.
Contributes towards https://github.com/xamarin/xamarin-macios/issues/15783.
We'll soon build and run tests on Windows, and some tests use these response files,
so it makes building these tests on Windows easier if we don't have to re-create
the response files (our generation logic is all written in make, which is not the
easiest on Windows).
Fixes:
apitest.NSTextInputClient
[FAIL] NSTextInputClient_ShouldGetBaselineDelta : NSTextInputClient_ShouldGetBaselineDelta - Returned wrong baseline delta value
Expected: True
But was: False
at apitest.NSTextInputClient.NSTextInputClient_ShouldGetBaselineDelta () [0x0000e] in /Users/builder/azdo/_work/3/s/xamarin-macios/tests/monotouch-test/AppKit/NSTextInputClient.cs:108
[FAIL] NSTextInputClient_ShouldGetFirstRect : NSTextInputClient_ShouldGetFirstRect - Returned wrong rect
Expected: {X=0,Y=0,Width=12,Height=14}
But was: {X=0,Y=0,Width=0,Height=14}
at apitest.NSTextInputClient.NSTextInputClient_ShouldGetFirstRect () [0x00030] in /Users/builder/azdo/_work/3/s/xamarin-macios/tests/monotouch-test/AppKit/NSTextInputClient.cs:84
This pull request updates the following dependencies
## From https://github.com/dotnet/installer
- **Subscription**: 9a2944cb-7dee-4bf2-a65c-08dabd10ae64
- **Build**: 20230306.1
- **Date Produced**: March 6, 2023 10:15:46 AM UTC
- **Commit**: 51e06f6931e859f56564556fa6ba519761fa7141
- **Branch**: refs/heads/main
- **Updates**:
- **Microsoft.Dotnet.Sdk.Internal**: [from 8.0.100-preview.2.23108.2 to 8.0.100-preview.3.23156.1][77]
- **Microsoft.NET.ILLink.Tasks**: [from 8.0.0-preview.2.23107.1 to 8.0.0-preview.2.23127.4][78]
- **Microsoft.AspNetCore.App.Ref**: [from 8.0.0-preview.2.23107.2 to 8.0.0-preview.3.23127.13][79]
- **Microsoft.NETCore.App.Ref**: [from 8.0.0-preview.2.23107.1 to 8.0.0-preview.2.23127.4][78]
- **Microsoft.NET.Workload.Emscripten.Current.Manifest-8.0.100-preview.2**: [from 8.0.0-preview.2.23081.3 to 8.0.0-preview.2.23113.1][80]
[77]: 5a84050...51e06f6
[78]: e71a4fb...2bdc3cb
[79]: cec7fbf...3265dc6
[80]: 1d9df33...d7ff0aa
## 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.ILLink.Tasks**: from 8.0.0-preview.2.23107.1 to 8.0.0-preview.2.23127.4 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.AspNetCore.App.Ref**: from 8.0.0-preview.2.23107.2 to 8.0.0-preview.3.23127.13 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.NETCore.App.Ref**: from 8.0.0-preview.2.23107.1 to 8.0.0-preview.2.23127.4 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.NET.Workload.Emscripten.Current.Manifest-8.0.100-preview.2**: from 8.0.0-preview.2.23081.3 to 8.0.0-preview.2.23113.1 (parent: Microsoft.NETCore.App.Ref)
This will be required when we make blocks use blittable callbacks, since we'll
have to use pointers in a few cases (because ref/out arguments aren't
blittable).
Removed a flavor of `class_addMethod` that is unused.
Ignored a few cases that are going to be in .NET and/or may break AOT
optimizations
Now all iOS pivots pass, 17 macOS remain.
Naming could be problematic when generating code, move the logic out of
the generator class to a helper class whose only job is to name classes
and keep track of names.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Several changes:
- Refactored AsyncMethodInfo and move the collection extensions out of
the Generator class.
- Added tests for the collection extension methods.
- Fix a mistake/bug in which Last was used instead of LastOrDefault
(funny comment was close to the right reason).
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Move all the string methods that can be an extension to a static class
(re-use the present one) and add tests.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Co-authored-by: TJ Lambert <50846373+tj-devel709@users.noreply.github.com>
Added Ventura machines to macTestConfigurations within both the
build-ci-pipeline and the build-pr-pipelines.
---------
Co-authored-by: Alex Soto <alex@alexsoto.me>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
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.ILLink.Tasks**: from 8.0.100-1.23067.1 to 8.0.0-preview.2.23101.2 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.AspNetCore.App.Ref**: from 8.0.0-alpha.1.23076.8 to 8.0.0-preview.2.23101.7 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.NET.Workload.Emscripten.net7.Manifest-8.0.100**: from 8.0.0-alpha.1.23073.2 to 8.0.0-alpha.1.23066.1 (parent: Microsoft.NETCore.App.Ref)
- **Microsoft.NETCore.App.Ref**: from 8.0.0-alpha.1.23076.9 to 8.0.0-preview.2.23101.2 (parent: Microsoft.Dotnet.Sdk.Internal)
## From https://github.com/dotnet/installer
- **Subscription**: 9a2944cb-7dee-4bf2-a65c-08dabd10ae64
- **Build**: 20230202.11
- **Date Produced**: February 2, 2023 10:28:14 PM UTC
- **Commit**: 5c7737d740c861fe7cda4822a7137c22368000dc
- **Branch**: refs/heads/main
- **Updates**:
- **Microsoft.Dotnet.Sdk.Internal**: [from 8.0.100-alpha.1.23077.6 to 8.0.100-preview.2.23102.11][1]
- **Microsoft.NET.ILLink.Tasks**: [from 8.0.100-1.23067.1 to 8.0.0-preview.2.23101.2][2]
- **Microsoft.AspNetCore.App.Ref**: [from 8.0.0-alpha.1.23076.8 to 8.0.0-preview.2.23101.7][3]
- **Microsoft.NET.Workload.Emscripten.net7.Manifest-8.0.100**: [from 8.0.0-alpha.1.23073.2 to 8.0.0-alpha.1.23066.1][4]
- **Microsoft.NETCore.App.Ref**: [from 8.0.0-alpha.1.23076.9 to 8.0.0-preview.2.23101.2][5]
[1]: 1d88a6b...5c7737d
[2]: c790896...842ec4a
[3]: 4d75ee9...56cb24c
[4]: ff23620...5b46122
[5]: 007df05...842ec4a
Updates the pinvokes in CoreFoundation to have blittable types.
I intentionally did *not* do `CFReadStream` and `CFWriteStream` as the
changes needed for those are may create a breaking API change, so those
should probably be their own PR for closer scrutiny.
Please look closely at CFProxySupport as that was the least
straightforward of the changes.
Modify the code to add Xcode (DT*) variables to the Info.plist:
* Do it for all platforms, not only mobile platforms. Apple uses these fields to
determine if an app was built with a prerelease or old version of Xcode, and will
reject any app submissions if this validation fails.
* Change the behavior to do not distinguish simulator builds, a bit of testing
in Xcode shows that Xcode always adds these values to the Info.plist, even for
simulator builds. This is probably something that changed in Xcode a *long* time
ago, since this code is old (from the initial import of the build logic from MonoDevelop
around 10 years ago).
* Also bump Xamarin.MacDev to get a related fix:
New commits in xamarin/Xamarin.MacDev:
* xamarin/Xamarin.MacDev@74c95ee [Xamarin.MacDev] Always fetch the DTSDKBuild variable.
Diff: 14d53612d4..74c95ee1c3
Fixes https://github.com/xamarin/xamarin-macios/issues/13300.
* Add obsolete attributes for all platforms.
* Make sure the same obsolete message is used on all platforms.
* Fix a few typos.
There are many more APIs to fix (as evidenced by the fact that this only
removes a few known failures), but this is how far I've gotten right now.
Also fix a few issues:
* Fix an issue with replicating availability attributes with a third digit.
The third version number is 'Build', not 'Revision' (which is fourth), so
adjust our code accordingly.
This fixes an issue where the copy of 'macos10.15.4' would become
'macos10.15' and we'd lose the third number.
* Fix an issue when generating filter code. We were using the wrong type as
the target (inlined) type, resulting in the wrong availability attributes
getting created sometimes.
Autotools-based project using libtool's -module flag generate plugins
with the .so extension that needs to be treated like DynamicLibraries in
terms of deployment location and relocation, except they are not linked
to the app.
This PR adds support for such .so files: they're treated as .dylib files, except
that they're not linked to the app.
Additionally remove a lot of 64-bit-specific configurations
(Debug64/Release64) as well, and just make the default configurations
(Debug/Release) be 64-bit.
Peter Collins
Rolf Bjarne Kvinge
dotnet-maestro[bot]
Alex Soto
Manuel de la Pena
Haritha Mohan
Steve Hawley
dustin-wojciechowski
Andoni Morales Alastruey