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.
Apple completely removed the NewsstandKit framework and the
PKDisbursementAuthorizationController[Delegate] types in Xode 15, so
let's not generate any corresponding code in the static registrar.
This effectively adds basic support for using Xcode 15 with .NET 7 (take
2).
Ref #18779
- We can get rid of Activator.CreateInstance in
`DictionaryContainer.GetStrongDictionary<T>` by passing a factory method
- For the cases where we need to use Activator.CreateInstance we need to
add `[DynamicallyAccessedMembers(...)]` to the type parameter
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.
* Don't strip resource assemblies, there's no code in them to strip anyways.
* Use the relative path inside the app bundle when computing the intermediate
location for stripped assemblies, so that if we were to find two identically
named assemblies in different directories, they're handled correctly (by
putting them in different intermediate locations, instead of overwriting
eachother).
Fixes https://github.com/xamarin/xamarin-macios/issues/17262.
This makes it easier to run some tests on Windows, because the tests
reference this file and by having it checked in it doesn't need to be generated
(which we currently do using make, which isn't trivial on Windows).
Also adjust the generated output slightly to make it easier on the eyes.
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.
This seems to happen fairly often:
+ xcrun simctl diagnose -b -X --output=/Users/builder/azdo/_work/1/s/diagnostic-sim-output/output
Error creating archive at '/Users/builder/azdo/_work/1/s/diagnostic-sim-output/output.tar.gz'.
Files are still in /Users/builder/azdo/_work/1/s/diagnostic-sim-output/output
An error was encountered processing the command
(domain=NSPOSIXErrorDomain, code=17):
Unable to write or file already exists
File exists
The output directory is empty (created in the line before), so I have no
idea what's going on.
An archive with the diagnostic info still seems to be created though, so
just ignore any failures from 'simctl diagnose' instead of bubbling them up
to Azure DevOps. This makes our test runs not show up with warnings.
XDocument.Load(string) takes a URI, not a file path. This usually works if
there are no special characters in the file path, but for instance with a path
with a colon (say 'a:b/some/file'), we'll get an exception about invalid uri
scheme.
So instead use the XDocument.Load(Stream) overload, and create the stream
using the file path instead, in which case there's no problem with special
characters.
This is a bit non-obvious, but we later use the presence of such a
stored list to determine if we need to generate the __Registrar__ type in the
assembly.
The problem is that we need to generate the __Registrar__ type even if
no trampolines were created, because we use it for numerous other purposes
as well (type lookup for instance).
Fixes https://github.com/xamarin/xamarin-macios/issues/18570.
The .mobile.props file is a file created and written by the mobile VS
extension to store property values that needs to be read early enough in
the build chain, as in design time builds, and that can't be set by CPS
because of a limitation in the project system. See more information
here: https://github.com/xamarin/XamarinVS/pull/13606
Initially it was named .user.env file and then was renamed in another PR
as part of a feedback from the project system team. See more information
here: https://github.com/xamarin/XamarinVS/pull/13628
Because this file was saved in the intermediate output path, it was
meant to be imported automatically by MSBuild, however we recently
detected that this was not happening reliably. Because of this, some
things like C# Hot Reload for iOS stopped working because Roslyn was
reading incorrect values from the Design Time Builds.
For that reason and to avoid relying on the project system, I'm
importing this file explicitly (and removing old .user.env import), so
the values in the file are always available and the dependent properties
are calculated correctly and available for all the consumers (including
Roslyn).
This should fix the following bugs:
https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1822041https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1851677
This PR adds lookup tables and factory methods for INativeObjects and
NSObjects. These generated methods allow us to create instances of these
objects without needing reflection.
Closes#18358.
We can determine the exact constructor to call when creating
INativeObject instances in the generated code, so do exactly that.
This avoids a lot of slow reflection, and also makes the constructor
call visible for any linkers.
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).
Rolf Bjarne Kvinge
dotnet-maestro[bot]
dustin-wojciechowski
Manuel de la Pena
Šimon Rozsíval
Filip Navara
Mauro Agnoletti