Context:
06fea905cf
In order to add .NET 9 Xcode16.1 builds to VS we'll need to insert packs
from two different commits on the `release/9.0.1xx-preview` branch.
Xcode information will now be added to the VS manifest that we generate
to allow us to produce unique manifests across the same branch.
Add the code generation for smart enumerators. This means the following
changes:
1. Refactor the way we register the diff pipelines.
2. Add code that generates the Extension class for the enums.
3. Add code that will generate the Library.g.cs partial class.
---------
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
If an assembly only required the lookup tables from the managed static
registrar (and not any other code), we wouldn't save those changes.
This would lead to a runtime exception:
```
Microsoft.iOS: Processing Objective-C exception for exception marshalling (mode: 2):
Could not find the type 'ObjCRuntime.__Registrar__' in the assembly 'X.Y.Z'. (ObjCRuntime.RuntimeException)
at ObjCRuntime.RegistrarHelper.GetMapEntry(String assemblyName) in /Users/builder/azdo/_work/1/s/xamarin-macios/src/ObjCRuntime/RegistrarHelper.cs:line 105
at ObjCRuntime.RegistrarHelper.GetMapEntry(Assembly assembly) in /Users/builder/azdo/_work/1/s/xamarin-macios/src/ObjCRuntime/RegistrarHelper.cs:line 93
at ObjCRuntime.RegistrarHelper.LookupRegisteredType(Assembly assembly, UInt32 id) in /Users/builder/azdo/_work/1/s/xamarin-macios/src/ObjCRuntime/RegistrarHelper.cs:line 199
at ObjCRuntime.Class.ResolveToken(Assembly assembly, Module module, UInt32 token) in /Users/builder/azdo/_work/1/s/xamarin-macios/src/ObjCRuntime/Class.cs:line 521
```
The fix is to save the assembly if the managed static registrar added
lookup
tables to the assembly.
Fixes https://github.com/xamarin/xamarin-macios/issues/21606.
Add two more Cecil tests:
* Verify that we don't call the NSObject.Handle setter, we're supposed to call
NSObject.InitializeHandle instead (which throws an exception if the handle
is null),
* Verify that we never call the base class' default constructor (very easy
mistake to make) in manually bound constructors - we're supposed to call the
overload that takes an `NSObjectFlag` parameter instead.
So install that, since it doesn't look like it's installed by default yet.
Also build before running, because the new terminal logger for the build
in .NET 9 ends up printing junk which ends up in the changelog.
Use a file (as opposed to a directory) as the Outputs property in MSBuild targets.
Directories have unintuitive file stamp behavior sometimes, which may confuse incremental builds, so use files instead to drive incremental builds.
* 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.
Rolf Bjarne Kvinge
Peter Collins
Manuel de la Pena
dotnet-maestro[bot]
Alex Soto