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 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.
Created attachment 9581 [details]
[XVS.iOS 3.9] XIB files within iOS Class Libraries cause "Cannot copy ... /builds/$(BuildSessionId)/obj/ ... .nib ... as the source file doesn't exist"
Regression status: regression between XVS 3.8.150 (10cfd17) + XI 184.108.40.206 (840a925) and XVS 3.9.289 + XI 220.127.116.11
## Steps to reproduce
1. Open the attached test case in Visual Studio.
2. Ensure Visual Studio is paired with the build host.
3. Build the "ClassicSingleViewUniversal1" app in the "Release|iPhone" configuration.
(Note: due to bug 26484 it is mandatory to build the solution from within Visual Studio rather than on the command line.)
The build process looks for the compiled `.nib` file from the "ClassicClassLibrary1" project in the incorrect location on the build host. The folder location does not include the project name "ClassicClassLibrary1".
### Error from the "Error List" window
> Cannot copy
> as the source file doesn't exist.
### The build host _does_ have the `.nib` file built at the correct location
> $ ls -l ~/Library/Caches/Xamarin/mtbs/builds/ClassicClassLibrary1/0dd5bd3b0d25b0ee1c1ce674a1862051/obj/Release/ibtool/
> -rw-r--r-- 1 macuser staff 892 Jan 30 15:18 IPhoneViewController1.nib
> -rw-r--r-- 1 macuser staff 353 Jan 30 15:18 IPhoneViewController1.plist
## Expected results
The app should build successfully. Building the app using XVS 3.8.150 or using the MSBuild engine in Xamarin Studio on Mac succeeds, and the compiled `.app` bundle contains the `IPhoneViewController1.nib` file.
## Version info
### Windows 8.1 64-bit, in VMWare Fusion 6.0.5 (2209127)
Microsoft Visual Studio Professional 2013
Version 12.0.30723.00 Update 3
Microsoft .NET Framework
Xamarin 3.9.289.0 (39a70ae)
Xamarin.Android 18.104.22.168 (49a04b966feb40dfdba49d57ba16249b66d606a6)
Xamarin.iOS 22.214.171.124 (3b3ef438017c7ecf486defa9e01567a5f2b3cb2a)
### OS X 10.9.5, MacBook Air
Xamarin.iOS 126.96.36.199 (Business Edition)
Build date: 2015-01-24 09:42:21-0500
Xcode 6.1 (6604), Build 6A1052d
Created attachment 9582 [details]
*** Bug 26579 has been marked as a duplicate of this bug. ***
## Possible workaround: migrate to the Unified API
At least in the attached test case, migrating both the class library and the app project to the Unified API resolves the problem.
*** Bug 26913 has been marked as a duplicate of this bug. ***
This is still not working with Xamarin 3.9.344.0 if the project name is not the same as the assembly name.
I still get the error
Cannot copy /Users/alexandre.pepin/Library/Caches/Xamarin/mtbs/builds/ClassLibrary.Test/9f7acb1f2b7b665d3a68f52aeca5c984/Images/Xamarin.png to /Users/alexandre.pepin/Library/Caches/Xamarin/mtbs/builds/iPadTest/3c0f92fd9150f92de1ff580c067d615b/bin/iPhone/Debug/iPadTest.app/Images/Xamarin.png, as the source file doesn't exist.
See attached sample
My project is named "ClassLibrary" and the assembly is named "ClassLibrary.Test". When it builds, it tries to copy the image from "ClassLibrary.Test" but the folder doesn't exists. The existing folder is named "ClassLibrary"
Created attachment 10146 [details]
@Alexandre, thanks for the heads-up! I've filed a new bug for the issue with the assembly name. I think in this situation a new bug will be helpful because the problem with the assembly name requires a slightly different test case compared to comment 0, and having more than 1 test case on a bug report often leads to confusion.
New follow-up bug filed here:
@QA, if you come back to verify this bug in the future, please use the original "Test case" project attached in comment 0. Thanks!
*** Bug 27166 has been marked as a duplicate of this bug. ***