AdamE.Firebase.iOS.Core with Win10 VS 2022 Nuget Restore - long paths
Closed this issue · 13 comments
Using Visual Studio 2022 with Windows 10 and using the Nuget package restore system doesn't work.
This means you cannot build the project to debug on a device or emulator. This is caused by devenv.exe not supporting paths longer than 260 characters, even though msbuild.exe, dotnet.exe and nuget.exe all support it. When restoring the core nuget package, it fails to extract this file:
adame.firebase.ios.core\10.21.0\lib\net6.0-ios16.1\Firebase.Core.resources\FirebaseCoreInternal.xcframework\ios-arm64_x86_64-simulator\FirebaseCoreInternal.framework\Modules\FirebaseCoreInternal.swiftmodule\arm64-apple-ios-simulator.private.swiftinterface
This means the remaining of the files including the metadata file from Nuget are not downloaded.
I have moved my Nuget package directory to C:\Nuget, and even with that short path, the total character length is 265, meaning even shrinking to C:\N would still be over the maximum 260 characters supported.
Is it possible to shrink the paths of the contained resources so we can build and debug with this library? I know this is technically not caused by this library, but it does mean that it is not working when you attempt to debug.
Hello @WSSC-AppDev, from what I understand, it is not possible to reduce the path name, but only reducing the namespaces from AdamE.Firebase.iOS.Core (22 chars) to something more shorter, however, I believe that won't happen, since this is an issue with Windows OS, even changing the namespace this issue will eventually happen again.
There are some Windows 10 and 11 hacks to enable long paths, please give it a try 😃 :
Yep, already been down that path. I have long paths enabled in the OS and everything works fine as long as you use msbuild.exe, dotnet.exe or nuget.exe. It's only when VS 2022 uses its internal Nuget system which doesn't use nuget.exe to restore the files that everything breaks.
I had hoped it was possible to shrink the paths of these additional files - building externally on Azure Devops works - its just the local debug system that fails... which then makes it hard to debug before you rollout your release to the AppStore.
@WSSC-AppDev you're right that it should work once long paths have been enabled on the OS and you run your nuget restore from the CLI (important note, clear your nuget cache before re-running the restore on the CLI!).
You should only have to run the nuget restore from the CLI the first time you download these packages to a given cache (or after clearing the cache, obviously).
Is it possible to shrink the paths of the contained resources so we can build and debug with this library?
The only wiggle room we really have is in the package names themselves, which we've inherited from Microsoft. Even if we got each package name down to say 5 characters, xcframeworks are just naturally verbose and if it does help, it might not work for all packages and isn't future-proof.
There might be something creative that could be done in a build target / script so that the nuget files could be shipped with compressed filepaths, but this would need to be a community-led initiative as I can't dedicate any time to it.
Yeah, as I said - not technically caused by this library, but even building the project fails when hitting this point:
Copying file from "C:\Nuget\adame.firebase.ios.core\10.21.0\lib\net6.0-ios16.1\Firebase.Core.resources\FirebaseCoreInternal.xcframework\ios-arm64_x86_64-simulator\FirebaseCoreInternal.framework\Modules\FirebaseCoreInternal.swiftmodule\x86_64-apple-ios-simulator.swiftinterface" to "C:\Projects\ProjectName\MAUI\ProjectName\bin\Debug\net8.0-ios\ios-arm64\Firebase.Core.resources\FirebaseCoreInternal.xcframework\ios-arm64_x86_64-simulator\FirebaseCoreInternal.framework\Modules\FirebaseCoreInternal.swiftmodule\x86_64-apple-ios-simulator.swiftinterface".
So regardless of my shrinking the Nuget folder back to one character, it still wouldn't build.
Love the fact that in a world where we have had long paths for a very long time on every other system Windows is 30 years behind. If only Visual Studio was built being long path aware - especially as you can build projects that are long path aware with a system that is not.
@WSSC-AppDev
Hi.
For Windows environments, it can be installed using .NET CLI.
@AdamEssenmacher says it here too.
The commands are listed on the NuGet page.
For example, AdamE.Firebase.iOS.CloudMessaging.
dotnet add package AdamE.Firebase.iOS.CloudMessaging --version 10.24.0
https://www.nuget.org/packages/AdamE.Firebase.iOS.CloudMessaging
Please run it in the folder where iOS csproj is located.
If MSB4019 occurs, please correct the csproj path.
<Import Project="$(MSBuildExtensionsPath)\Xamarin\iOS\Xamarin.iOS.CSharp.targets" />$(MSBuildExtensionsPath) probably means a path in a Mac environment.
It will work if you specify the relevant file path in the Windows environment.
For example, in my environment it was as follows.
<Import Project="C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Xamarin\iOS\Xamarin.iOS.CSharp.targets" />Additional measures may be required depending on the library being installed.
Please refer to the readme.
I hope everything goes well.
@ta-yamaoka Thanks for your details, but not really the issue here. I have the package installed, I can build the project using the dotnet CLI. What can't be done is debugging of the software through Visual Studio. I am currently getting around it by doing this:
<ItemGroup Condition="'$(Configuration)|$(TargetFramework)'=='Debug|net8.0-ios'">
<PackageReference Include="Xamarin.Firebase.iOS.CloudMessaging" Version="8.10.0.3" />
<PackageReference Include="Xamarin.Firebase.iOS.Analytics" Version="8.10.0.3" />
</ItemGroup>
<ItemGroup Condition="'$(Configuration)|$(TargetFramework)'=='Release|net8.0-ios'">
<PackageReference Include="AdamE.Firebase.iOS.Core" Version="10.24.0" />
<PackageReference Include="AdamE.Firebase.iOS.CloudMessaging" Version="10.24.0" />
<PackageReference Include="AdamE.Firebase.iOS.Analytics" Version="10.24.0" />
<PackageReference Include="AdamE.Firebase.iOS.Crashlytics" Version="10.24.0" />
</ItemGroup>
I also have a bunch of preprocessor flags of '#if RELEASE" around the Crashlytics sections which allows me to build the project, but is really not ideal as I cannot debug Crashlytics.
Currently it works, but I would like to be able to include the proper packages that are being released with my project when I'm debugging.
Thanks!
If anyone has this issue, adding or manually run dotnet restore from your Windows terminal works as well. It only happens to VS for some reason.
Any news with this issue?
The debugging experience is already painful in VS. Having to combine dotnet cmd tooling in combination with VS to debug makes debugging unbearable. The long path issue in VS and the abandonment of the Firebase bindings makes me looking at other frameworks to be honest.
I can see some plans at Shiny to implement Firebase iOS bindings, but I'm not sure how long this can take.
https://shinylib.net/release-notes/client/v40/
Also MS is adding some Firebase bindings to their samples.
https://github.com/Redth/DotNet.Platform.SlimBindings/tree/main/firebase/macios
@kaniosm I share your frustrations and have seriously considered abandoning MAUI / iOS.NET myself for these very same issues (and others...) I haven't got there yet, but I have abandoned Visual Studio+Windows in favor of Rider+Mac. After a short adjustment period, the experience is a marked improvement for .NET mobile development.
For a solution to this long-path issue, the best idea I have right now is to merge the iOS binding approach demonstrated in the repos you've linked with the "full" binding definition files (i.e. ApiDefinition.cs) currently contained in this project. This would practically be a complete rewrite of the current repo though. It'd be a lot.
Given the required effort (and lacking sponsorship) I unfortunately won't be able to dedicate my own effort to such a solution. However, I'd be happy to offer guidance and support to community contributors.
I've been leaving this issue open so that it's easier for others to find, but I don't realistically expect it to be resolved any time soon (or possibly ever).
One other thing... https://github.com/Redth/DotNet.Platform.SlimBindings/tree/main/firebase/macios isn't officially sponsored by Microsoft, and the demo project only includes a tiny fraction of the Firebase API surface (which is kind of their whole point).
The same (or similar) approach from above is being used in the 4.0 Shiny release, but I have concerns that this approach will make Shiny incompatible with AdamE.Firebase.iOS.* packages.
Thanks for you prompt reply Adam!
I fully understand your point. I just hope someone from MS listens to the the community.
Supporting frameworks that have wide adoption while themselves failed to implement, can only benefit them and the people using their products. An open-source framework can only thrive with the proper support from it's sponsors, otherwise it can easily get abandoned.
I'm closing this issue. I've added more context and workaround instructions in the project readme.