Maui - some nugets do not work as path is too long "Could not find a part of the path"

[Zack-G-I-T]

Description

Using the Xamarin.Firebase.iOS.CloudMessaging nuget in .NET Maui.
Android works fine, but in iOS we get this error. I believe it is because the file path is too long - however I have set the system settings to enable long paths and still get this exception. I am using Windows 10 if that is relevant.

**An error occurred while trying to deploy the app 'SamplePush.app'. Details: Could not find a part of the path

'C:\Users\username\AppData\Local\MyTempFiles\Xamarin\HotRestart\Signing\SamplePush.app\out\Payload\SamplePush.app\SamplePush.content\Firebase.CloudMessaging.resources\FirebaseMessaging.xcframework\ios-arm64\FirebaseMessaging.framework\Headers\FirebaseMessaging-umbrella.h'.**

I changed my temp file location to be shorter C:\tmp but still get the following:

**An error occurred while trying to deploy the app 'SamplePush.app'. Details: Could not find a part of the path

'C:\Tmp\Xamarin\HotRestart\Signing\SamplePush.app\out\Payload\SamplePush.app\SamplePush.content\Firebase.Core.resources\GoogleUtilitiesComponents.xcframework\ios-arm64_x86_64-simulator\GoogleUtilitiesComponents.framework\Headers\GoogleUtilitiesComponents-umbrella.h'**

Steps to Reproduce

1. Download Xamarin.Firebase.iOS.CloudMessaging nuget in a new maui app.
2. Try and debug in ios and see exception.

Link to public reproduction project repository

No response

Version with bug

7.0.92

Is this a regression from previous behavior?

Yes, this used to work in Xamarin.Forms

Last version that worked well

Unknown/Other

Affected platforms

iOS

Affected platform versions

No response

Did you find any workaround?

No response

Relevant log output

An error occurred while trying to deploy the app 'SamplePush.app'. Details: Could not find a part of the path

'C:\Users\username\AppData\Local\MyTempFiles\Xamarin\HotRestart\Signing\SamplePush.app\out\Payload\SamplePush.app\SamplePush.content\Firebase.CloudMessaging.resources\FirebaseMessaging.xcframework\ios-arm64\FirebaseMessaging.framework\Headers\FirebaseMessaging-umbrella.h'.

[jonathanpeppers]

Does enabling long paths help here at all?

https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry#enable-long-paths-in-windows-10-version-1607-and-later

/cc @emaf @mauroa

[mauroa]

Created AzDO bug since it belongs to the Platform Tools team: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1899665

[radderz]

Note, long file paths doesn't work in windows 11 at all, both the registry setting and group policy option doesn't work with long paths anymore so this long paths issue is a pretty major regression. Not being able to use Firebase for instance for push notifications is crippling our ability to test our apps.

[jonathanpeppers]

Note, long file paths doesn't work in windows 11 at all, both the registry setting and group policy option doesn't work with long paths anymore

We should file a bug with Windows, if that is the case, this is unrelated to MAUI.

As to the error above:

Could not find a part of the path

'C:\Users\username\AppData\Local\MyTempFiles\Xamarin\HotRestart\Signing\SamplePush.app\out\Payload\SamplePush.app\SamplePush.content\Firebase.CloudMessaging.resources\FirebaseMessaging.xcframework\ios-arm64\FirebaseMessaging.framework\Headers\FirebaseMessaging-umbrella.h'.

Do you know what changed? When it worked, was the path just shorter?

[radderz]

I imagine the path was shorter, any filename over 260 will fail in windows 11, when it was possible to get it working in window 10. I am not sure when this started failing but it's pretty painful after updating our devs all with new laptops running windows 11.

I put the note in here incase that was the issue and it looks like this filename is 271 in length so the long file names setting would need to be enabled to work for this to function. The issue comes from the nuget package download/unzip, which fails due to the long file names. Then the copying to the obj folder can have the same effect if that path ends up too long too.

I am unsure if @Zack-G-I-T is using windows 11 but if he is then I'd say that is the problem he is experiencing.

Edit: @Zack-G-I-T is using Windows 10. You should look up enabling long filenames in registry to allow file paths > 260 in length. After doing that you need to delete the package from your nuget cache as it is already there in a bad state and visual studio will not restore it for you.

[Zack-G-I-T]

@radderz Hi, I am on Windows 10 and I tried enabling long file names in regedit and in group policy and i deleted my whole nuget cache but it didnt work.
I ended up having to delete the "_CopyLocalBindingResources" tag from my Xamarin.Shared.Sdk.targets" for it to work.

[mauroa]

