* Add support for Mono Components.
* Modify how we look up symbols from native libraries shipped with Mono: we keep
track of which native libraries we linked with, and depending on how we linked
to those assemblies, we look the symbols up at runtime in either the current executable
(if linking statically), or the actual library (where the P/Invoke says they're
supposed to be).
* This means that we have to propagate how libmono is linked from the MSBuild code
to the Application class so that our existing logic is able to correctly determine
which native mono lib to use.
* Modify how we list the P/Invokes we need to preserve by taking into account the
list of native libraries from Mono we have to link with (for .NET). For legacy
Xamarin, I've reverted the logic to how it was before we started adding .NET support.
Fixes https://github.com/xamarin/xamarin-macios/issues/10950.
Fixes https://github.com/xamarin/xamarin-macios/issues/11145.
Fixes https://github.com/xamarin/xamarin-macios/issues/12100.
* Rearrange some MSBuild logic so that the packaging/archiving code for macOS
can also be used for Mac Catalyst.
* Make the .NET build logic package/archive when requested to do so.
* Add tests.
Partial fix for https://github.com/xamarin/xamarin-macios/issues/10413.
* [net6] Adds missing custom linker steps when building from Windows
To share the definition of the custom steps we need to specify the right path to the `dotnet-linker.dll`.
When building from macOS `_XamarinSdkRootDirectoryOnMac` will have the same value as `_XamarinSdkRootDirectory` (which is the local Xamarin SDK dir), but from Windows the former will be the path to the Xamarin SDK on the connected Mac. Essentially this new property is agnostic from the platform from which the build is being executed, and will always return the path to the Xamarin SDK on macOS (either local or remote), so it can be used on scenarios like this one where we know the resource we need should always be referenced from macOS.
* [net6] Updates .NET SDK path for remote tasks execution
This path needs to be updated because VS (from Dev17 Preview 3+) will install through XMA the .NET SDK and the iOS SDK on macOS in a custom dir. This should be the preferred path when building from Windows if it does exist.
* Adds missing spaces to TaskRunner.cs
List all the assemblies in the app bundle and pass them to MonoVM/CoreCLR's in
the TRUSTED_PLATFORM_ASSEMBLIES initialization property.
This way CoreCLR knows where to find System.Private.CoreLib.dll for fat apps
(it's in the runtimeidentifier-specific subdirectory, and by default CoreCLR
will only look next to libcoreclr.dylib).
Fixes https://github.com/xamarin/xamarin-macios/issues/12265.
There's no real change here, the code did exactly this in before, but it was a
side effect of '_SdkIsSimulator' being 'true' for Mac Catalyst, which isn't
obvious. Now the logic is explicit for all platforms.
* CreateIpa: only executed if 'BuildIpa' is set.
* _CreateInstaller: only executed if 'CreatePackage' is set.
* Archive: only executed if 'ArchiveOnBuild' is set.
We don't do this for inner builds of multi-rid builds, only single-rid builds or
outer builds of multi-rid builds.
* Add support for the interpreter everywhere.
* Add support for the AOT compiler everywhere we didn't support it before,
because the interpreter needs it (at least System.Private.CoreLib.dll must
be AOT-compiled when using the interpreter).
* Do FullAOT compilation on Mac Catalyst/ARM64 if we're not using the
interpreter, since we can't use the JIT.
* Fix monotouch-test to be green on Mac Catalyst/ARM64.
Fixes https://github.com/xamarin/xamarin-macios/issues/11724.
Fixes https://github.com/xamarin/xamarin-macios/issues/11421.
* [dotnet] Add support for implicit namespace imports. Fixes#12084.
Also update our templates to remove any using statements for implicitly imported
namespaces.
Fixes https://github.com/xamarin/xamarin-macios/issues/12084.
* [monotouch-test] Fix compilation error due to implicit namespace causing type conflict.
Fixes these errors:
xamarin-macios/tests/monotouch-test/ImageIO/MutableImageMetadataTest.cs(54,54): error CS0104: 'CGImageProperties' is an ambiguous reference between 'CoreGraphics.CGImageProperties' and 'ImageIO.CGImageProperties'
xamarin-macios/tests/monotouch-test/ImageIO/MutableImageMetadataTest.cs(54,88): error CS0104: 'CGImageProperties' is an ambiguous reference between 'CoreGraphics.CGImageProperties' and 'ImageIO.CGImageProperties'
xamarin-macios/tests/monotouch-test/ImageIO/ImageMetadataTest.cs(40,54): error CS0104: 'CGImageProperties' is an ambiguous reference between 'CoreGraphics.CGImageProperties' and 'ImageIO.CGImageProperties'
xamarin-macios/tests/monotouch-test/ImageIO/ImageMetadataTest.cs(40,88): error CS0104: 'CGImageProperties' is an ambiguous reference between 'CoreGraphics.CGImageProperties' and 'ImageIO.CGImageProperties'
* Update dependencies from https://github.com/dotnet/installer build 20210722.2
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.1.21370.12 -> To Version 6.0.100-rc.1.21372.2
* [dotnet] Work around problem where the local .NET install contains an invalid workload.
We work around it by deleting the invalid workload.
* [dotnet] Fix merge failure - don't reference workloads that don't exist anymore.
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Runtime pack entries should be included in all workload manifest files,
even though they will not yet be resolved from the packs folder due to
https://github.com/dotnet/sdk/issues/14044. These changes will also
allow us to start producing .msi files for the runtime packs for an
eventual inclusion in the Visual Studio installer.
This means not listing per-assembly linker flags for only binding projects, but delay
it until we've computed the linker flags for all assemblies (and reflect this in
variable names as well).
This also meant propagating how libmono is linked from the MSBuild code to the Application
class so that our existing logic is able to correctly determine which native mono
lib to use.
This pull request updates the following dependencies
## From https://github.com/dotnet/installer
- **Subscription**: df3e6147-3e41-4928-6775-08d8f479343c
- **Build**: 20210720.12
- **Date Produced**: 7/21/2021 6:57 AM
- **Commit**: d7279fc09fcfb108c5fb97fa290dbbb11c4c441b
- **Branch**: refs/heads/main
- **Updates**:
- **Microsoft.Dotnet.Sdk.Internal**: [from 6.0.100-preview.7.21330.1 to 6.0.100-rc.1.21370.12][1]
- **Microsoft.NET.ILLink.Tasks**: [from 6.0.100-preview.6.21329.2 to 6.0.100-preview.6.21370.1][2]
[1]: 823ff33...d7279fc
[2]: f549b4e...6eae019
## 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 6.0.100-preview.6.21329.2 to 6.0.100-preview.6.21370.1 (parent: Microsoft.Dotnet.Sdk.Internal)
Context: xamarin/yaml-templates#117
Updates the .NET 6 NuGet packaging steps to exclude package metadata,
as the .msi conversion tooling does not process .nupkg file names with
the +sha.commit metadata.
Two new stages have been added to facilitate the Visual Studio setup
authoring process.
The first stage named "Prepare Release" will sign the .NET 6 NuGet
package content (inside and out), convert relevant packages to .msi
installers, generate Visual Studio manifests for the .msi installers,
and push the signed packages to the xamarin-impl feed.
The new SignList.xml file is required for our NuGet signing templates.
The new xamarin-workload.props file contains version information
and other metadata required to generate a Visual Studio manifest.
The second stage starts with a manual validation task. This task
will pause and wait for someone to click a "Resume" or "Reject" button
that will appear on the pipeline UI. This task is configured to be
rejected after waiting for two days, but it can be manually re-ran at a
later date if we want to trigger VS insertion for an older build.
If the manual validation task is approved, a VS Drop will be created
containing all .NET 6 .msi files. This Drop URL can then be used to
update our component versions in Visual Studio. This last piece is
currently manual as we will initially be introducing new components,
however we should be able to automate VS PR creation in the future.
Commit 09f911b missed adding the
PR build check condition to a step in sign-and-notarized.yml, causing
PR builds from forks to fail. We can fix this by adding in the missing
condition.
* Add proper .NET project files for dont link, link sdk and link all. This
includes a Mac Catalyst variant, and adding helpful Makefile targets for
simple execution.
* Adjust various tests to work with Mac Catalyst.
* Add the new Mac Catalyst variants to xharness.
This is a partial fix for #10833.
Context: https://github.com/xamarin/yaml-templates/pull/117
Updates the .NET 6 NuGet packaging steps to exclude package metadata,
as the .msi conversion tooling does not process .nupkg file names with
the `+sha.commit` metadata.
Two new stages have been added to facilitate the Visual Studio setup
authoring process.
The first stage named "Prepare Release" will sign the .NET 6 NuGet
package content (inside and out), convert relevant packages to .msi
installers, generate Visual Studio manifests for the .msi installers,
and push the signed packages to the `xamarin-impl` feed.
The new `SignList.xml` file is required for our NuGet signing templates.
The new `xamarin-workload.props` file contains version information
and other metadata required to generate a Visual Studio manifest.
The second stage starts with a [manual validation task][0]. This task
will pause and wait for someone to click a "Resume" or "Reject" button
that will appear on the pipeline UI. This task is configured to be
rejected after waiting for two days, but it can be manually re-ran at a
later date if we want to trigger VS insertion for an older build.
If the manual validation task is approved, a VS Drop will be created
containing all .NET 6 .msi files. This Drop URL can then be used to
update our component versions in Visual Studio. This last piece is
currently manual as we will initially be introducing new components,
however we should be able to automate VS PR creation in the future.
[0]: https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/utility/manual-validation?view=azure-devops&tabs=yaml
So that the ComputeAOTArguments can compute the llvm-path value to pass to the AOT
compiler (the llvm-path value states where the opt and llc command-line tools are,
and they're next to the AOT compiler).
We need to process the runtimeconfig.json file somehow when using CoreCLR, and
the embedding API we use (coreclr_initialize) won't parse it for us. So re-use
the logic we already have to process runtimeconfig.json for MonoVM (which
involves converting it to a binary format at build time, which we then process
at runtime).
* Move the templates to a common subdirectory.
* Add .NET unit test to verify that all the templates build and that they have
no warnings.
* Modify the template code to:
* Use the UIApplication.Main overload that takes a Type.
* Use top-level statements for the Main method to simplify code.
* Remove a few unnecessary usings.
Partial fix for #12085.
Context: https://github.com/dotnet/maui/pull/1578
In the latest xamarin-macios bump, the dotnent/maui build started
failing because the `$(OutputPath)` of all the projects changed from:
bin/Debug/net6.0-ios/
bin/Debug/net6.0-maccatalyst/
To:
bin/Debug/net6.0-ios/iossimulator-x64/
bin/Debug/net6.0-maccatalyst/maccatalyst-x64/
Class library projects appear to have `$(RuntimeIdentifier)` set by
default. I don't think this is needed, because class libraries do not
need to be compiled as `--self-contained` apps.
On the Android side, we only set a default `$(RuntimeIdentifiers)` for
application projects:
7c5fab1332/src/Xamarin.Android.Build.Tasks/Microsoft.Android.Sdk/targets/Microsoft.Android.Sdk.DefaultProperties.targets (L49-L61)
I think the correct change here is to check:
'$(OutputType)' == 'Exe' Or '$(IsAppExtension)' == 'true'
So Apple platforms only put a default `$(RuntimeIdentifier)` for
applications or extensions.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* Don't copy runtime dylibs to the publish directory if we're linking statically.
* Don't copy static libraries to the publish directory, they're never needed at
runtime.