Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
So I have two machines I'm trying to create a build of a Xamarin iOS project from on the command line. (Really I have a CI machine where I'm trying to create builds from the command line and a dev machine that is working.) We changed the Xamarin iOS project to use asset catalogs for splash screens and image icons. This works on the dev machine but not the CI machine.
In the "_CopyContentToBundle" build step the ImageAssets aren't getting copied over. The "_CoreCompileImageAssets" task adds the relevant items to the "_BundleResourceWithLogicalName" ItemGroup which is the input to "_CopyContentToBundle". I added some debugging to my "_CoreCompileImageAssets" task to see what it's doing.
Condition="'$(MtouchTargetsEnabled)' And '@(ImageAsset)' != ''"
<Output TaskParameter="PartialAppManifest" ItemName="FileWrites" />
<Output TaskParameter="OutputManifests" ItemName="FileWrites" />
<Output TaskParameter="BundleResources" ItemName="FileWrites" />
<Output TaskParameter="PartialAppManifest" ItemName="_PartialAppManifest" />
<Output TaskParameter="BundleResources" ItemName="_BundleResourceWithLogicalName" />
<Message Text="%(_BundleResourceWithLogicalName.Identity) %(_BundleResourceWithLogicalName.LogicalName)"/>
Here's the output on the machine where the build works:
And here's some output on the machine where the build fails:
../../../../../../var/jenkins/workspace/GMAF for iOS 1.3/GeocortexApp.iOS/obj/iPhone/Ad-Hoc/actool/AppIcons29x29@2x.png ../../../../../../../../../../var/jenkins/workspace/GMAF for iOS 1.3/GeocortexApp.iOS/obj/iPhone/Ad-Hoc/actool/AppIcons29x29@2x.png
../../../../../../var/jenkins/workspace/GMAF for iOS 1.3/GeocortexApp.iOS/obj/iPhone/Ad-Hoc/actool/AppIcons29x29@3x.png ../../../../../../../../../../var/jenkins/workspace/GMAF for iOS 1.3/GeocortexApp.iOS/obj/iPhone/Ad-Hoc/actool/AppIcons29x29@3x.png
../../../../../../var/jenkins/workspace/GMAF for iOS 1.3/GeocortexApp.iOS/obj/iPhone/Ad-Hoc/actool/AppIcons40x40@2x.png ../../../../../../../../../../var/jenkins/workspace/GMAF for iOS 1.3/GeocortexApp.iOS/obj/iPhone/Ad-Hoc/actool/AppIcons40x40@2x.png
There's nothing special about how I invoke the build so I'm not sure why it chooses that roundabout path, but it is valid. What's broken is the "LogicalName" metadata. The "ACTool" task is a black box but there seems to be a bug in how it's constructing the "LogicalName".
The problem is your project is in a mess of symlinked directories with different capitalization.
This has already been fixed.
I'm reopening this issue as Jeffrey Stedfast's comment indicates he doesn't understand the problem.
There are no symbolic links in the solution directory. ```find . -type l -ls``` returns nothing.
you misunderstood what I meant.
Your solution is located in what? /var? That's a symlinked directory.
Yes /var is symlinked, but that's standard on OS X and not a mess.
The problem is already fixed.
*** This bug has been marked as a duplicate of bug 29579 ***