@radderz @Zack-G-I-T how are you installing the FireBase NuGet package? If it's by adding a PackageReference or using the Package Manager Console, I guess you are getting an error on installation or restore time, aren't you? I'm just trying to understand if that's the first error you are facing or if it's directly when building the MAUI app for iOS. That would help us to determine the best route for the issue. Thanks

[radderz]

@mauroa it is when trying to build, it tries to copy the contents of the nuget to the obj folder for build, but the file doesn't exist as at nuget restore time since the initial zip extraction fails. It basically gives a cannot copy file error and the overall path is way too long.

I tried to change the nuget cache folder to have as short a path as possible but it still fails since it copies it to the obj folder of the project which has a longer path.

[mauroa]

@radderz thanks. That's correct, but it also fails when you install the package or restore it without building. The package installation in the cache folder is what it initially fails. The installation gets incomplete because of the path length issue. When I try to install the package, it shows this error:

Install-Package : Could not find a part of the path C:\Users\myuser\nuget\packages\xamarin.firebase.ios.installations\8.10.0.3\lib\xamarinios10\Firebase.Installations.resources\FirebaseInstallations.xcframework\ios-arm64_x86_64-simu lator\FirebaseInstallations.framework\Headers\FIRInstallationsAuthTokenResult.h.

In fact, If I go to that path and try to manually create that missing file, Windows truncates the file name because of the path policy.

I think this issue is indeed out of the scope of MAUI or tooling, as @jonathanpeppers suggested in a comment above.

[radderz]

Yea it isn't a Maui problem, I'd say however that this is a very commonly used package within MAUI so it is going to be a big pain for a lot of devs using MAUI.

[radderz]

@mauroa, Actually, I just tested using CMD prompt, long file paths is working fine with the registry setting. So the issue is actually with the application trying to access the long paths i.e. nuget and VS.

I.e. try this.

1. enable long file paths
2. go to a folder in terminal.
3. mkdir fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
4. cd fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
5. repeat till the folder path is very long

You can create a path that exceeds the size limit of windows 260 chars. explorer doesn't support long file paths but the windows file system is working.

So I do think this is a tooling issue in nuget/VS build.

[mauroa]

Correct, cmd allows it. However, if you try to create a folder or a file in Windows with the UI (right click > New > Folder or right click > New > Text Document) in an already very long and exceeded path (created with cmd), you will see that Windows doesn't allow you to do that. So, we agree that the Windows file system allows it, the Windows explorer doesn't as well as VS/NuGet.

[radderz]

Correct, cmd allows it. However, if you try to create a folder or a file in Windows with the UI (right click > New > Folder or right click > New > Text Document) in an already very long and exceeded path (created with cmd), you will see that Windows doesn't allow you to do that. So, we agree that the Windows file system allows it, the Windows explorer doesn't as well as VS/NuGet.

Yes but that's a choice Microsoft made for "compatibility". Windows explorer isn't used as part of nuget restore and build so that's not really relevent. Nuget, unzip/zip and VS should be able to use the longer file paths.

[mauroa]

Yes, I agree with you. What affects us is anything that touches the VS scope, however I was trying to picture the areas affected by this long path issue, independently of VS, just for context purposes.

[harima34]

Did you find any workaround ? I got the same problem after update my visual studio and .net8

[radderz]

Did you find any workaround ? I got the same problem after update my visual studio and .net8

No there was no workaround, still can't build ios on .net 8 if using firebase push.

[robertev-alchemy]

1. gpedit.msc, Local Computer Policy -> Computer Configuration -> Administrative Templates -> System -> Filesystem, then enable the Enable Win32 long paths option
2. Change msbuild.exe.config :

3. REBOOT

That actually worked to get around the long path build issues for me, temporarily at least, a couple weeks ago.

Now evidently there has been some update ... and that work-around no longer works, long path issue has returned.

Urghh.

Does anybody have Push Notifications working in MAUI - and an example that compiles, and please list the VS version, nugets, OS version, Firebase plugin version, etc. What is the magic working combination and any OS and msbuild settings?

And why in the world would msbuild default to short paths anyways, especially since max_path limit was removed back in RS1.

[ghost]

We've added this issue to our backlog, and we will work to address it as time and resources allow. If you have any additional information or questions about this issue, please leave a comment. For additional info about issue management, please read our Triage Process.

[radderz]

This doesn't work for the firebase package as the filenames are far too long, so just shortening the package cache isn't enough. Get Outlook for Android<https://aka.ms/AAb9ysg>

…

