Split decompressing zip files and figuring out what was inside the zip files
in two different tasks, so that we do the second part even if the first part
isn't done (it could have been done in a previous build).
This is required for rebuilds to work correctly.
This fixes the following problem:
* App with framework is built and signed.
* App is rebuilt, and the framework is copied in again.
* This time, the framework's executable's timestamp will be earlier than the
timestamp when it was last signed, and as such it won't be signed again.
Fix this by touching all the copied files when copying a directory to the app bundle.
Collect all the binding resource packages, add our binding resource packages to the
items that need to be resolved, and remove them from the ResolvedFileToPublish item
group.
Depending on the resolved content (static library, dynamic library, framework) of
a binding resource package, we must do different things , so these items must be
removed from the ResolvedFileToPublish item group.
The _DecompressPlugIns target will process all the items in the _CompressedPlugIns
item group, decompress them and add them to _DirectoriesToPublish. The compressed
file itself is not copied to the app bundle.
We can't keep plugins in the ResolvedFileToPublish item group, because plugins are
usually directories, which may contain symlinks, which the built-in publish logic
doesn't handle correctly.
The _DecompressAppleFrameworks target will process all the items in the _CompressedAppleFrameworks
item group, decompress them and add them to _FrameworkNativeReference. The compressed
file itself is not copied to the app bundle.
This new target will process all the items in the _CompressedAppleBindingResourcePackage
item group, decompress them, and then resolve the extracted results.
This new target will process all the items in the _CompressedPlugIns item group,
decompress them, and add them to _DirectoriesToPublish for later copying into the
app bundle.
This new target will process all the items in the _CompressedAppleFrameworks item
group, decompress them, resolve them if necessary (for .xcframeworks) and add them
to _FrameworkNativeReference.
We're soon going to use this task to copy other types of directories (such as plugins)
as well, and in that case the old target name would be misleading.
Don't add FileNativeReferences to the main libraries to link with, because we
pass that list of main libraries to the LinkNativeCodeTask, and we're already
passing the FileNativeReferences for a different task parameter.
This means that we end up adding the file native reference twice to the linker
arguments, and that's wasteful. It can also cause problems if those linker
arguments aren't always computed in the same way (once as a relative path,
once as an absolute path for instance).
Fixes https://github.com/xamarin/xamarin-macios/issues/13503.
- Fixes https://github.com/xamarin/xamarin-macios/issues/13526
- F#, along with some other cases, have files to publish that have the same filename but different folder
- The most obvious example being resources assemblies: cs/FSharp.Core.resources.dll vs de/FSharp.Core.resources.dll
- I naively copied all files into one directory ignoring path, which does not work here at all
- DestinationSubPath seems to be set unconditionally by ResolvePackageAssets but #msbuild suggested not assuming it was always there (0fc72ddb75/src/Tasks/Common/ItemUtilities.cs (L126-L128))
- So use DestinationSubPath when it is around, else fall back to the old Filename + Extension
- Since there are now subdirectories inside stripped folder, extend MakeDir to cover all file's Directory path
- Tested by hand with FSharpiOSCoolApp (.NET), I can extend an auto test if desired
* Change dotnet-linker to only care about whether we're actually trimming anything or not.
* Allow LinkMde/MtouchLink to not be set if TrimMode is set.
* Detect if any assemblies are linked or not by checking the global TrimMode
property + any TrimMode properties on assemblies.
Fixes https://github.com/xamarin/xamarin-macios/issues/13518.
NullabilityInfoContextSupport - saves a lot by trimming all C# compiler generated nullable information
BuiltInComInteropSupport - no COM support on iOS
named 'Info.plist', and assume that's the app manifest.
That doesn't quite work when we end up with multiple 'Info.plist' entries in any
of those item groups (one example being a framework as a BundleResource - all frameworks
have an Info.plist, and there's no good way to distinguish what the developer's intention
was).
So:
1. Implement a 'AppManifestDetectionEnabled' property to disable automatic app manifest
detection.
2. Add a public 'AppBundleManifest' property that specifies the app manifest
(this is just a renamed version of our previously private '_AppManifest' property).
This makes it possible for app developers to:
* Disable automatic app manifest detection.
* Still have an app manifest by specifying it manually.
* Disable automatic app manifest detection, but also not specify an app manifest
manually (so no custom app manifest at all).
Also:
* Rename '_AppBundleManifest' to '_AppBundleManifestPath' to make it less confusing
with the new 'AppBundleManifest' property.
Pass -dead_strip to the native linker like we do for legacy Xamarin:
* If there are no custom linker arguments.
* If all third-party bindings in the app has SmartLink = true (this doesn't
show up in the PR, but the logic exists for legacy Xamarin and is already
executed for .NET, the resulting Application.DeadStrip value just wasn't
taken into account).
This shrinks the app size a bot for a Hello World app:
* Before: 10.659.731 (https://gist.github.com/rolfbjarne/b5892a5c7fb8663d38e2b69f67bce90c)
* After: 9.940.240 (https://gist.github.com/rolfbjarne/8404394180fb9971bd2f1475b747c70a)
* Difference: -719.491 (-6.7 %)
This way we don't have to update the runtime identifier validation when we add
support for new runtime identifiers.
We'll also have an item group that lists the valid runtime identifiers, which
is making it possible (although the item group is currently private) to query
the valid runtime identifiers (which is something the IDEs have expressed
interest in).
* [dotnet] Show an error if an app developer tries to publish a simulator architecture.
* We can't publish a simulator build, so show an error in that case.
* We can't change the default runtime identifier when publishing (to a
publishable runtime identifier), because by the time we know we're
publishing, it's too late to change the runtime identifier. This means that
it'll be required for app developers to specify a runtime identifier when
publishing to a mobile platform, since the current default runtime
identifier is for a simulator build.
Partial fix for https://github.com/xamarin/xamarin-macios/issues/12997.
* Fix typo and improve naming.
* [dotnet] Don't use '_UsingDefaultRuntimeIdentifier', it's already used elsewhere in .NET
Build the Xamarin.PreBuilt.iOS app bundle instead of using a prebuilt bundle.
This makes sure that we're always using the latest BCL.
Some accurate build massaging was needed, because:
* To build the prebuilt app we need the iOS workload installed (into our build-local
.NET installation).
* The iOS workload contains the Microsoft.iOS.Windows.Sdk pack.
* The Microsoft.iOS.Windows.Sdk pack contains the prebuilt app.
Thus we had a circular reference. Fortunately, the Microsoft.iOS.Windows.Sdk pack
is only required on Windows, which means we can break this circular reference by:
* Mark Microsoft.iOS.Windows.Sdk pack as only to be installed on Windows (unfortunately
it seems we have to list the exact runtime identifiers for the platforms where
to install the pack, so we can't do something like "win-*", but new variations
of the "win-*" runtime identifier shouldn't show up all that often).
* Build the prebuilt app on macOS.
This way we don't need the Microsoft.iOS.Windows.Sdk pack when installing the iOS
workload locally.
The .NET build order is now:
* Build general sdk, runtime and ref packs for .NET.
* Build the prebuilt app.
* Build the Microsoft.iOS.Windows.Sdk pack.
Fixes https://github.com/xamarin/xamarin-macios/issues/12945.
Context: https://github.com/dotnet/maui/pull/3018#pullrequestreview-792369556
In order for the .NET MAUI workload to properly implement implicit
global usings:
1. The .NET MAUI workload will add many `@(Using)` entries that
conflict with each platform's APIs.
2. We need *something* to identify `@(Using)` is for a specific
platform, so we can use a new `%(Platform)` metadata for this.
3. Late in .NET MAUI's MSBuild targets, we can do:
<ItemGroup Condition=" '$(UseMaui)' == 'true' and ('$(ImplicitUsings)' == 'true' or '$(ImplicitUsings)' == 'enable') ">
<Using Remove="@(Using->HasMetadata('Platform'))" />
</ItemGroup>
In .NET 7, we might have a nicer design around this, but for now this
is the plan for .NET 6.
Rolf Bjarne Kvinge
TJ Lambert
Chris Hamons
Marek Safar
Jonathan Peppers