Some platforms don't support hostfxr but we can use the coreclr/monosgen library directly to initialize the runtime.
Android exports now use the `android` runtime identifier instead of `linux-bionic`, this removes the restrictions we previously had:
- Adds support for all Android architectures (arm32, arm64, x32, and x64), previously only the 64-bit architectures were supported.
- Loads `System.Security.Cryptography.Native.Android` (the .NET library that binds to the Android OS crypto functions).
We don't seem to expose any API that uses `char16_t` yet, but I added it anyway since we make the type info for it.
I didn't add anything for `wchar_t` because we are not making a type info so maybe we don't have a need for it yet, it could be added in the future.
To prevent breaking compatibility with the C# bindings, we ignore the `char32_t` metadata and still use `System.Int64`.
- Use the export platform's `get_os_name` to determine the platform name instead of guessing from the features.
- Use the export platform's `add_message` to add error messages instead of a custom error dialog. Integrates .NET error messages with the export log dialog.
* Replaces `find(...) != -1` with `contains` for `String`
* Replaces `find(...) == -1` with `!contains` for `String`
* Replaces `find(...) != -1` with `has` for containers
* Replaces `find(...) == -1` with `!has` for containers
Random-access access to `List` when iterating is `O(n^2)` (`O(n)` when
accessing a single element)
* Removed subscript operator, in favor of a more explicit `get`
* Added conversion from `Iterator` to `ConstIterator`
* Remade existing operations into other solutions when applicable
Instead of making the accessors `internal` which can break binary compat, make them `public` but hide them with EB never so they don't show up in IntelliSense.
Also, do the same for properties with the `PROPERTY_USAGE_INTERNAL` flag. These properties were not meant to be exposed to scripting, but since they've been public before all we can do now is hide them.
The Godot.NET.Sdk (for C# use) should define the property `UsingGodotNETSdk` in its [SDK.props](a07dd0d6a5/modules/mono/editor/Godot.NET.Sdk/Godot.NET.Sdk/Sdk/Sdk.props).
## Why
Defining this property allows shared build configuration (e.g. Directory.Build.targets or other imported msbuild files) to detect deterministically when they are operating within the scope of a project controlled by Godot.NET.Sdk. This enables shared build configuration that may span many different projects within a folder to have Godot.NET.Sdk-specific configuration that only applies to Godot projects.
## Why named UsingGodotNETSdk
This naming scheme is common practice in Microsoft Dotnet SDKs. For example, the property `UsingMicrosoftNETSdk` is defined by the default SDK, `UsingMicrosoftTraversalSdk` is defined by [Microsoft.Build.Traversal](363532de5b/src/Traversal/Sdk/Sdk.props (L10)), `UsingMicrosoftNoTargetsSdk` by [Microsoft.Build.NoTargets](363532de5b/src/NoTargets/Sdk/Sdk.props (L10)), and so on. The property `UsingMicrosoftNETSdk` is even used in the implementation of Godot.NET.Sdk for conditional logic of the type predicted here.
Note that these "Using*" properties are _additive_ in the sense that more than one can be defined for a given project (as SDKs can effectively be built upon other SDKs, using them as components). So, it is normal and appropriate for both `UsingMicrosoftNETSdk` and `UsingGodotNETSdk` to be simultaneously defined within the same project.
Raul Santos
Rémi Verschelde
kit
Thaddeus Crews
RedOrbweaver
Alula
bruvzg
Daylily-Zeleen
Jonatan Röjder Delnavaz
Juan Pablo Arce
Marius Hanl
Gaoyao Massimo Hu
A Thousand Ships
Paul Joannon
K. S. Ernest (iFire) Lee
Konstantin Kretov
Nông Văn Tình
AyOhEe
Jason Hunter