* Mark a few MediaExtension fields as Notification fields.
* Remove extreanous NSSharingCollaborationModeRestriction.AlertRecoverySuggestionButtonLaunchUrl setter.
* introspection: ignore methods that start with '_Init', aren't publicly
visible, and bind an Objective-C constructor when verifying that a managed
method doesn't bind an Objective-C constructor.
* Remove all legacy code.
* Fix all warnings.
* Enable warnings as errors.
* Started unifying code between macOS vs iOS/tvOS/MacCatalyst.
* Updated README slightly.
Retry the test 10 times if it fails - it uses a shared resource (the
pasteboard), so it's possible to run into race conditions if the same test
also runs in a different process at the same time.
Also remove code that we removed a long time ago, so that the test actually
runs: 86ab2bc1d1.
Hopefully fixes https://github.com/xamarin/maccore/issues/2569.
This adds support for including all app icons in the app, as well as for specifying alternate app icons.
Including all app icons is enabled by setting the following MSBuild property:
```xml
<PropertyGroup>
<IncludeAllAppIcons>true</IncludeAllAppIcons>
</PropertyGroup>
````
This will make the `ACTool` task pass `--include-all-app-icons` to `actool` when compiling the asset catalog.
Specifying alternate app icon(s) is enabled by setting the following MSBuild item:
```xml
<ItemGroup>
<AlternateAppIcon Include="MyAlternateAppIcon" />
<AlternateAppIcon Include="MyOtherAlternateAppIcon" />
</ItemGroup>
```
Note that the included value is the name if the icon in question, not the path or the filename of the actual icon file (this way there's no need to have different items for different platforms, because there are some platform differences with regards to paths and icon file extensions).
In order to make the behavior consistent, this PR also adds support for specifying the app icon itself using an MSBuild property (in addition to the existing Info.plist property `XSAppIconAssets`, which will eventually be deprecated):
```xml
<PropertyGroup>
<AppIcon>MyAppIcon</AppIcon>
</PropertyGroup>
```
The same note applies here: the value is the name of the icon.
Note about platforms: the code is there for all platforms (iOS, tvOS, macOS and Mac Catalyst), but alternate app icons only seem to work for iOS and tvOS. `UIApplication.SupportsAlternateIcons` always returns `false` on Mac Catalyst (googling only find people in the same situation), and macOS doesn't have this API to begin with (nor anything similar):
Also:
* Add a bunch of tests.
* Document on our website: https://github.com/dotnet/docs-mobile/pull/53
* Samples for iOS and tvOS: https://github.com/dotnet/macios-samples/pull/2
Fixes https://github.com/xamarin/xamarin-macios/issues/12790.
Fixes https://github.com/xamarin/xamarin-macios/issues/20182.
It's not used anymore, because we only create a single markdown document for
each platform in .NET (because we only ship a single assembly for each platform now).
* Run both sets of Windows tests (local and remote), and fail afterwards if there
are test failures. This way we get both test suites executed even if the first
one fails.
* Create a script for executing the local tests (makes it easier to run locally
as well).
* Make it possible to use a custom built .NET locally by honoring any DOTNET variable
instead of blindly setting it (makes it easier to test locally).
* Add a .gitignore for the test configuration file we create to run tests on Windows.
* Some minor code simplifications.
* Update the makefiles to remove legacy logic.
* Port the mtouch/mmp projects to a .NET project, and make the necessary code
changes to keep it working (we still use mtouch/mmp during our build to
generate the partial static registrar code).
* Misc other related changes.
In order to fully take advantage of the
[caching](https://github.com/dotnet/roslyn/blob/main/docs/features/incremental-generators.md#caching)
provided by the incremental code generator infrastructure we move to use
a data model that will represent the code changes that will trigger a
regeneration of certain classes.
The current implementation only takes care of the changes that will
trigger a regeneration on enums:
1. Enum fully qualified name changed.
2. Attributes added or removed in the enum.
2. Enum values added/removed.
We provide our own Comparer to have more control on how the structures
are compared.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* Remove test cases for 32-bit arm, which we don't support anymore.
* Use test-level test cases instead of fixture-level test cases, because the
fixture-level test cases are all rendered identically in both the console
output and the html report, making it impossible to figure out which
variation failed when something goes wrong.
* Add new assets related to app icons.
* Update according to new test project assets.
* Ask 'assetutil` to write the output we care about to a file, that way we
don't have to take random stdout output into account.
* Simplify how the test asserts asset catalog contents to include all assets,
not just a selection of them.
Note: might be easier to review commit-by-commit, because there's a lot of new
assets and I'm adding them in a separate commit.
For universal apps, we compile as many resources as we can in the outer
(universal) build, and then pass a path to a temporary file with a list of
those compiled resources to the inner (rid-specific) builds, so that the inner
builds can skip them.
We have to delete this temporary file after the inner builds have completed,
otherwise they may interfere with subsequent builds if the set of resources
has changed.
However, this revealed another issue with incremental builds: we still need to
write out this temporary file even if the outer build won't compile the
resources because they were compiled in a previous build, otherwise the inner
builds would unnecessarily compile those resources.
An upcoming test for a new feature found this issue, so I'm not adding a test.
* Find all git repositories in the default working directory, for both
multi-repo checkouts and single-repo checkouts, and clean them all.
* Completely remove the 'packages' directory before putting any other files in
it.
When MSBuild crashes, MSBuild creates a log file and prints:
> error MSB4166: Child node "3" exited prematurely. Shutting down. Diagnostic information may be found in files in "/var/folders/52/tx7jvhs16x19bkdf030_nyww0000gn/T/MSBuildTempbuilder/" and will be named MSBuild_*.failure.txt. This location can be changed by setting the MSBUILDDEBUGPATH environment variable to a different directory.
However, these log files aren't accessible after a CI build has concluded, so
set the MSBUILDDEBUGPATH environment variable to the jenkins-results
directory, which will be uploaded as a build artifact.
This way we can inspect whatever made MSBuild fail in a CI build.
Rolf Bjarne Kvinge
Alex Soto
dotnet-maestro[bot]
Manuel de la Pena
Mauro Agnoletti