* Update FabricBot with more useful commands
* Remove the 'awaiting-customer-response' label and corresponding tasks
* Ignore people with admin permissions
Co-authored-by: TJ Lambert <tjlambert@microsoft.com>
* Update FabricBot with more useful commands
* Remove the 'awaiting-customer-response' label and corresponding tasks
Co-authored-by: TJ Lambert <tjlambert@microsoft.com>
Fix lookup of block proxy attributes to look in protocols declared on base classes.
Broken pseudo code:
class BaseApplicationDelegate : NSObject, IUIApplicationDelegate {}
class MyApplicationDelegate : BaseApplicationDelegate {
[Export("application:didReceiveRemoteNotification:fetchCompletionHandler:")]
public void DidReceiveRemoteNotification (UIApplication application, NSDictionary userInfo, Action<UIBackgroundFetchResult> completionHandler) { }
}
the static registrar wouldn't figure out that the DidReceiveRemoteNotification method
comes from the UIApplicationDelegate, because it would only look in protocols defined
on MyApplicationDelegate, not any base classes.
The fix is to look in base classes too.
Also:
* Fix a boolean logic error when matching parameters between methods in another
(rarely used) code path when looking for matching binding methods in the extension
class for protocols with optional members.
* Add tests.
Fixes https://github.com/dotnet/maui/issues/6259.
We have a significant amount of logic using BUILD_REVISION to determine
whether we're in CI or not, so just set this variable to the current commit
hash.
We can't return unretained INativeObjects to Objective-C, because they might
be freed at any point when the GC collects the managed object. Instead return
retained objects, that way they're not freed even if the GC collects the
managed object.
This fixes a random crash in the TestRegistrar.TestINativeObject when the GC
would run just after we've returned an INativeObject to native code, and later
used that native handle thinking it would still be valid.
Fixes https://github.com/xamarin/maccore/issues/2572.
Resolves#14285
1. Make sure `libextension-dotnet.a` gets built, and with the `-DEXTENSION` flag.
2. Make sure `libextension-dotnet.a` gets included in the package alongside `libxamarin-dotnet.a`
3. At build time, make sure to link with the correct lib[tv]extension-dotnet.a library depending when we need to.
4. Add some tests.
Co-authored-by: Eric Sink <eric@Erics-MacBook-Pro.local>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.300-rtm.22219.35 -> To Version 6.0.300-rtm.22220.25
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* Workaround FirstChanceExceptionEventArgs being trimmed
See https://github.com/xamarin/xamarin-android/issues/6626
* Don't use ILLink descriptor on Microsoft.macOS.dll
It is using CoreCLR which doesn't run into the issue.
* Adding nullability
* use GetHandle ();
* Add nullable to TryGetX
Co-authored-by: TJ Lambert <tjlambert@microsoft.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
* Nullability Changes
* Using is nulls
* This one shouldnt use is null
* Leave in the parameters that should not be null in the ignores
* Addressing Rolfs nullability fixes
* forgot this AVKit change
* More Concise nulls
* Silence the string nullability for AVAudioSession
* add if not null
* Use default value from apple docs for KeyToEnum method and correct earlier rolf suggestion
* Nullable element missing
* change default to null
* removing casting and passing the errors
* throw and exception in the setter
Co-authored-by: TJ Lambert <tjlambert@microsoft.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
When building a binding project, we need to execute bgen (and csc) on the mac. Figuring
out where these files are on the Mac is rather complicated from a remotely executed
task, so instead we execute a sub-build that computes these properties.
In legacy Xamarin this was accomplished by building the 'Xamarin.iOS.ObjCBinding.Common.props'
file using msbuild, and invoking a custom target that prints the property we're looking
for (the 'targetGetPropertyValue_*' targets).
For multiple reasons this approach doesn't work in .NET anymore (in particular it
seems that the 'Xamarin.iOS.ObjCBinding.Common.After.targets' file with the custom
'targetGetPropertyValue_*' targets is nowhere to be found, but logic has also moved
around in the .targets/.props files which makes just building the 'Xamarin.iOS.ObjCBinding.Common.props'
not work correctly since the properties we need wouldn't be set).
So I'm adding a new task that does a sub-build, using either msbuild or dotnet as
appropriate, to compute the properties we need. Instead of building the 'Xamarin.iOS.ObjCBinding.Common.props'
file, the task creates an actual binding project (an empty one), and executes the
new '_WriteRemoteGeneratorProperties' target in this binding project.
An additional advantage in this new task is that it will only execute one sub-build
where all the properties are computed (the previous approach executed one sub-msbuild
per property).
In order to keep code as similar as possible between legacy Xamarin and .NET, the
new task is being used for legacy Xamarin as well (and the old approach deleted).
This fixes building binding projects on Windows in .NET.
If we try to process any exceptions, we'll throw an Objective-C exception,
which will likely be unhandled because we're pretty much at the top of the
stack, and when we handle this Objective-C exception we'll try to convert it
into a managed exception and throw that, and since there are no managed frames
on the stack we'll end up converting it to an Objective-C exception, which
we'll try to throw, and so on, eventually running into a stack overflow.
This is unnecessary, so just abort directly.
The output directory might or might not be where the app bundle is: by default
it is, but if someone sets the PkgPackageDir variable to provide an alternate
directory for the pkg, then that won't be where we'll find the app bundle.
The good news is that we already have a property that tells us where the app
bundle is (the 'AppBundleDir' property), so just use that instead.
Also:
* Make sure that the output directory exists before we try to write to it.
* Only pass full paths to productbuild, which for some reason doesn't seem to
like relative paths.
Fixes https://github.com/xamarin/xamarin-macios/issues/14751.
* Throw better exceptions
* use is null and is not null
Co-authored-by: tj_devel709 <antlambe@microsoft.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
* We now create a tracking GCHandle for all NSObjects, not only the toggled ones.
CoreCLR will notify us when a tracked GCHandle's target enters finalization, and
we need to be notified for all NSObjects, not just the toggled ones.
* Augment the tracking callback to know about non-toggled objects, and in that
case report that the tracking GCHandle is a weak GCHandle.
* There's no need to store the tracking GCHandle in a field in the NSObject instance,
since we store it in our runtime object_map.
* Remove one place where we set the InFinalizerQueue flag, since it's no longer
required there (this reverts a previous attempt at fixing this problem - 0622ae4af2)
- we only set the InFinalizerQueue flag in the xamarin_coreclr_reference_tracking_tracked_object_entered_finalization
callback now.
* Update a few comments accordingly.
Partial fix for https://github.com/xamarin/xamarin-macios/issues/13531.
Fixes https://github.com/xamarin/xamarin-macios/issues/13921 (again).
* We can remove entries in the object_map when the target is null (and we
don't need the corresponding GCHandle anymore, so it can be freed).
* When replacing an existing entry, we have to free the GCHandle.
Augment Runtime.GetNSObject to optionally create a new instance even if an
existing instance was found, if the existing instance isn't compatible with
the requested instance type.
Partial fix for https://github.com/xamarin/xamarin-macios/issues/13531.
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.300-rtm.22214.7 -> To Version 6.0.300-rtm.22219.35
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
We were trying to call the 'retain' and 'autorelease' selectors on objects
that weren't NSObjects when returning them from function calls. For some
unfathomable reason that has worked until now, but I started running into this
problem with other (unrelated) changes, so it needs to be fixed.
The fix is to not call the 'retain' and 'autorelease' selectors on
NativeObjects, instead call into managed code to either call the Retain method
on the managed NativeObject (if we're supposed to retain the return value), or
if we have to autorelease the return value, then check first if the input is
an NSObject, and only then call retain+autorelease.
Rather than having a single yaml template with several branches using ifs, we move to a single template that does the build and then this same template allows to perform a number of steps post build and before the clean up of the bot.
This allows to separate completely the steps used by the api diff and building the pkgs. The plan is to use this as the base to move the sining of the pkgs to a diff stage allowing the signing to run in parallel allowing to reduce the build time.
* Update dependencies from https://github.com/dotnet/installer build 20220406.8
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.300-preview.22205.8 -> To Version 6.0.300-preview.22206.8
* Update dependencies from https://github.com/dotnet/installer build 20220407.16
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.300-preview.22205.8 -> To Version 6.0.300-preview.22207.16
* Update dependencies from https://github.com/dotnet/installer build 20220408.1
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.300-preview.22205.8 -> To Version 6.0.300-preview.22208.1
* Update dependencies from https://github.com/dotnet/installer build 20220409.1
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.300-preview.22205.8 -> To Version 6.0.300-preview.22209.1
* Update dependencies from https://github.com/dotnet/installer build 20220411.2
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.300-preview.22205.8 -> To Version 6.0.300-preview.22211.2
* Update dependencies from https://github.com/dotnet/installer build 20220412.2
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.300-preview.22205.8 -> To Version 6.0.300-preview.22212.2
* Update dependencies from https://github.com/dotnet/installer build 20220412.25
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.300-preview.22205.8 -> To Version 6.0.300-preview.22212.25
* Update dependencies from https://github.com/dotnet/installer build 20220413.48
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.300-preview.22205.8 -> To Version 6.0.300-rtm.22213.48
Dependency coherency updates
Microsoft.AspNetCore.App.Ref
From Version 6.0.3 -> To Version 6.0.4 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220414.7
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.300-preview.22205.8 -> To Version 6.0.300-rtm.22214.7
Dependency coherency updates
Microsoft.AspNetCore.App.Ref
From Version 6.0.3 -> To Version 6.0.4 (parent: Microsoft.Dotnet.Sdk.Internal
* Find .NET's csc compiler.
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* Update dependencies from https://github.com/dotnet/runtime build 20220406.5
Microsoft.NETCore.App.Ref
From Version 6.0.5 -> To Version 6.0.5
* Update dependencies from https://github.com/dotnet/runtime build 20220411.4
Microsoft.NETCore.App.Ref
From Version 6.0.5 -> To Version 6.0.5
* Update dependencies from https://github.com/dotnet/runtime build 20220412.7
Microsoft.NETCore.App.Ref
From Version 6.0.5 -> To Version 6.0.5
* Update dependencies from https://github.com/dotnet/runtime build 20220413.11
Microsoft.NETCore.App.Ref
From Version 6.0.5 -> To Version 6.0.5
* Update dependencies from https://github.com/dotnet/runtime build 20220413.11
Microsoft.NETCore.App.Ref
From Version 6.0.5 -> To Version 6.0.5
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
The configuration job used to be ran only onces, because now it runs
several times we need to move the loc code out to make sure that we do
not generate more than one branch.
So that it doesn't do the wrong thing when the WORKSPACE variable isn't set
(such as trying to write stuff to the root directory).
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Manuel de la Pena
TJ Lambert
Rolf Bjarne Kvinge
Eric Sink
dotnet-maestro[bot]
Alexander Köplinger
Mauro Agnoletti
VS MobileTools Engineering Service 2