Upgrading from .NET 9.0 to .NET 10.0 leads to linker issues when using xcframeworks with long paths

[ewerspej]

Apple platform

iOS

Framework version

net10.0-*

Affected platform version

VS 2026, .NET SDK 10.0.102, Xcode 26.2 and .NET for iOS (26.2.10191)

Description

Originally posted this issue in TobiasBuchholz/Plugin.Firebase#565

It appears that there is a breaking change between .NET 9.0 and .NET 10.0

After upgrading an existing project from .NET 9.0 to .NET 10.0, I'm getting the following linker errors when I try to use Plugin.Firebase (bundle) or Plugin.Firebase.Crashlytics together with Plugin.Firebase.Analytics with .NET SDK 10.0.102, Xcode 26.2 and .NET for iOS (26.2.10191):

1>C:\Program Files\dotnet\packs\Microsoft.iOS.Sdk.net10.0_26.2\26.2.10191\targets\Xamarin.Shared.Sdk.targets(1864,3): error : clang++ exited with code 1:
1>C:\Program Files\dotnet\packs\Microsoft.iOS.Sdk.net10.0_26.2\26.2.10191\targets\Xamarin.Shared.Sdk.targets(1864,3): error : Undefined symbols for architecture arm64:
1>C:\Program Files\dotnet\packs\Microsoft.iOS.Sdk.net10.0_26.2\26.2.10191\targets\Xamarin.Shared.Sdk.targets(1864,3): error :   "_FIRConsentStatusDenied", referenced from:
1>C:\Program Files\dotnet\packs\Microsoft.iOS.Sdk.net10.0_26.2\26.2.10191\targets\Xamarin.Shared.Sdk.targets(1864,3): error :       <initial-undefines>
1>C:\Program Files\dotnet\packs\Microsoft.iOS.Sdk.net10.0_26.2\26.2.10191\targets\Xamarin.Shared.Sdk.targets(1864,3): error :   "_FIRConsentStatusGranted", referenced from:
1>C:\Program Files\dotnet\packs\Microsoft.iOS.Sdk.net10.0_26.2\26.2.10191\targets\Xamarin.Shared.Sdk.targets(1864,3): error :       <initial-undefines>
1>C:\Program Files\dotnet\packs\Microsoft.iOS.Sdk.net10.0_26.2\26.2.10191\targets\Xamarin.Shared.Sdk.targets(1864,3): error :   "_FIRConsentTypeAdStorage", referenced from:
1>C:\Program Files\dotnet\packs\Microsoft.iOS.Sdk.net10.0_26.2\26.2.10191\targets\Xamarin.Shared.Sdk.targets(1864,3): error :       <initial-undefines>
1>C:\Program Files\dotnet\packs\Microsoft.iOS.Sdk.net10.0_26.2\26.2.10191\targets\Xamarin.Shared.Sdk.targets(1864,3): error :   "_FIRConsentTypeAnalyticsStorage", referenced from:
1>C:\Program Files\dotnet\packs\Microsoft.iOS.Sdk.net10.0_26.2\26.2.10191\targets\Xamarin.Shared.Sdk.targets(1864,3): error :       <initial-undefines>
1>C:\Program Files\dotnet\packs\Microsoft.iOS.Sdk.net10.0_26.2\26.2.10191\targets\Xamarin.Shared.Sdk.targets(1864,3): error :   "_OBJC_CLASS_$_FIRAnalytics", referenced from:
1>C:\Program Files\dotnet\packs\Microsoft.iOS.Sdk.net10.0_26.2\26.2.10191\targets\Xamarin.Shared.Sdk.targets(1864,3): error :        in registrar.o
1>C:\Program Files\dotnet\packs\Microsoft.iOS.Sdk.net10.0_26.2\26.2.10191\targets\Xamarin.Shared.Sdk.targets(1864,3): error : ld: symbol(s) not found for architecture arm64
1>C:\Program Files\dotnet\packs\Microsoft.iOS.Sdk.net10.0_26.2\26.2.10191\targets\Xamarin.Shared.Sdk.targets(1864,3): error : clang++: error: linker command failed with exit code 1 (use -v to see invocation)

These errors do not occur when using any of the other packages separately (with all required transient/base libraries) in different projects, so far I've only encountered this with the above mentioned packages.

I'm using Visual Studio 2026 on Windows 11 paired to a Mac (Apple M2) running macOS Tahoe (26.2) and XCode 26.2.

I've tried including the transient packages directly using the most recent versions and I've also tried excluding the frameworks from being trimmed and played around with different linker settings, but to no avail.

This affects Debug builds for physical iOS devices as well as iOS simulators without any linking or trimming explicitly enabled:

<!-- iOS Debug -->
<PropertyGroup Condition="'$(TargetFramework)' == 'net10.0-ios' and '$(Configuration)' == 'Debug'">
	<ApplicationId>de.my.app</ApplicationId>
	<CodesignKey>MyCodeSignKey</CodesignKey>
	<CodesignProvision>MyProvisioningProfile</CodesignProvision>
	<ProvisioningType>manual</ProvisioningType>
	<MtouchExtraArgs>$(MtouchExtraArgs) --weak-framework=NewsstandKit</MtouchExtraArgs>
	<CodesignEntitlements>Platforms\iOS\Entitlements.Debug.plist</CodesignEntitlements>
	<MtouchNoSymbolStrip>True</MtouchNoSymbolStrip>
	<EnableBitcode>false</EnableBitcode>
</PropertyGroup>

This issue only occurs when trying to deploy on an iOS device or simulator from Windows. I can successfully build and run the project if I build directly on macOS, e.g. using Rider.

Steps to Reproduce

