Having multiple .frameworks in a nuget package fails to build due to multiple info.plist files

[dotMorten]

Steps to Reproduce

1. Create a nuget package with two or more sets of .framework files in \runtimes\ios-arm64\native\ folder. Each framework will have an Info.plist file associated with it.
2. Reference the nuget package from an net6.0-ios project and compile.
3. Observe the build error.

Expected Behavior

Application deploys and both frameworks gets deployed

Actual Behavior

Build error:

1>C:\Program Files\dotnet\sdk\6.0.100-preview.7.21379.14\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.ConflictResolution.targets(112,5): error NETSDK1152: Found multiple publish output files with the same relative path: C:\Users\mn.nuget\packages\esri.arcgisruntime.runtimes.ios\100.12.0-maui.7\runtimes\ios-arm64\native\ArcGIS-arm64.framework\Info.plist, C:\Users\mn.nuget\packages\esri.arcgisruntime.runtimes.ios\100.12.0-maui.7\runtimes\ios-arm64\native\Runtimecore.framework\Info.plist.

Environment

Microsoft Visual Studio Enterprise 2022 Preview
Version 17.0.0 Preview 3.0
VisualStudio.17.Preview/17.0.0-pre.3.0+31606.5
Microsoft .NET Framework
Version 4.8.04084

Installed Version: Enterprise

Visual C++ 2022   00476-70000-00000-AA536
Microsoft Visual C++ 2022

ASP.NET and Web Tools 2019   17.0.414.6609
ASP.NET and Web Tools 2019

Azure App Service Tools v3.0.0   17.0.414.6609
Azure App Service Tools v3.0.0

C# Tools   4.0.0-3.21403.23+d51d1a7338e32d3a3cd1e5452665964ee8ec15df
C# components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.

Common Azure Tools   1.10
Provides common services for use by Azure Mobile Services and Microsoft Azure Tools.

Extensibility Message Bus   1.2.6 (master@34d6af2)
Provides common messaging-based MEF services for loosely coupled Visual Studio extension components communication and integration.

Microsoft JVM Debugger   1.0
Provides support for connecting the Visual Studio debugger to JDWP compatible Java Virtual Machines

Microsoft MI-Based Debugger   1.0
Provides support for connecting Visual Studio to MI compatible debuggers

Microsoft Visual C++ Wizards   1.0
Microsoft Visual C++ Wizards

Microsoft Visual Studio VC Package   1.0
Microsoft Visual Studio VC Package

Mono Debugging for Visual Studio   17.0.6 (1ebf2f7)
Support for debugging Mono processes with Visual Studio.

NuGet Package Manager   6.0.0
NuGet Package Manager in Visual Studio. For more information about NuGet, visit https://docs.nuget.org/

ProjectServicesPackage Extension   1.0
ProjectServicesPackage Visual Studio Extension Detailed Info

Test Adapter for Boost.Test   1.0
Enables Visual Studio's testing tools with unit tests written for Boost.Test.  The use terms and Third Party Notices are available in the extension installation directory.

Test Adapter for Google Test   1.0
Enables Visual Studio's testing tools with unit tests written for Google Test.  The use terms and Third Party Notices are available in the extension installation directory.

TypeScript Tools   17.0.0730.2001
TypeScript Tools for Microsoft Visual Studio

Visual Basic Tools   4.0.0-3.21403.23+d51d1a7338e32d3a3cd1e5452665964ee8ec15df
Visual Basic components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.

Visual F# Tools   17.0.0-beta.21370.1+9b96c1bde17e9af532ae34eacbfc12d1628183d7
Microsoft Visual F# Tools

Visual Studio Code Debug Adapter Host Package   1.0
Interop layer for hosting Visual Studio Code debug adapters in Visual Studio

Visual Studio IntelliCode   2.2
AI-assisted development for Visual Studio.

Visual Studio Tools for CMake   1.0
Visual Studio Tools for CMake

VisualStudio.DeviceLog   1.0
Information about my package

VisualStudio.Foo   1.0
Information about my package

