* Add support for 'dotnet publish'.
* Add support for a 'PkgPackagePath' for macOS and Mac Catalyst, an MSBuild
property to specify the resulting .pkg path, to reflect the existing
'IpaPackagePath' (for iOS and tvOS).
* Fix MSBuild logic that uses 'IpaPackagePath'. Looks like nobody has ever
used this...
* Add tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/11807.
We extract frameworks from third-party libraries when running the linker, and
we need to store this information on disk and the reload it after the linker
has executed, and add it to the existing MSBuild variables that keep track of
the user frameworks and dynamic libraries that have to be copied to the app
bundle.
Fixes the framework-test tests.
when (by default)
* the interpreter is not enabled (since new code might subclass or override the members analyzed at build time)
* building for release
Reverts c56b893b68
Fix https://github.com/xamarin/xamarin-macios/issues/9573
Notes
* Even if possible (in metadata) there is no point in setting `final` on
a method if we remove `virtual`. This match ILLink version of the sealer
and makes the same test pass on both.
* Don't apply optimization on non-AOT builds, e.g. simulators, since some
features (like XML serialization) checks for
`RuntimeFeature.IsDynamicCodeSupported` and that requires some types
to be subclassed thru SRE
* [dotnet] Remove workaround for private symbols for AOT.
* [tools] Make Application.AotArguments a list of string.
This is just a simple refactoring to make Application.AotArguments a list of
strings instead of a comma-separated list of values.
* [tools] Only use direct-icalls when linking mono statically.
Ref: https://github.com/dotnet/runtime/issues/55000
* [mtouch] Fix aot arguments comparison.
* [tests] Adjust mtouch test according to mtouch changes.
* [tests] Add minimum OS version to the Mac Catalyst variation of the MySimpleApp test case.
* 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'
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.
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).
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.
aotdata files go next to the assemblies, not next to the executable. This does
not make a difference for mobile platforms (because it's the same location),
but it matters for Mac Catalyst / macOS, where assemblies are not located next
to the executable.
Context: 36e0432547/src/mono/nuget/Microsoft.NET.Workload.Mono.Toolchain.Manifest/WorkloadManifest.json.in
When using the MacCatalyst workload, you hit the build error:
error NETSDK1147: To build this project, the following workloads must be installed: microsoft-net-runtime-maccatalyst
I found an `extends` was missing in `WorkloadManifest.json`.
I also found the macOS workload needs to extend
`microsoft-net-runtime-mono-tooling`, because of its usage of
`<RuntimeConfigParserTask/>`
Context: https://github.com/xamarin/xamarin-android/pull/6045
We are aiming to simplify the .NET workload ids to short names like:
dotnet workload install maui
dotnet workload install android
dotnet workload install ios
dotnet workload install maccatalyst
dotnet workload install macos
dotnet workload install tvos
Updated the workload ids here, as well as the `.stamp-install-workloads`
make target.
Other changes:
* Updated descriptions to match Android. Still waiting on an *official*
description we should be using for each workload.
* Fixed trailing `,` that showed up as JSON errors in VS Code.
Add support for universal / fat apps for iOS, macOS and Mac Catalyst.
We detect if we need to build a universal app by checking if `RuntimeIdentifiers` (plural) is set, and in that case we do a complete inner build for every `RuntimeIdentifier`, and then once those inner builds are done, we merge the resulting .app bundles together (using a new MSBuild task called `MergeAppBundles`).
When merging app bundles together, we'll run into files that exist in both apps. Depending on the file type, we do different things:
* MachO flies: lipo'ed together.
* Managed assemblies: we do a binary comparison, if the assemblies are different, we put them in a RID-specific subdirectory. At runtime we know to look for assemblies in this directory.
* runtimeconfig.bin, icudt.dat: put in a RID-specific subdirectory.
* Info.plist: computed in the outer (fat) build, the one from the inner build is ignored.
* Other files: for identical files we just copy one, otherwise we show an error.
If we run into files that are different between apps, but we should handle somehow, then we'll have to decide on a case-to-case basis what to do.
Some code shuffling was required to increase code sharing between the tools/ code, the msbuild/ code, and tests.
I've also added support for a default `RuntimeIdentifier`.
Fixes https://github.com/xamarin/xamarin-macios/issues/10294.
Fixes https://github.com/xamarin/xamarin-macios/issues/10861.
Rolf Bjarne Kvinge
Sebastien Pouliot
Emanuel Fernandez Dell'Oca
Peter Collins
Manuel de la Pena
Jonathan Peppers