Ditto Cannot Get the Real Path for Source
Yesterday I ran into this problem when I was trying to deploy to my iPhone for the first time. Newly registered in the team provisioning profile and eager to deploy, ditto blocked my enthusiasm. Thanks for that, ugh.
ditto: Cannot get the real path for source '/Users/irisclasson/Repos/{somethingsomething}.appex'
3>Xamarin.Shared.targets(2325,3): Error MSB6006 : "ditto" exited with code 1.
You can skip the paragraph below, but we really should get better at understanding our tools, so I encourage you to at least skim through the extra info:
ditto is a command-line utility in macOS that is primarily used for copying files and directories. In the context of Xamarin or iOS development: ditto is used to package app bundles, extensions, frameworks, and other resources into a single coherent bundle for deployment.
But sometimes you get the error I mentioned. I know this seemed to have worked for my colleagues a few years back: https://stackoverflow.com/questions/52212557/xamarin-ios-tool-exited-with-code1-output-ditto-cant-get-real-path-for-sourc/61797686#61797686
Basically, if you have <DeviceSpecificBuild>
tag in your extension csproj and it’s set to true, set it to false.
When set to true, the build output is optimized specifically for different iOS device configurations instead of generating more generic binaries that can run on various iOS devices without optimizations specific to any particular device.
But didn’t work for me. I also cleaned out all the obj and bin folders (classic!), but nope.
Finally, I decided to forego Rider build and use msbuild, passing in the arguments.
Rider | Preferences or Settings | Settings | Build, Execution, Deployment | Toolset and Build
Uncheck Use Rider build Check Pass arguments
According to Rider docs: When you run ReSharper Build for the first time, it builds all projects using multiple parallel processes according to your build configurations. The next time you build the solution, JetBrains Rider only builds projects where supported build items were changed. If the change affects public types used in other projects, the dependent projects are rebuilt as well.
Switching from Rider build to MSBuild got rid of the error, and even though I switched back the error didn’t reoccur. This makes me think it’s either because:
A) Cleaning and rebuilding the project using MSBuild might have removed intermediate build artifacts that were causing the issue. Or:
B) Using a different build system may have invalidated cached data or dependencies, leading to a fresh build that doesn’t encounter the previously cached errors. Or:
C) If Rider builds in parallel, did something get out of order and thus the binaries needed didn’t get built as they were indirect dependencies? And when I switched (and oh dear did the new build take foreeeever) everything got built one thing at the time like a Swedish toilet line (we love waiting in line so much that sometimes we wait in line without knowing for what) and when I switched back to Rider build it worked because the binaries was there (remember it only rebuilds if binaries are missing).
My money is on C. But I guess we’ll have to c. Mum-joke intended. I’m working on embarrassing my children.
Hope this helps!
Comments
Last modified on 2024-10-10