Closed Kebechet closed 5 days ago
The path: C:\Users\samos\.nuget\packages\kebechet.maui.microsoftclarity.ios\2.0.0\lib\net8.0-ios17.2\Maui.MicrosoftClarity.iOS.resources\Clarity.xcframework\ios-arm64_x86_64-simulator\Clarity.framework\Modules\Clarity.swiftmodule\arm64-apple-ios-simulator.private.swiftinterface
is 268 characters long. But I have also LongPaths enabled on my Win 11 machine
Probably related to: https://github.com/dotnet/maui/issues/17828 https://developercommunity.visualstudio.com/t/Allow-building-running-and-debugging-a/351628
but shortening the path doesnt make a difference
- download Kebechet/BUG-BuildError
I get a 404 - is it private?
In any case this sounds like a MAX_PATH issue, but the fact that it's intermittent is really weird.
Can you try building from the command line and see if that has the same problem? Here's a document explaining how to publish from the command line, you can build as well by just replacing "dotnet publish" with "dotnet build" and adjusting any other command line arguments as needed.
If you're able to reproduce from the command line, please get an MSBuild binlog and attach it here.
I get a 404 - is it private?
Sorry, yes it was, now you should be able to access it.
Can you try building from the command line and see if that has the same problem?
From cli the build seems to work without errors/warnings I have tried:
dotnet build -c Debug -f net8.0-ios
dotnet build -c Debug -f net8.0-android
dotnet build -c Debug -f net8.0-windows10.0.19041.0
I get a 404 - is it private?
Sorry, yes it was, now you should be able to access it.
Can you try building from the command line and see if that has the same problem?
From cli the build seems to work without errors/warnings I have tried:
dotnet build -c Debug -f net8.0-ios dotnet build -c Debug -f net8.0-android dotnet build -c Debug -f net8.0-windows10.0.19041.0
Sorry, I forgot to link to the actual document: https://learn.microsoft.com/en-us/dotnet/maui/ios/deployment/publish-cli?view=net-maui-8.0#publish-an-ios-app-from-windows
The important part is that you need to set a few properties (ServerAddress, ServerUser, ServerAddress) on the command line for the remote build to happen.
Enabling long path support doesn't cut it for VS on Windows. The paths still have to be shortened (~260 chars). The long path support only works on the command line. That's why you're seeing the different results.
Sorry, I forgot to link to the actual document: https://learn.microsoft.com/en-us/dotnet/maui/ios/deployment/publish-cli?view=net-maui-8.0#publish-an-ios-app-from-windows
The important part is that you need to set a few properties (ServerAddress, ServerUser, ServerAddress) on the command line for the remote build to happen.
But specifying server address, user etc is for building on the mac. I had this problem on windows without connected mac. Or whats the purpose of running it on mac from cli ?
But when trying to run cli ios build with address and user specified I get:
C:\Program Files\dotnet\packs\Microsoft.iOS.Sdk.net8.0_17.5\17.5.8020\tools\msbuild\iOS\Xamarin.Shared.targets(1866,3): error : Could not find Microsoft.iOS in /usr/local/share/dotnet/packs/Microsoft.iOS.Sdk.net8.0_17.5/17.5.8020/. [D:\OneDrive\Programming\Csharp\BuildError\BuildError\BuildError.csproj::TargetFramework=net8.0-ios]
C:\Program Files\dotnet\packs\Microsoft.iOS.Sdk.net8.0_17.5\17.5.8020\tools\msbuild\iOS\Xamarin.Shared.targets(1866,3): error : [D:\OneDrive\Programming\Csharp\BuildError\BuildError\BuildError.csproj::TargetFramework=net8.0-ios]
I haven't had time to try this yet, but a potential workaround could be to just remove the files causing problems from the xcframework before it's consumed by the binding project.
So remove this directory:
Clarity.xcframework\ios-arm64_x86_64-simulator\Clarity.framework\Modules\Clarity.swiftmodule
You could probably remove all the *.swiftmodule directories:
Clarity.xcframework*\Clarity.framework\Modules*.swiftmodule
These files are not needed at runtime (in fact only for compiling Xcode/Swift projects, so we don't need them at all).
Can you try that and see if it works for you?
After deletion of those *.swiftmodule
folders the build works correctly. Thank you for your help!
OK, this really sounds like a MAX_PATH issue, since it works from the command line.
It's a known issue that it's not possible to increase/ignore MAX_PATH in VS (https://developercommunity.visualstudio.com/t/allow-building-running-and-debugging-a-net-applica/351628 - please upvote!), so I'm closing this as a duplicate of the VS feedback issue.
Apple platform
iOS
Framework version
net8.0-*
Affected platform version
VS 2022 17.11.1
Description
idk if this is my binding's bug or VS bug
I can normally build MAUI app containing library referencing iOS xcframework binding. This binding contains files also for simulator. First build/rebuild and then starting the app works correctly. But then when I close and start or restart the maui app it fails with errors(I cleared whole nuget cache and those files really exist in that location):
followed by warnings like:
warning MSB3026: Could not copy "C:\Users\samos\.nuget\packages\kebechet.maui.microsoftclarity.ios\2.0.0\lib\net8.0-ios17.2\Maui.MicrosoftClarity.iOS.resources\Clarity.xcframework\ios-arm64_x86_64-simulator\Clarity.framework\Modules\Clarity.swiftmodule\arm64-apple-ios-simulator.abi.json" to "bin\Debug\net8.0-ios\iossimulator-arm64\Maui.MicrosoftClarity.iOS.resources\Clarity.xcframework\ios-arm64_x86_64-simulator\Clarity.framework\Modules\Clarity.swiftmodule\arm64-apple-ios-simulator.abi.json". Beginning retry 1 in 1000ms. Could not find a part of the path 'bin\Debug\net8.0-ios\iossimulator-arm64\Maui.MicrosoftClarity.iOS.resources\Clarity.xcframework\ios-arm64_x86_64-simulator\Clarity.framework\Modules\Clarity.swiftmodule\arm64-apple-ios-simulator.abi.json'.
Steps to Reproduce
1) download https://github.com/Kebechet/BUG-BuildError 2) try to build it and you should get those errors. If you are able to build, then try to start the app(e.g. windows build) and try to restart it.
Did you find any workaround?
I have to always clean and rebuild the whole solution (sometimes works, sometimes it doesnt)
Build logs