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 )
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.
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 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>
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.
Moved the extension methods to their own file and enabled nullable.
Fixed the following underlying bug:
The extension method that creates a valid parameter named does not do
the right thing in the following cases:
1. When the starting illegal char is NOT a number. It will prepend @
fixing nothing. Example " OHOH" to "@ OHOH"
2. When the illegal chars is in the middle of the param name. Example
"OH OH" to "@OH OH"
I have fixed the method to return null in those ocassions (we will need
to enable nullability later in the generator, is too much for this PR).
Tests have been added to ensure we do not have such an issue again.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Stop implying Mac Catalyst attributes from the iOS attributes, and instead
treat Mac Catalyst like all the other platforms (not implying anything from
any other platform).
This makes our attribute logic much easier to reason about and understand.
It also required adding numerous Mac Catalyst attributes that were previously
implied. This task was way too big to do manually, so I made some changes to
Chris' mellite tool, and managed to do it quite easily with Roslyn with the
changes in this branch: https://github.com/rolfbjarne/mellite/tree/explicit-maccatalyst-attributes
This is the first part of a 2 or more changes that will allow the APIs
to use ? as a way to mark a nullable field, parameter, property and
return method.
The way it works follows the documentation from the runtime that can be
found here:
https://github.com/dotnet/roslyn/blob/main/docs/features/nullable-metadata.md
The tldr; of the documentation is as follows:
1. If we are looking at a value type, the compiler converts int? into
Nullable<int>. This was already considered in the old code.
2. If we are inspecting a generic type we have to look for the
information in two different attributes added by the compiler: -
NullableAttribute: Each type reference in metadata may have an
associated NullableAttribute with a byte[] where each byte represents
nullability: 0 for oblivious, 1 for not annotated, and 2 for annotated.
- NullableContextAttribute is valid in metadata on type and method
declarations. The byte value represents the implicit NullableAttribute
value for type reference within that scope that do not have an explicit
NullableAttribute and would not otherwise be represented by an empty
byte[].
The API is very similar to that provided by dotnet6 but it allows us to
support classic. The move to the dotnet6 API should not be hard and
probably can be done by an IDE.
Once this API lands we will have to find the old usages of the check for
nullability and combine both. This new API should fix several issues we
have with nullability and nullability + generics.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Protocols with one set of introduced attributes ([TV (12, 0)]) inlined in
types that were introduced in a different version ([TV (10, 0)]) would always
use the attributes from the type.
This is wrong if the protocol was introduced after the type, in which case we
should instead use the introduced attributes from the protocol.
Fix this by choosing the latest introduced attribute when we have multiple to
choose from.
This required passing a bit more information around so that we always know if
a member is being inlined in another type.
This PR will also print availability attributes on the protocol members themselves:
[Protocol]
interface IProtocol
{
[TV (12, 0)] // this was not printed before
[Export ("someProperty")]
string SomeProperty { get; set; }
}
Also add and improve some tests.
Contributes towards https://github.com/xamarin/xamarin-macios/issues/14802.
Fixes#17162
Added GPSLatitudeRef and GPSLongitudeRef to CGImagePropertiesGPS.
Added new photo to all resources folders that has GPS data.
Created new test that reads GPS information off a photo and verifies that it is correct.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
* Fix an issue where it would not compute the correct grouping key for each member,
effectively grouping unrelated members together and coming up with weird and incorrect
results.
* Make it match failures exactly, which makes it possible to detect (and report,
which it now does) when a known failure is fixed.
* Ignore any hidden members (EditorBrowsableState.Never), because they're most
likely mistakes.
* Ignore any members in AppKit and UIKit, because these namespaces have a lot of
conflicting availability attributes. This is tracked in a separate bug (#17292).
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
This PR handles two scenarios (fixed in separate commits):
Scenario 1:
* The property has different availability attributes than the containing type.
* The property's accessor(s) do not have availability attributes.
We'd generate the wrong availability attributes for the property accessors,
because we'd take the type's availability attributes and add them to the
accessors.
As for the fix: I can't really explain it. This code is rather impenetrable,
and the parameter names don't make much sense, but whatever I did seems to
work?
And it turns out this fix shows up in an existing test as well (the
generator's Bug35176 test), which I had to modify to remove the expectation of
(now redundant) availability attributes that we no longer produce.
Scenario 2:
* Type is available on iOS, tvOS.
* Property in the type is available on iOS (and not tvOS).
* Property accessor has explicit availability attributes for iOS.
Then the property accessor would get the availability attribute for tvOS from
the type, and not the (un)availability attribute from the property.
The fix is to make sure the parent context is the property (and not the type)
when processing availability attributes for the accessor.
I've started seeing more random network delays on these tests recently - which
the tests themselves handle, but the test run ends up taking much longer, and
we need to give the test run more time to finish.
Provided manual binding of AVAudioPlayer::initWithContentsOfURL:error: and AVAudioPlayer::initWithData:error: to prevent an issue where AVAudioPlayer::FromData() and FromUrl() do not throw exceptions when returning null.
Fixes#16229
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
According to the compilation compilation directives, these APIs are not
available on tvOS nor macOS, so update the availability attributes
accordingly.
In the following scenario:
* Type T is not available on a platform (say tvOS).
* Protocol P is available on said platform.
* A member M of P has its own availability attribute for said platform (for
instance if P is available on tvOS 11.0, and the member is available on tvOS
12.0).
* The protocol P is inlined into the type T.
We'd include the SupportedOSPlatform attribute from the inlined member on
generated code on other platforms (so the iOS assembly would say that the
inlined member M in T is available on tvOS).
Fixes https://github.com/xamarin/xamarin-macios/issues/17268.
.NET 6 doesn't define the minimum supported OS version property, which means
we can't use the existing logic to automatically determine the min OS version
to use as the default SupportedOSPlatformVersion in the .NET 6, so hardcode
the value.
Previously API definitions like this:
string Property {
get;
[NoiOS]
set;
}
would generate a setter for every platform, even iOS.
This is rather unexpected, so fix the generator to honor No* attributes on
property getters and setters.
Unify a lot of code related to how to load test assemblies.
This resulted in adding a couple of test assemblies to monotouch-test when executed on macOS (this was a bug), and this also required adapting some of those tests to work correctly on macOS.
If we're creating a universal app, and here are satellite assemblies that are not
identical across all RuntimeIdentifiers, those assemblies will be stored in a RuntimeIdentifier-specific
subdirectory during the build.
Unfortunately we didn't know how to find those assemblies at runtime, causing localizations
in universal apps to not work.
This change will:
* Add support for looking in the directory where RID-specific satellite assemblies
are stored.
* Add an assembly resolution event handler to our CoreCLR bridge so that we can
execute our custom lookup code.
* Add an assembly resource lookup test to monotouch-test.
* Add a macOS + Mac Catalyst variation of monotouch-test to xharness that triggers
the bug (a universal test app).
Fixes https://github.com/xamarin/xamarin-macios/issues/16847.
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.
* 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>
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>
Rolf Bjarne Kvinge
Alex Soto
Manuel de la Pena
Haritha Mohan
Steve Hawley
dustin-wojciechowski
Andoni Morales Alastruey
Timothé Larivière