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.
This has happened on two Mac machines after setting up the dev environment and installing Xamarin bits. When building a project that uses the XMA connection, I get this popup on my Mac four consecutive times: http://screencast.com/t/rwEbHfU12E
If I deny any number of permission dialogs, then I get this failure in the IDE error list:
>User canceled the operation. BlankNativeSharedAppShared.iOS
>C:\Program Files (x86)\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets 1516
The project finishes building after entering all credentials successfully. Otherwise, it will hang indefinitely.
This was confusing when it first happened because I repeatedly had to enter the same credentials. Then, I had the thought that it may have to do with the XMA processes running on the build agent - four prompts, four agents. Although, there is already an established XMA connection prior to the prompts appearing. Both machines are connected via WiFi - if that matters, I can't yet tell.
1) Create a project which requires XMA at compile time
2) Build the project while connected to the build agent
3) Observe the prompts on the build agent
Windows environment: https://gist.github.com/BenBeckley/0fe715f97f88ebca9ffaa2cad29971d2
build agent environment: https://gist.github.com/BenBeckley/4215364965854a03937c6bdcf9d4b114
Created attachment 16549 [details]
Contains build logs and IDE logs
It looks like the iOS code signing key you're using is in the System keychain, so the Mac OS authentication mechanism is requesting access to that keychain item when running the `codesign` step.
The prediction would be that you would get the same set of dialogs if you ran the same build (using the same code signing key) directly in Xamarin Studio on the Mac (under the same user account currently used by VS).
(Non-public Bug 31959 might provide some useful additional background context. The short version is that there are 2 options for unlocking the keychain:
(a) Store the permission for `codesign` permanently.
(b) Click through all of the dialogs on each build.)
I am not encountering these dialogs on the Mac functioning as the XMA host when building a project in XS using the same code signing key.
I also switched my main development Mac to WiFi and did not encounter this issue. So, I assume that there are other elements affecting this.
This is also occurring whether or not the System keychain is unlocked.
> This is also occurring whether or not the System keychain is unlocked
I'm not sure there is an "unlocked" state for the _keychain_ in the way it sounds like you're picturing. The "Allow" button on the dialog from Comment 0 will allow the key to be used _once_. For keys that are stored in the _login_ key chain, you will get an additional "Always Allow" button, but it seems that the dialog for keys in the System keychain don't offer that button. So you might need to explicitly allow `codesign` to access the key as described in step 4 from Bug 31959:
1. Open the Keychain Access app.
2. Navigate to the key that is being used to sign the app and double-click it.
(a) Ensure `codesign` is listed under "Access Control [tab] -> Confirm before allowing access [radio button] -> Always allowing access by these applications".
(b) Probably a less secure and therefore less recommended option, set "Access Control [tab] -> Allow all applications to access this item [radio button]".
Ah yes, that described exactly the scenario I am encountering - and both options ended up working for me. Thank you, Brendan!