Support for "compressed" MacCatalyst .framework references to avoid corruption

[mattleibow]

Details about Problem

1. Create a Mac Catalyst .framework
2. Observe that the framework exists with symbolic links.
3. Add it to a NuGet package
4. The compression of a NuGet uses a compression system that does not preserve symbolic links, causing compiler failures.

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.

If this is going to be fixed with NuGet or the SDK tools. But, this might be a something that needs to be done for other platforms since Windows does not support symlinks.

NuGet product used (NuGet.exe | Visual Studio | MSBuild.exe | dotnet.exe): any

Product version: all

Worked before? If so, with which NuGet version: new things

Repro steps and/or sample project

Verbose Logs

[mattleibow]

Linked here: xamarin/xamarin-macios#11671

[JonDouglas]

Possible dupe of #10734

[spouliot]

This is not limited to [Mac] Catalyst. The same situation exists for regular macOS frameworks. In fact Catalyst inherits the (old) framework format from macOS itself.

This is not (usually [0]) an issue for iOS, tvOS and watchOS since the (newer) "user framework" are using a simpler structure. It makes sense as they are always part of the app bundle, never shared across apps (so versioning concerns does not apply).

[0] The structure with symlinks might be accepted on iOS/tvOS/watchOS but I've never (yet) seen it used inside projects.

[dominoFire]

Does a custom .targets MSBuild could help in creating symlinks for each specific platform?

[aortiz-msft]

Closed as dupe of #10734