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.
When trying to compile a Xamarin.iOS app from the command line, if the solution has a Class library (.dll) project as a dependency of the main (.exe) project, the .dll project creates an exclusion connection to mtbs, making the .exe mtbs connection fail, therefore failing the build.
As a workaround, modify this file :
C:\Program Files (x86)\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.After.targets
Add a condition to the SayHelloTask invocation:
Condition="'$(OutputType)' == 'Exe'"
Then immediately after, add the following node:
Condition="'$(OutputType)' != 'Exe'"
This will ensure that the SayHelloTask is only invoked when building the .exe project.
Thanks for the report. At first glance this appears to be the same symptom described in Bug 26484. The QA testing on that bug suggested that it was fixed in the Cycle 5 "XamarinVS 3.11" release.
I see that this bug (Bug 32697) does not currently include version information. If you are using XamarinVS 3.11.x, there are 3 possibilities:
(a) There has been a regression in Bug 26484 between the version tested in Bug 26484, Comment 8 and the version you are using.
(b) Bug 26484, Comment 8 did not accurately verify the test case from Bug 26484, Comment 0, so the bug was never properly fixed.
(c) Your particular solution (or computer environment) is hitting a scenario that is different from the test case (and environment) in Bug 26484, Comment 0.
I have just re-verified (a) and (b) on XamarinVS 3.11.836 + Xamarin.iOS 18.104.22.168, so we are left with possibility (c).
## Next steps if you still see the problem with XamarinVS 3.11.x
1. Please attach back your complete version information from both the Windows PC and the Mac build host.
### Windows, Visual Studio
"Help -> About Microsoft Visual Studio -> Copy Info [button]"
### Mac build host
"Xamarin Studio -> About Xamarin Studio -> Show Details -> Copy Information [button]"
2. Please attach back a minimal test case that reproduces the problem (optionally marked private), along with a short list of steps to reproduce the problem.
3. Please attach back the diagnostic MSBuild output  from the failed build attempt.
 Add the `/v:Diagnostic` flag to the `msbuild` command, and redirect standard output into a file. Example:
> C:\source\UnifiedSingleViewIphone1>msbuild UnifiedSingleViewIphone1.sln /t:Build /p:Configuration=Release;Platform=iPhone /v:Diagnostic > DiagnosticMSBuildOutput.txt
Thanks in advance.
## Side note: disabling the SayHelloTask probably will not be a sufficient workaround in every case
If I recall correctly, iOS library projects will sometimes require a connection to the Mac build host (for example, to build storyboards and XIBs).
Similarly, if the solution contains 2 iOS app projects, then (at least with the old behavior of Bug 26484) one of them will skip the remote build phase and fail to produce a signed `.app` or `.ipa`.
Xamarin Customer Support
As we've added several improvements to our build system and deploying/debugging mechanism since the bug was reported, I'm resolving it tentatively as Fixed.
That said, if you're still facing this issue with current bits, please feel free to reopen the bug.