VisualStudio.Mac   1.0
Mac Extension for Visual Studio

Xamarin   17.0.0.145 (main@bdc8369)
Visual Studio extension to enable development for Xamarin.iOS and Xamarin.Android.

Xamarin Designer   17.0.0.58 (remotes/origin/d17-0@927d548a1)
Visual Studio extension to enable Xamarin Designer tools in Visual Studio.

Xamarin Templates   17.0.3 (a84fb28)
Templates for building iOS, Android, and Windows apps with Xamarin and Xamarin.Forms.

Xamarin.Android SDK   11.4.99.70 (main/7e1558c)
Xamarin.Android Reference Assemblies and MSBuild support.
    Mono: c633fe9
    Java.Interop: xamarin/java.interop/main@4fb7c14
    ProGuard: Guardsquare/proguard/v7.0.1@912d149
    SQLite: xamarin/sqlite/3.36.0@a575761
    Xamarin.Android Tools: xamarin/xamarin-android-tools/main@623332d


Xamarin.iOS and Xamarin.Mac SDK   14.99.0.294 (13b1b3c45)
Xamarin.iOS and Xamarin.Mac Reference Assemblies and MSBuild support.

Build Logs

binlog: msbuild.zip

Example Project (If Possible)

[rolfbjarne]

Looks like this behavior is by design: dotnet/sdk#9643 (comment)

That said, there might be a way around this (in some cases you can zip up the .framework instead and put it in a specific location), I'll have a look to see how that would work with NuGets.

[dotMorten]

I'm not sure how this is by design? I'd say .frameworks are special and needs special handling for the build.
Not being able to put multiple frameworks in one package would be a bit of a showstopper for us

[rolfbjarne]

@dotMorten it's NuGet's design, and not something we can change for Xamarin.iOS.

[rolfbjarne]

That said, I'm going to try to find a solution (that doesn't involve changing NuGet).

[dotMorten]

we could go back to mtouch arguments in a targets file but it's terribly errorprone and OS dependent

[dotMorten]

And why can't we change nuget?

[rolfbjarne]

And why can't we change nuget?

Because it will break existing code that depends on the current behavior.

[dotMorten]

@rolfbjarne There is existing code that relies on multiple /runtimes/ios-XXX/native/*.framework/info.plist files to be overwriting each other? That seems a bit unlikely since iOS /runtimes/* support is just getting introduced with .NET 6. Now I get what you're trying to say, that the runtimes folder in general behaves like that (although there is exceptions to this rule already, like when there are multiple RIDs in a build), but it appears to me that there needs to be exceptions to that rule for things to correctly work. I'm not sure how else we'd be able to deploy frameworks by using the built-in runtime identifier functionality on iOS like we do everywhere else.

[rolfbjarne]

@rolfbjarne There is existing code that relies on multiple /runtimes/ios-XXX/native/*.framework/info.plist files to be overwriting each other?

No, because this is new for Xamarin.iOS.

It's not new for NuGet in general though, and, according to this comment, there are platforms that rely on the fact that all the files in /runtimes/*/native/* (recursively) are copied to the output directory (without preserving the original directory).

In any case I'm just parroting what I read from dotnet/sdk#9643, so if you have any concerns with NuGet, please file an issue in that repo.

[dotMorten]

if you have any concerns with NuGet, please file an issue in that repo.

Honestly this feels a bit like being caught between two chairs: You added support for using the /runtimes/ folder on iOS (which is awesome!), but it is falling short, because of another team's decision on behavior that gets in the way of how native frameworks work on the various platforms. I've spent the time finding, logging and pointing out these shortcomings, communicated it to Microsoft via this issue, but as an external developer, it is really hard for me to be the person responsible for getting various Microsoft teams to work together to solve these problems.

[rolfbjarne]

it is really hard for me to be the person responsible for getting various Microsoft teams to work together to solve these problems.

I've already said we're going to find a solution (#12440 (comment)), so you don't have to do anything else.

[rolfbjarne]

I believe this to be the same as #12572 (which is a more general issue), so I'm closing this one in favor of that one.