Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for "compressed" .framework references to avoid corruption #11671

Closed
mattleibow opened this issue May 25, 2021 · 7 comments
Closed

Support for "compressed" .framework references to avoid corruption #11671

mattleibow opened this issue May 25, 2021 · 7 comments
Labels
enhancement The issue or pull request is an enhancement Mac Catalyst Issues affecting Mac Catalyst macOS Issues affecting Xamarin.Mac
Milestone

Comments

@mattleibow
Copy link
Contributor

mattleibow commented May 25, 2021

Steps to Reproduce

  1. Create a Mac Catalyst .framework
  2. Observe that the framework exists with symbolic links.
  3. Add it to a NuGet package

Expected Behavior

The framework does not get corrupted.

Another part of the system is that I have to build this framework on macOS, but then I have to build more things on Windows and eventually run a nuget pack on Windows. This means, the framework has to survive uploading and copying on Windows. For example, I noticed that DevOps uploads the framework, but duplicates the files. As a result, this needs to be compressed (by me maybe) on a macOS agent, and then just reference that.

Actual Behavior

The compression of a NuGet uses a compression system that does not preserve symbolic links, causing compiler failures.

Environment

.NET 6

Build Logs

Example Project (If Possible)

@mattleibow mattleibow changed the title Support for "compressed" .framework references Support for "compressed" .framework references to avoid corruption May 25, 2021
@filipnavara
Copy link
Contributor

This is actually NuGet issue so maybe https://github.com/NuGet/Home would be better fit?

@spouliot
Copy link
Contributor

This is actually NuGet issue so maybe https://github.com/NuGet/Home would be better fit?

Agreed. Any workaround will have non negligible impact on build performance.

@mattleibow
Copy link
Contributor Author

Adding a link to that: NuGet/Home#10893

But I don't think this is a nuget issue. Since this is really an issue with the Windows OS not supporting symbolic links properly, the SDK will have to handle this.

@mattleibow
Copy link
Contributor Author

Adding a link to another, more generic issue: NuGet/Home#10734

@spouliot
Copy link
Contributor

Since this is really an issue with the Windows OS not supporting symbolic links properly, the SDK will have to handle this.

Recently there was an XML file added to UNIX-like permission could be kept properly.

@spouliot spouliot added enhancement The issue or pull request is an enhancement Mac Catalyst Issues affecting Mac Catalyst macOS Issues affecting Xamarin.Mac labels May 25, 2021
@spouliot spouliot added this to the Future milestone May 25, 2021
@spouliot
Copy link
Contributor

We need to verify if macOS (and Catalyst) support [0] the newer "user framework" format that is used by iOS, tvOS and watchOS. Those frameworks are not using symlinks (since they do not have to care about versioning).

If this is supported then the frameworks could be converted to this format - and that would solve the issue.

[0] build time, run time and submissions to App Store

@rolfbjarne
Copy link
Member

This has been implemented, we'll automatically zip up any (xc)frameworks with symlinks now.

@ghost ghost locked as resolved and limited conversation to collaborators Nov 9, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement The issue or pull request is an enhancement Mac Catalyst Issues affecting Mac Catalyst macOS Issues affecting Xamarin.Mac
Projects
None yet
Development

No branches or pull requests

4 participants