xamarin-macios/tools/dotnet-linker
Rolf Bjarne Kvinge cb998a3589
[msbuild/dotnet] Don't use the built-in publishing logic in .NET to copy frameworks to the app bundle. Fixes #12369. (#12656)
.NET/MSBuild don't handle symlinks properly [1], which means that we can't ask
.NET to copy frameworks to the app bundle, since frameworks may contain
symlinks.

In our case, the symptom was that instead of copying symlinks, the file the
symlink pointed to was copied instead, and then codesign complained about
invalid bundle format when we tried to sign the framework.

We fix this by having our own target (_CopyFrameworksToBundle) to copy
frameworks to the app bundle (instead of adding all the files in the
frameworks to the ResolvedFileToPublish item group), and then using 'ditto' to
copy the frameworks.

In order to create a test case for this, I also made the macOS and Mac
Catalyst versions of the XTest framework use symlinks:

* Create a proper XTest framework bundle hierarchy for macOS and Mac Catalyst
  by using the typical symlink structure (actual files in the Versions/A
  subdirectory, and then symlinks pointing into that directory).
* Create a separate Info.plist for each platform for XTest.framework, since
  using an otherwise correct framework makes tooling (such as codesign)
  complain if the Info.plist isn't correct too.

This made our existing tests show the bug.

Finally I had to fix signing frameworks where the executable is a symlink.

We were first resolving symlinks for the input - say we had an
Example.framework/Example symlink to Example.framework/Versions/A/Example -
and then checking the parent directory if it's a framework. The parent
directory of 'Example.framework/Versions/A/Example' is 'A', which did not meet
our framewrok condition (if it ends with '.framework').

The fix is to adjust the logic to resolve symlinks after checking if the input
is a framework or not.

[1]: https://github.com/dotnet/msbuild/issues/6821

Fixes https://github.com/xamarin/xamarin-macios/issues/12369.
2021-09-09 09:11:25 +02:00
..
Steps [msbuild/dotnet] Don't use the built-in publishing logic in .NET to copy frameworks to the app bundle. Fixes #12369. (#12656) 2021-09-09 09:11:25 +02:00
.gitignore [build] Use arcade dependency management tooling (#10890) 2021-04-02 00:02:27 -04:00
ApplyPreserveAttributeBase.cs Update to new linker custom steps API (#11374) 2021-05-12 12:26:54 -04:00
BackingFieldDelayHandler.cs [dotnet][linker] Remove unused backing fields (#12001) 2021-07-21 09:03:25 -04:00
Compat.cs [dotnet-tools] Fix Profile.Is[Product|Sdk]Assembly. Fixes #12276. (#12311) 2021-08-02 09:27:30 +02:00
DotNetResolver.cs Fix some whitespace issues in various files. (#12399) 2021-08-11 10:06:46 +02:00
Extensions.cs Fixes for .NET 6 linker (#11739) 2021-06-14 20:10:29 -04:00
LinkerConfiguration.cs [dotnet/msbuild] Fix publishing user frameworks and dynamic libraries from binding projects. (#12396) 2021-08-11 09:58:00 +02:00
Makefile [main] Update dependencies from dotnet/installer (#12357) 2021-08-18 09:36:03 +02:00
README.md Add some documentation. 2020-06-03 09:10:27 +02:00
SetupStep.cs Fixes for .NET 6 linker (#11739) 2021-06-14 20:10:29 -04:00
dotnet-linker.csproj [main] Update dependencies from dotnet/installer (#12357) 2021-08-18 09:36:03 +02:00
dotnet-linker.sln [tools] Add dotnet-linker, a project to contain custom linker steps for our net5.0 build. 2020-06-02 15:55:56 +02:00

README.md

Linker

This directory contains the custom linker steps for the managed linker when building Xamarin.iOS/tvOS/watchOS/macOS apps using .NET 5.

This is work in progress, and is not in a releasable state yet.