Add a Visual Basic templates for:
* All our platforms (iOS, tvOS, macOS and Mac Catalyst).
* A simple project (the ios, tvos, macos and maccatalyst templates).
* A class library property (the ioslib, tvoslib, macoslib and maccatalystlib templates).
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>
The PrintAttributes method defaults to not printing anything, and when then
asked to not print platform attributes, it still adds up to doing nothing, so
just remove this redundant method call.
We used to show this:
> ILLINK warning MT1302: Could not extract the native library 'StaticLibrary.a' from '~/Downloads/BindingTest/obj/Debug/net7.0-ios/iossimulator-x64/linker-cache/StaticLibrary.a'. Please ensure the native library was properly embedded in the managed assembly (if the assembly was built using a binding project, the native library must be included in the project, and its Build Action must be 'ObjcBindingNativeLibrary').
now we show the assembly:
> ILLINK warning MT1302: Could not extract the native library 'StaticLibrary.a' from '~/Downloads/BindingTest/obj/Debug/net7.0-ios/iossimulator-x64/linker-cache/BindingLibrary.dll'. Please ensure the native library was properly embedded in the managed assembly (if the assembly was built using a binding project, the native library must be included in the project, and its Build Action must be 'ObjcBindingNativeLibrary').
Also increase diagnostics for this failure scenario to list all the resources
in the given assembly.
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.
The bug manifests like this:
> Could not create an native instance of the type WindowsAzure.Messaging.SBNotificationHub: the native class hasn't been loaded.
which happens because the SBNotificationHub doesn't exist in the final
executable. We asked the linker to link with the static library containing
this type, but the linker didn't link with the library because it didn't need
any of the symbols in it.
We should have collected all the exported Objective-C types from this library
and asked the native linker to keep them, but that didn't happen because:
1. We collect bound Objective-C classes from binding libraries here (the
ListExportedSymbolsStep): 608765e2c9/tools/linker/MonoTouch.Tuner/ListExportedSymbols.cs (L148-L157)
2. That only happens for attributes with a LinkWith attribute.
* We compute if an assembly has a LinkWith attribute here:
608765e2c9/tools/common/Assembly.cs (L266)
* Which is called from here:
608765e2c9/tools/common/Assembly.cs (L198)
* Which is called from here (the ExtractBindingLibrariesStep):
608765e2c9/tools/dotnet-linker/Steps/ExtractBindingLibrariesStep.cs (L18)
Now, we must obviously compute if an assembly has a LinkWith attribute before
doing anything that depends on that value, but we weren't doing things in that
order.
Changing the custom linker steps to run the ListExportedSymbols step *after*
the ExtractBindingLibrariesStep fixes this logic problem.
Fixes https://github.com/xamarin/xamarin-macios/issues/17347.
Try to fix #xamarin/maccore@2637 by making sure a file's timestamp changes
after make runs the corresponding target.
Otherwise it seems make may run into some sort of infinite loop.
Fixes https://github.com/xamarin/maccore/issues/2637.
Automated PR. Bring new translated changes in the lcl files for
OneLocBuild to create translated resx files.
Co-authored-by: Alex Hsu <csigs@users.noreply.github.com>
Co-authored-by: CSIGS <csigs@outlook.com>
There's no trace of this in the headers, so I assume it's something that
happened in a beta and then got removed, and we didn't notice to update our
bindings.
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>
ARKit is in a weird spot on Mac Catalyst: it exists, but it doesn't do
anything. Since it doesn't actually work, we don't have bindings for ARKit.
This means that while the method '[NISession setARSession:]' technically
exists on Mac Catalyst, we can't bind it properly, since the type of the
parameter (ARSession) isn't available in our bindings for Mac Catalyst.
Due to how we hack around the lack of ARSession in our source code, we ended
up binding the method with an NSObject argument instead. This is still wrong,
so here I'm removing that method from the API.
But of course, removing that API is a breaking change, so until then the
method is obsoleted and hidden, and only removed in XAMCORE_5_0.
Also hide a few other obsoleted API in NISession, and remove those as well in
XAMCORE_5_0.
The API for MPMediaItem/MPMediaEntity varies wildly between platforms (for
historical reasons), so move availability attributes around a bit so that they
match reality a bit better: MPMediaEntity is not available on macOS, only
MPMediaItem is.
According to the compilation compilation directives, these APIs are not
available on tvOS nor macOS, so update the availability attributes
accordingly.
The ifdefs here were confusing, so I cleaned them up a bit.
Note that No* attributes in enum members won't prevent the enum members from
being generated, they'll just get an unavailable attribute, so adding No*
attributes to an enum member is not a breaking change (which allows for some
of this cleanup).
Contributes towards #14802.
Apple provides the headers to target PushToTalk (so using PushToTalk in code
builds just fine for the simulator in Xcode), but it doesn't work at runtime.
I believe it's better to allow the same thing in our bindings, for two reasons:
* Apple prints out a helpful error message at runtime, instead of our rather
incomprehensible build error.
* Apple might implement simulator support in the future, in which case we
won't need to do anything else.
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.
Handle the 'need-repro' label like the 'need-info' label:
* Add a comment that we need a repro, and how to get one.
* Close the issue if no comments within 7 days.
* Add a 'need-attention' label if reporter comments.
Also add a document explaining how to create a repro, modeled after (copied)
MAUI's document (https://github.com/dotnet/maui/blob/main/.github/repro.md).
New workflows:
1. When a `move-to-vs-feedback` label is applied to an issue, tell the
user to use the VS Feedback tool instead.
2. If issue is commented on within 3 days, mark as `needs-attention`.
3. If issue is inactive for 3 days, close the issue.
This is a shameless copy of
05c5e202a3.
Rolf Bjarne Kvinge
dustin-wojciechowski
dotnet-maestro[bot]
Mauro Agnoletti
Manuel de la Pena
Steve Hawley
github-actions[bot]