Try to make CoreServices.FSEventStreamTest better by using shorter duration locks,
and re-checking success condition after timing out in case there’s a race condition.
Also improve exception reporting/logging a bit.
Ref: https://github.com/xamarin/maccore/issues/2630
Added default entitlements for MacCatalyst templates.
For Debug, the com.apple.security.get-task-allow entitlement that allows for using developer tools when developing MAUI Blazor apps.
For release, com.apple.security.app-sandbox is required to publish MacCatalyst apps to the Mac App Store.
Also added unit test to check for entitlements when project is created.
Fixes#18344
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Some time ago we added a workaround for an msbuild bug that has since
been fixed (since the initial .NET 7 release). This workaround involved
writing build properties to a file instead of passing them on the
command line.
We no longer need the workaround, but it turnes out we still need to be
able to pass build properties in a file (because we have a test that
needs this behavior). We'll also soon run into a scenario where we need
to be able to specify a build property on the command line
(`TargetFrameworks`) - the build won't work if specified in a file.
So add support for both, and make the test that needs to specify the
build property on the command line say so explicitly.
When figuring out whether something needs to be (re)signed or not, we must
also take into account that the signing identity may have changed (for
instance a release build will often have a different signing identity than a
debug build).
Do this by storing the command line to sign for each item we need to sign in
the stamp file, and if the stored contents don't match the new command line
to sign, then we must resign the item.
This is rather obnoxious to write unit tests for (since we'd need to have two
different signing identities available on the bots), so I've only done local
testing.
Fixes https://github.com/xamarin/xamarin-macios/issues/16124.
* A property set on the command line is set for all projects that are built,
including projects referenced by the main project.
* If the main project references more than one project, those referenced
projects may be built in parallel.
* This means multiple projects might have the same IntermediateOutputPath if
set on the command line, and thus accessing files in the directory
simultaneously, which is a bad idea.
Fix this by manually disabling build parallelism in tests that set
IntermediateOutputPath.
Fixes https://github.com/xamarin/maccore/issues/2567.
We'll soon change the generator to execute locally on Windows, even for
remote builds. As a stepping stone towards that goal, this PR adds the
generator tests to the list of tests we run on Windows.
Setting test configuration variables using the environment is useful
when running tests on a Windows machine (easier than having to deal with
make).
Also refactor the code a bit to not use constants, and more consistent
naming.
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).
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>
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>
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.
… 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>
Detect if a url we use in our tests actually works, and if not, save the
results and ignore any subsequent test that tries to use that url.
---------
Co-authored-by: Haritha Mohan <harithamohan@microsoft.com>
For a given dylib named '/path/to/libMyLibrary.dylib', we pass this to the native linker:
-L/path/to -lMyLibrary
however, that doesn't work unless the dylib's name starts with 'lib'.
So detect this, and if the dylib doesn't start with 'lib' (say it's just
'MyLibrary.dylib'), then just pass the path to the dylib as-is to the native
linker:
/path/to/MyLibrary.dylib
Fixes https://github.com/xamarin/xamarin-macios/issues/15044.
* The 'copyCGImageAtTime:actualTime:error:' selector is deprecated, so
replicate that.
* Bind the 'generateCGImageAsynchronouslyForTime:completionHandler:'
selector.
Fixes parts 1 and 2 of https://github.com/xamarin/xamarin-macios/issues/18452.
Add public targets to compute the mlaunch command lines for installing
and launching mobile apps.
These new targets are:
* ComputeMlaunchInstallArguments
* ComputeMlaunchRunArguments
As part of this change, also create a few new public properties:
* MlaunchPath
* MlaunchRunArguments
* MlaunchInstallArguments
* MlaunchRunScript
* MlaunchInstallScript
If the *Script variables are set, the corresponding target will create a
script file with the path to mlaunch + the corresponding arguments.
Otherwise, it's also possible to get the arguments directly from the
build log.
Fixes https://github.com/xamarin/xamarin-macios/issues/18359.
Fixes#17707
The error target for when there is a conflict of interest in defining
both the runtime identifier and runtime identifiers is called during the
multi-rid builds, but not sure if the placement is the most ideal..
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Alex Soto <alex@alexsoto.me>
* Move all the RunAsync logic to the TestRuntime class, instead of having some
in TestRuntime and some in AppDelegate.
* Create a unified Task-based implementation for all platforms, optionally showing
a UI on the platforms where we can do that.
* Remove all the overloads that took a DateTime timeout, and instead only use a
TimeSpan timeout. This simplified some of the code.
* The new Task-based implementation will capture any exceptions (and rethrow most
of them) from the tasks we're waiting for, so no need to do that in each RunAsync
caller. This simplifies the testing code a lot for some tests.
* Add a new TryRunAsync method that will return (instead of rethrowing) any exceptions.
This simplifies some of the testing code (which verifies the correct exception,
or ignores the test in case of some exceptions).
* The new Task-based implementation will bubble up any NUnit exceptions, which
means that the tasks we're waiting for can call NUnit's Assert and the right thing
happens (in particular Assert.Ignore will actually ignore the test).
Fixes:
MonoTouchFixtures.AVFoundation.CaptureMetadataOutputTest
[PASS] Defaults
[PASS] Flags
[FAIL] MetadataObjectTypesTest : System.NotImplementedException : The method or operation is not implemented.
at TestRuntime.CheckXcodeVersion(Int32 major, Int32 minor, Int32 build) in xamarin-macios/tests/common/TestRuntime.cs:line 483
at MonoTouchFixtures.AVFoundation.CaptureMetadataOutputTest.MetadataObjectTypesTest() in xamarin-macios/tests/monotouch-test/AVFoundation/CaptureMetadataOutputTest.cs:line 131
at System.Reflection.MethodInvoker.InterpretedInvoke(Object , Span`1 , BindingFlags )