________________________________ From: SEONG-AHN LEE ***@***.***> Sent: Friday, December 8, 2023 9:47:27 PM To: dotnet/maui ***@***.***> Cc: Mark Radcliffe ***@***.***>; Mention ***@***.***> Subject: Re: [dotnet/maui] Maui - some nugets do not work as path is too long "Could not find a part of the path" (Issue #17828) C: Create a folder "X" on drive root, copy all the files and folders underneath the solution folder, and build and deploy it. — Reply to this email directly, view it on GitHub<#17828 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAJD3T6SHUYVHGUKZ3WFDV3YILHZ7AVCNFSM6AAAAAA5SWEMSGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBWG44DENBWHE>. You are receiving this because you were mentioned.Message ID: ***@***.***> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. CAUTION: This correspondence is confidential and intended for the named recipient(s) only. If you are not the named recipient and receive this correspondence in error, you must not copy, distribute or take any action in reliance on it and you should delete it from your system and notify the sender immediately. Unless otherwise stated, any views or opinions expressed are solely those of the author and do not represent those of Blackhawk Tracking Systems Limited.

[IeuanWalker]

xamarin/GoogleApisForiOSComponents#639

[IeuanWalker]

Has anyone got any workaround?

Atm seems impossible to build push notification using FCM

[archergod]

I think best bet is not Visual Studio but to use VSCode .. I read in other places that VS Code or commandline for that matter works for them fine. I have move on to different project so cannot test my problem code until later. But I am counting on command line tools only.

[zLordZachy]

This is terrible, I'm getting tired of it ... enable long paths, will eventually solve problem . But for that you need to delete the bin obj or even put them in the root directory.

[ia3n]

This really is beyond a joke at this point - the last functional Firebase package for iOS was released on 7 Nov 2020. Yes, that's right, it's been almost FOUR YEARS since we had a package available that we could actually, you know... compile.

Up until now we could use the old 2020 releases to get by on Mono, but there has never been a working option for .Net and with Mono depreciated this just went from unfortunate to a real dealbreaker.

The big issue for me is that it breaks Xamarin.Google.iOS.MobileAds meaning that there is no way to currently monetize iOS projects. Working AdMob nugets should be at the top of Microsoft's list if they ever hope for MAUI to be a contender in the cross-platform space.

You know who DOES have working AdMob libraries? Flutter. I don't really want to go through the painful process of learning dart and refactoring all my apps, but at this point I'm not sure which is more painful, 3 months of reworking everything or another four years waiting for Microsoft to raise the character limit enough for us to run their own packages.

[AlleSchonWeg]

I think flutter has first class support for google/firebase apis.
Because flutter and android are google tools.

[WeirdAnakin]

Is there any news on this? Any confirmed way of working around yet?

[KnollK]

Here is the workaround I was able to use to install a few of these longer name NuGet packages and get an iOS build running on a simulator, which still crashes immediately for me but that is my Maui Migraine to deal with. Hopefully this helps someone.

1. Add a Nuget.config file to the root directory of your solution with the following (change the "C:\Nuget" to whatever you want as long as it is short):

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <config>
        <clear />
        <add key="globalPackagesFolder" value="C:\Nuget" />
    </config>
</configuration>

2. In Visual Studio 2022 change the workspace path for your project:
   File > Source Control > Advanced > Workspaces > Edit > Enter a New Working Folder click the ellipses (should be an option under "Source Control Folder" header) > Select the folder of your solution > Click the local folder and change it to an incredibly short path on your machine.

[radderz]

This only helps if the package files have short enough folder locations that this brings it under the threshold, but this isn't enough for some packages that even C:\N\ as the nuget folder which is the shortest possible still breaches the threshold.

[improwise]

Can't help but to wonder if it would not be easier for everyone if Microsoft just killed of MAUI since they obviously don't care anymore...this problem has been around for years and yet...

[khalil2099]

Is there any news on this? Any confirmed way of working around yet?

have you even tried the proposed solution ?

[khalil2099]

Can't help but to wonder if it would not be easier for everyone if Microsoft just killed of MAUI since they obviously don't care anymore...this problem has been around for years and yet...

because there are work around for this problem already.

[improwise]

Can't help but to wonder if it would not be easier for everyone if Microsoft just killed of MAUI since they obviously don't care anymore...this problem has been around for years and yet...

because there are work around for this problem already.

Please tell me one that works as I have tried all that I have found and none is working and I am obviously not the only one with problems...

[khalil2099]

Can't help but to wonder if it would not be easier for everyone if Microsoft just killed of MAUI since they obviously don't care anymore...this problem has been around for years and yet...

because there are work around for this problem already.

Please tell me one that works as I have tried all that I have found and none is working and I am obviously not the only one with problems...

Yes im also having this problem before this, but i managed to solved it. I even complain about it on this thread on Feb 2024.

Have you tried this ? But before you try this, u need to enable Long Path Names and also delete your Bin and Obj folder inside your project folder. I have tried this with two different machine and no problems.

Post your error output here.

[improwise]

Can't help but to wonder if it would not be easier for everyone if Microsoft just killed of MAUI since they obviously don't care anymore...this problem has been around for years and yet...

because there are work around for this problem already.

Please tell me one that works as I have tried all that I have found and none is working and I am obviously not the only one with problems...

Yes im also having this problem before this, but i managed to solved it. I even complain about it on this thread on Feb 2024.

Have you tried this ? But before you try this, u need to enable Long Path Names and also delete your Bin and Obj folder inside your project folder. I have tried this with two different machine and no problems.

Post your error output here.

Thanks, will give that a try as well. But when not even latest VS can do MAUI in 2024, I just can't help but to think that we need to consider our options here. But that is of course another discussion not related to this issue.

[improwise]

We were actually able to find a solution (ie workaround) that actually seem to work in VS as well. It is not pretty but here goes

<PropertyGroup>
	<BaseOutputPath>..\..\..\..\..\temp\</BaseOutputPath>
</PropertyGroup>

We tried with different variants of something like "C:\temp" instead but never got it to work with our other build scripts. There are of course nicer ways to solve this still using relative paths but right now we were just looking for a quick and dirty way of making it work...

Of course you may need to adjust the number of ".." based on your folder structure etc. The idea here is to get a relative path (to make MSBuild happy) but still get a path short enough to make Windows / VS happy as well.

[ia3n]

Coming back a month later to confirm that YES many of these workarounds will solve the issue - keep trying! For us it was the earlier suggestion to open windows powershell and enter:
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" `
-Name "LongPathsEnabled" -Value 1 -PropertyType DWORD -Force

Also a reminder that this was an issue in Xamarin.iOS long before it was a MAUI issue. MAUI has introduced a number of new headaches for us, sure, but this is an old one. The bigger problem here is that in Xamarin.iOS the simple workaround was to use older packages and .net requires the recent ones so it's been harder to fix.

After my initial frustrated rant (which I stand by) I do want to note that we've been pleasantly surprised to find that once you get it up and running, MAUI works... really well. We've successfully rolled out several updates on Android and iOS over the past month, have integrated all firebase nugets successfully (including FCM) since the .net team updated them recently and are considering releasing to the Windows store for the first time ever. Billing is simple with James Montemagno's excellent cross-platform nuget, and Admob is now working on all apps. We're also seeing fewer ANRs than when our apps were written in Xamarin, and maintenance is so much easier than running two native builds. Expect to do some workaround-hunting and a lot of 'Clean Solution + delete Obj & Bin folders, but if you're deep in the .net and just looking to transfer your code across from Xamarin, I would say it's worth it and don't give up.

[AlleSchonWeg]

It is more a visual studio issue: https://developercommunity.visualstudio.com/t/Allow-building-running-and-debugging-a/351628
Upvote it. Perhaps it helps.

[improwise]

Can't help but to wonder if it would not be easier for everyone if Microsoft just killed of MAUI since they obviously don't care anymore...this problem has been around for years and yet...

because there are work around for this problem already.

Please tell me one that works as I have tried all that I have found and none is working and I am obviously not the only one with problems...

Yes im also having this problem before this, but i managed to solved it. I even complain about it on this thread on Feb 2024.

Have you tried this ? But before you try this, u need to enable Long Path Names and also delete your Bin and Obj folder inside your project folder. I have tried this with two different machine and no problems.

Post your error output here.

This only seem to work for a while but not once you need to build etc again, at least not for us. The solution (workaround) I posted above works over time though once you have put it into the project file (at least it does for us, YMMV of course). Best would be if MS just fixed this in VS.

<PropertyGroup>
	<BaseOutputPath>..\..\..\..\..\temp\</BaseOutputPath>
</PropertyGroup>

Edit:

Wierdly enough, now it seems to work with absolute paths as well, something that did not work before, like

<PropertyGroup>
	<BaseOutputPath>M:\temp\</BaseOutputPath>
</PropertyGroup>

[NeilPSingular]

This worked for me:

nuget install <Package-Name> in the cmd of the project directory

[jfversluis]

As pointed out a couple of times, unfortunately this is not a .NET MAUI problem but wider spread and older.

I think there is a couple of variations of this either in Windows or Visual Studio, this seems to be a VS Feedback ticket with a good number of comments and votes so please upvote that one and/or add your scenario there and hopefully it will be fixed soon!

Since this is not actionable on our side and this has now accumulated a good number of workarounds to help people move forward, closing this for now here.