This also fixes a compiler warnings:
> tools/common/Rewriter.cs(333,25): warning CS8604: Possible null
reference argument for parameter 'path1' in 'string Path.Combine(string
path1, string path2)'.
And make nullability warnings in dotnet-linker show up as errors to
prevent future introduction of nullability warnings.
It's possible to create a provisioning profile for Mac Catalyst that
doesn't allow dylibs in the app. It seems a significant number of people run
into this problem when publishing their apps, so avoid it by linking Mono and
Xamarin statically by default instead.
The downside is that build time might increase a little bit.
An upside however is that the app size might decrease somewhat.
Fixes https://github.com/xamarin/xamarin-macios/issues/14686.
Our test projects may be using an earlier version of .NET (in particular
Touch.Unit and MonoTouch.Dialog often are), so ignore any warnings about
out-of-support workloads.
Fixes test failures like:
Xamarin.Tests.BundleStructureTest.Build(MacCatalyst,"maccatalyst-x64;maccatalyst-arm64",All,"Debug"): Warnings
Expected is <System.Collections.Generic.List`1[System.String]> with 22 elements, actual is <System.String[28]>
Values differ at index [22]
Extra: < "The workload 'maccatalyst' is out of support and will not receive security updates in the future. Please refer to https://aka.ms/maui-support-policy for more information about the support policy.", "The workload 'maccatalyst' is out of support and will not receive security updates in the future. Please refer to https://aka.ms/maui-support-policy for more information about the support policy.", "The workload 'maccatalyst' is out of support and will not receive security updates in the future. Please refer to https://aka.ms/maui-support-policy for more information about the support policy."... >
Additionally parse files in reverse order, because any variables at the
end should take precedence (when parsing config files the first time
variable is found is the one we use).
It's rather rare now that we need to disable .NET from the CI, so just
remove the option. It can still be disabled directly in the code when
needed.
Also this fixes an issue where we'd build with .NET enabled even if
disabled in the code, because we'd always pass --enable-dotnet to
configure.
If an assembly changes, then we must AOT compile that assembly again (which we already
did), in addition to any assembly that references the modified assembly (which we
didn't do).
So rework the AOTCompile target: remove the Inputs and Outputs (because the dependency
tracking is too complicated for MSBuild to resolve), and instead move the logic to
detect if an assembly must be AOT-compiled again into the AOTCompile task.
Note that this PR has a custom port to .NET 8: #18518.
Fixes https://github.com/xamarin/xamarin-macios/issues/17708.
---------
Co-authored-by: Alex Soto <alex@alexsoto.me>
Closes#18357
This PR implements the idea described in the linked issue:
Whenever there's an NSObject constructor that we call from a registrar
callback, we need to create
a separate constructor that will first set the `handle` and `flags`
values of the NSObject before
calling the original constructor. Here's an example of the code we
generate:
```csharp
// The original constructor:
public .ctor (T0 p0, T1 p1, ...) { /* ... */ }
// The generated constructor with pre-initialization:
public .ctor (T0 p0, T1 p1, ..., IntPtr handle, IManagedRegistrar dummy) {
this.handle = (NativeHandle)handle;
this.flags = 2; // Flags.NativeRef == 2
this..ctor (p0, p1, ...);
}
```
- This code can't be expressed in C# and it can only be expressed
directly in IL.
- The reason we need to do this is because the base NSObject
parameterless constructor
would allocate a new Objective-C object if `handle` is a zero pointer.
- The `IManagedRegistrar` type is added only to make the constructor
signature unique (IManagedRegistrar is not a public class and customers
can't use it in their apps directly)
This API was missed because the old sim intro tests are not running and
we missed it. This was found while working on xcode15. The tvOS attr is
missing which defaults to the min version of tvOS when it should be 15.
Added a compat implementation so that the API remains that will return
null.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Apple completely removed the NewsstandKit framework in Xode 15.
This effectively adds basic support for using Xcode 15 with .NET 7.
While this technically won't be a supported scenario, we have tests that
ensures .NET 7 apps can be built with .NET 8, and .NET 8 will ship with Xcode
15 support. This means that in order to make these tests work, we'll otherwise
have to have Xcode 14.3 installed both locally and on bots (in addition to
Xcode 15 of course), which is a rather big nightmare.
It's much easier to must try to make Xcode 15 work with .NET 7.
It seems that Apple will completely remove the NewsstandKit framework from iOS 17.
This poses a problem for existing apps that link with NewsstandKit: they will
crash at launch.
Solve this by always linking weakly with the NewsstandKit framework; this way
any apps that link with it will keep working if the framework ends up being
removed by Apple.
Fixes https://github.com/xamarin/xamarin-macios/issues/18606.
Fixes https://github.com/dotnet/maui/issues/16316.
This API was missed because the old sim intro tests are not running and
we missed it. This was found while working on xcode15. The tvOS attr is
missing which defaults to the min version of tvOS when it should be 15.
Added a compat implementation so that the API remains.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Similar to PR https://github.com/xamarin/xamarin-macios/pull/18600 we
need to use the same verison as the one found in the workload file in CI
and not that one from the make.config.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Add prIssueManagement.yml to onboard repo to GitOps.ResourceManagement
as FabricBot replacement
Owners of the FabricBot configuration should have received email
notification. The same information contained in the email is published
internally at: https://aka.ms/gim/fabricbot. Details on the replacement
service and the syntax of the new yaml configuration file is available
publicly at: https://microsoft.github.io/GitOps/policies/resource-management.html
This commit fixes the code that was added in
https://github.com/xamarin/xamarin-macios/pull/16361.
The previous change uses the version number that is part of the config
file in the current build machine. That is correct when we are working
when we are running the tests in the same machine that built them. That
IS NOT THE CASE when building on CI.
Back when the CI did the separation to accommodate the EO we noticed
that if the workload is built in a diff machine, the versions were not
to be trusted, that is why the CI sets and enviroment variable to track
the version that was built in the original step. This change check if we
are on the CI, if we are we trust the version given by the previos
machine, else we use the config one.
This is the pull request automatically created by the OneLocBuild task
in the build process to check-in localized files generated based upon
translation source files (.lcl files) handed-back from the downstream
localization pipeline. If there are issues in translations, visit
https://aka.ms/icxLocBug and log bugs for fixes. The OneLocBuild wiki is
https://aka.ms/onelocbuild and the localization process in general is
documented at https://aka.ms/AllAboutLoc.
This commit fixes the code that was added in
https://github.com/xamarin/xamarin-macios/pull/16361.
The previous change uses the version number that is part of the config
file in the current build machine. That is correct when we are working
when we are running the tests in the same machine that built them. That
IS NOT THE CASE when building on CI.
Back when the CI did the separation to accommodate the EO we noticed
that if the workload is built in a diff machine, the versions were not
to be trusted, that is why the CI sets and enviroment variable to track
the version that was built in the original step. This change check if we
are on the CI, if we are we trust the version given by the previos
machine, else we use the config one.
… the Build Agent and remote tasks
DOTNET_ROOT and DOTNET_HOST_PATH are being deprecated as a mechanism to
store the location of dotnet. PATH will be used instead, so we should
ensure that the existing code that makes usage of these variables is
adapted to the new guidelines. More information:
f454d6960ehttps://github.com/dotnet/runtime/issues/88754#issuecomment-1632957579
Additionally, to avoid confusion, we are using a dedicate
DOTNET_CUSTOM_PATH variable with the path of the dotnet used by the XMA
Build Agent, so it can be used internally by the tasks without mixing it
with the existing dotnet variables
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
… supporting XPC on File Provider instance
File Provider Service can act as an standalone XPC that you can
establish the connection with.
To open up the capability this new signature has to be exposed
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Co-authored-by: Alex Soto <alex@alexsoto.me>
Prior to changing to the new PAT to help with the automatization, we had
these lcl files waiting to be brought over. It's not clear if the new
PAT is fully working - we will need to wait until more translation codes
are added.
Rolf Bjarne Kvinge
dotnet-maestro[bot]
Manuel de la Pena
Šimon Rozsíval
Alexander Köplinger
microsoft-github-policy-service[bot]
Mauro Agnoletti
VS MobileTools Engineering Service 2
JonnHard
TJ Lambert
Emanuel Fernandez Dell'Oca