1. Take a MAUI project running on .NET 9.0
2. Configure a Firebase project
3. Add Plugin.Firebase or Plugin.Firebase.Analytics and follow the necessary setup steps
4. Make sure to avoid long path issues on Windows by enabling long paths in the OS. restore and first build via CLI (https://developercommunity.visualstudio.com/t/Allow-building-running-and-debugging-a/351628#T-N10888570)
5. Use Pair-To-Mac to connect to a Mac Build Host
6. Build and deploy to iOS using Visual Studio Build - it will work
7. Now upgrade the MAUI project to .NET 10.0
8. Build via CLI
9. Try to build and run on iOS again using Visual Studio Build
10. The linker issues related to missing symbols of iOS bindings will appear

Did you find any workaround?

Build MAUI iOS app directly on Mac

Build logs

No response

[rolfbjarne]

8. Build via CLI
9. Try to build and run on iOS again using Visual Studio Build

Does the build work via CLI and fail in Visual Studio, or does it fail in both cases?

In any case, could you get an MSBuild binlog for a failing build? Thanks!

[ewerspej]

@rolfbjarne The CLI build works, but the Visual Studio Build fails. However, it's important to note that due to the long path issues on Windows, it's necessary to build with CLI (or ReSharper Build which also works) before switching to Visual Studio Build in order to deploy to the iOS device connected to the Mac Build Host.

I'll come back to you with the binlog later.

[rolfbjarne]

However, it's important to note that due to the long path issues on Windows, it's necessary to build with CLI before switching to Visual Studio

Was this the case with .NET 9 as well, or is this also a regression in .NET 10?

[AdamEssenmacher]

Was this the case with .NET 9 as well, or is this also a regression in .NET 10?

I can add some extra context here.

TL;DR
For the -->CLI thing<-- @ewerspej mentioned, this is not a .NET 10–specific regression. Windows + Visual Studio have long-standing issues restoring/building NuGet packages that contain long file paths. Whether things work often depends on how the initial restore/build happens (CLI vs Visual Studio), not the .NET version. Recent changes in the Firebase iOS binding packages should mitigate this, but the originally reported issue reportedly predates those fixes and affects earlier versions as well.

---

Windows + Visual Studio have never worked well with NuGet packages that contain files with long paths. When such a package is restored inside Visual Studio, VS queitly skips extracting long-path files into the NuGet cache. This leaves the cache in a partially extracted state and can result in build or runtime errors like the ones reported above.

If the initial restore happens via the CLI (outside of Visual Studio), the NuGet cache is populated correctly. If Visual Studio then reuses that cache, things tend to work better—VS can usually build and deploy (at least historically—but it would still fail when archiving or publishing.

The same class of problem exists with XamarinBuildDownload (XBD). If the downloaded .tar.gz contains long paths and Visual Studio is responsible for the first extraction, the XBD cache ends up partially extracted and effectively poisoned. From that point on, builds will continue to fail. As with NuGet restore, running the first build on the CLI allows the tarball to extract correctly (assuming 7zip works), after which Visual Studio can usually build and deploy successfully.

Since the time Microsoft maintained the original iOS binding NuGets, long paths have become much more common. This is largely due to:

• Changes in how modern .NET packs iOS resources into NuGets
• Adoption of the .xcframework bundle format
• Increased use of Swift

In my continuation of Microsoft’s old Google iOS binding packages (used by Plugin.Firebase and other community projects), I’ve made two recent improvements to address this class of issues:

1. Enabled CompressBindingResourcePackage = true, which avoids packing long-path files directly into the NuGet.
2. Removed the use of XamarinBuildDownload for resolving external resources at build time, instead packing those resources directly into the NuGets.

With these two changes in place, I suspect that @ewerspej’s statement about needing to build on the CLI first may no longer be true—though I haven’t been able to validate this personally, as I no longer work on Windows.

Plugin.Firebase v4.0 updates the minimum required iOS binding packages to versions that include both of these fixes. However, as noted in @ewerspej’s original issue, the same problem also affects v3.1.2, which predates those changes.

[ewerspej]

@AdamEssenmacher Thank you for providing more context. Essentially, none of this would be an issue, if Visual Studio could finally fully support long paths in the year 2026. That's unfortunately still not the case and won't be anytime soon as far as I understood from personal conversations with members of the MAUI team.

Since this worked with .NET 9.0 with versions 3.1.2 and 4.0.0 of the Plugin.Firebase.* packages (as well as with the full Plugin.Firebase bundle) but not with .NET 10.0, something must have changed that leads to the above problem(s).

@rolfbjarne Today, I'll try to get the binlog for you.

P.S.: I just added another frustrated comment to the VS MAX_PATH discussion. Maybe this can get more attention again, so that Microsoft finally does something about it.

[ewerspej]

@rolfbjarne Here are the binlogs you asked for. If you need anything else, let me know. FirebaseAnalyticsCrashlytics_Win11_VS2026_PairToMac_XCode26.2_NET10_binlog.zip

[rolfbjarne]

This is really weird, I can see where the build goes wrong, but I don't understand why.

The problem shows up in the ResolveNativeReferences task, which is supposed to find native frameworks (such as FirebaseCrashlytics.framework) for a given assembly (Firebase.Crashlytics.dll in this case) - but that doesn't happen for some reason (the task can find all other frameworks for all other assemblies just fine, and no output explaining why Firebase.Crashlytics.dll is the odd one out).

By any chance, can you confirm that in this directory:

Q:\nuget\adame.firebase.ios.crashlytics\12.5.0.4\lib\net10.0-ios26.0\

you have exactly two files, of approximate this size:

1. Firebase.Crashlytics.dll: 21 kb
2. Firebase.Crashlytics.resources.zip: 1.183 kb

[dotnet-policy-service]

Hi @@ewerspej. We have added the "need-info" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.