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.
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.
* 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.
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.
When embedding bundle resources to an assembly as assembly resources, we store
the LogicalName property for the resource. We do this by using the LogicalName
property as the resource name - but we need to encode forward and backward
slashes, since they don't work properly has resource names.
In the past, we've encoded forward and backward slashes differently, but this
results in different encodings depending on whether the resources are embedded
on Windows or macOS.
So change the encoding, so that both forward and backward slashes are encoded
the same way, and then they're extracted using the platform's path character.
This way we get consistent behavior on both platforms.
Now it's possible to reference a compressed xcframework like this:
```xml
<NativeReference Include="path/to/myframework.xcframework.zip" />
```
This makes it easier to work with xcframeworks on Windows, because
xcframeworks can contain symlinks, and by zipping them up the whole symlink
problem is avoided.
Turns out there's already a NuGet that adds a .xcframework.zip file as a
NativeReference (Microsoft.ML.OnnxRuntime), so this makes that NuGet work.
Fixes https://github.com/xamarin/xamarin-macios/issues/21294.
Fixes https://github.com/xamarin/xamarin-macios/issues/21450.
This is a tool used to build legacy projects, so it's no longer needed.
I haven't removed everything that depends on xibuild, in particular some of
the tests need to be ported to .NET instead of just removed.
Add the following:
1. Code needed to register the changes in the compiler pipeline.
2. Code that will add the using statements for the generated code that
match those in the binding file.
3. Code that allows to write tabbed code in a way we do not have to keep
track of indentation.
We have the first unit test that verifies code generation by checking
the using statements.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
This pull request updates the following dependencies
## Coherency Updates
The following updates ensure that dependencies with a *CoherentParentDependency*
attribute were produced in a build used as input to the parent dependency's build.
See [Dependency Description Format](https://github.com/dotnet/arcade/blob/master/Documentation/DependencyDescriptionFormat.md#dependency-description-overview)
- **Coherency Updates**:
- **Microsoft.NET.ILLink.Tasks**: from 9.0.0-rtm.24515.9 to 9.0.0 (parent: Microsoft.NET.Sdk)
- **Microsoft.AspNetCore.App.Ref**: from 9.0.0-rtm.24514.7 to 9.0.0 (parent: Microsoft.NET.Sdk)
- **Microsoft.NETCore.App.Ref**: from 9.0.0-rtm.24515.9 to 9.0.0 (parent: Microsoft.NET.Sdk)
- **Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport**: from 9.0.0-rtm.24513.1 to 9.0.0-rtm.24515.1 (parent: Microsoft.NETCore.App.Ref)
- **Microsoft.NETCore.App.Ref**: from 9.0.0-rtm.24515.9 to 9.0.0 (parent: Microsoft.NET.Sdk)
## From https://github.com/dotnet/sdk
- **Subscription**: afa459aa-bd64-46cb-8138-9f6f795963d4
- **Build**: 20241020.4
- **Date Produced**: October 21, 2024 5:47:08 AM UTC
- **Commit**: 95bea787c14e3402b47311007dba6b3f503b34e7
- **Branch**: refs/heads/release/9.0.1xx
- **Updates**:
- **Microsoft.NET.Sdk**: [from 9.0.100-rtm.24518.42 to 9.0.100-rtm.24520.4][28]
[28]: f5127b18a8...95bea787c1
We must define the default platform version if it's not specified in the TFM, and according to the spec the default should not change for a given .NET version:
* We release support for iOS 18.0 with .NET 9
* Apple releases iOS 18.1, we're still using .NET 9. This default continues to be iOS 18.0
* .NET 10 is shipped, and at this point we bump the default to iOS 19.0
Basically: this should be the last OS version of the platform in question when the current major .NET version is first released to stable.
Ref: 8e6394406d/accepted/2020/net5/net5.md (os-versions)
However, this doesn't work well for Apple platforms: Whenever Apple releases new Xcode versions, our existing workloads might not be compatible with the new Xcode. We'll of course ship updateds workload with support for the new Xcode, but defaulting to an older target platform version would mean that developers wouldn't get the new workload, they'd get the old one. This is exacerbated by the fact that Apple aggressively auto-updates Xcode on developers' machines: they might wake up one day to a broken build - the obvious fix ("dotnet workload update") doesn't fix anything - even if we've shipped updated workloads - because the default is to use the old one. They'd have to manually specify the target platform version in the target platform to get the updated workload ("net8.0-ios17.2" to use the iOS 17.2 workload instead of "net8.0-ios", which would use the default (old/initial/17.0) .NET 8 workload) - and then update _again_ when the next Xcode comes around. At this point the point of having a sane default value is totally out the window, because everybody would have to specify (and continuously update) a platform version in their project files to keep their projects building.
So we've made the decision that the default target platform version is always the latest supported target platform version.
Given the previous example: once we've implemented and released support for iOS 18.1, the updated iOS workload will use 18.1 as the default TPV for iOS.
On the other hand, this turns out to be somewhat of a complication for library developers, because they typically don't need Xcode to build their projects, and if we auto-update their TargetPlatformVersion to the latest, then all their customers have to also update their workloads, which for some people end up being a rather nasty surprise (because with the above algorithm it happens without developer action). Thus we follow .NET's default platform version scheme for library projects: it won't change in minor .NET releases.
Related design/docs PRs:
* https://github.com/dotnet/docs/pull/43089
* https://github.com/dotnet/designs/pull/324
Rolf Bjarne Kvinge
Manuel de la Pena
Alex Soto
dotnet-maestro[bot]