[maccatalyst] NativeReference results in "bundle format is ambiguous (could be app or framework)" #12369
Comments
rolfbjarne
added
bug
|
I have a fairly suspect workaround: I basically avoid the issue of storing Mac Catalyst frameworks in .nupkg files by zipping it up as a native runtime asset: In most TFMs (Android and Windows), this would auto reference and make sure it is compiled in. Due to a bug (#11667) this is not referenced, and in the case of maccatalyst and my .zip, this still would not work. However, if it is in this folder, I can still reference it in MSBuild without having to write logic in may targets files to include it from the package. Then I use this .targets file to extract and reference. But, since this bug exists, I also watch for the collection of these framework and then overwrite the copy that MSBuild made using Unix |
…eworks to the app bundle. Fixes xamarin#12369. .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. [1]: dotnet/msbuild#6821 Fixes xamarin#12369.
…opy 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]: dotnet/msbuild#6821 Fixes #12369.
ghost
locked as resolved and limited conversation to collaborators
Steps to Reproduce
<NativeReference>to a Mac Catalyst dynamic .frameworkbundle format is ambiguous (could be app or framework)I did notice that my framework has symlinks, but once it reaches the .app it has lost the symlinks and has duplicate files.
Expected Behavior
App builds and links.
Actual Behavior
Environment
Build Logs
msbuild.binlog.zip
Example Project (If Possible)
SkiaSharpTestAppMacCat.zip
Extract the project and then unzip
libSkiaSharp.framework.zipmaking sure to preserve symlinks.The text was updated successfully, but these errors were encountered: