Open Zack-G-I-T opened 10 months ago
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.
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...
Is there any news on this? Any confirmed way of working around yet?
have you even tried the proposed solution ?
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.
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...
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.
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.
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.
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.
It is more a visual studio issue: https://developercommunity.visualstudio.com/t/Allow-building-running-and-debugging-a/351628 Upvote it. Perhaps it helps.
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>
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
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