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 opening a project that has a specific signing Identity / Provision selected, VS on Windows will show the Bundle Signing settings set to Automatic | Automatic. However, the build will fail with a message like:
> iOS code signing key 'iPhone Developer: Xamarin QA (943YW87293)' not found in keychain.
The obvious thing to do next is to visit the Bundle Signing tab in the project's properties but they show it set as Developer (Automatic) | Automatic. VS for Mac will instead show values like this:
Signing Identity: Unknown (iPhone Developer: Xamarin QA ....)
Provisioning Profile: Uknown (16fae78f-xxxxxx-xxxx-xxxxx-xxxx)
That makes it more obvious that you need to select other values or set it back to Automatic. VS on Windows leads you to think that it's set to Automatic but it's still using the values in the .csproj. You have to toggle off Automatic and back again to _actually_ get Automatic.
## Steps to Reproduce:
1. Download the TestSample project attached to Bug 41405.
2. Open this in VS on Windows
3. Build the iOS project
Assuming you don't have the Xamarin QA identity and provisions, you will get an error.
4. Open the Project->Properties of the iOS project
5. Select the iOS Bundle Signing tab
## Expected Results
Parity with what VS for Mac shows to indicate what provision and identity are being used and that they are unknown.
Created attachment 23461 [details]
"BAD" results in Visual Studio on Windows
## Minimized steps followed to test
1. Create a new "Visual C# > iOS > iPhone > Single View App (iPhone)" project.
2. Edit the .csproj file in a text editor.
3. Add the following 2 lines to the "Debug|iPhoneSimulator" PropertyGroup configuration. These are made up values that just follow the format rules for the 2 properties:
<CodesignKey>iPhone Developer: iPhone Developer (111AA11111)</CodesignKey>
4. Navigate to "Project properties > iOS Bundle Signing".
## "BAD" results in Visual Studio on Windows
> Signing identity: Developer (Automatic)
> Provisioning Profile: Automatic
(See also the attached screenshot.)
## "GOOD" results in Visual Studio on Mac
> Signing identity: Unknown (iPhone Developer: iPhone Developer (111AA11111))
> Provisioning Profile: Unknown (0a0a0a00-0a00-000a-a0a0-a00a00000000)
(See also the screenshot attached in the next comment.)
## Additional testing environment info
XamarinVS 220.127.116.11 (60c3d0e)
Microsoft Visual Studio Enterprise 2017 Preview (Pre)
Version 15.3.0 Preview 3.0
Microsoft .NET Framework
Windows 10 Version 1703 (OS Build 15063.413)
US English locale, US Eastern time zone
Logged in with a local user named "Windows User"
Xamarin.iOS 10.12.0.12 (d15-3: 494fcbcf)
Mono 18.104.22.168 (2017-04/478c04a)
US English locale, US Eastern time zone
Logged in with a local user named "Mac User"
Created attachment 23462 [details]
"GOOD" results in Visual Studio on Mac
## Regression status: not a recent regression
> "BAD": XamarinVS 22.214.171.124 (60c3d0e) + Xamarin.iOS 10.12.0.12 (d15-3: 494fcbcf)
> "BAD": XamarinVS 126.96.36.199 (3f99c5a) + Xamarin.iOS 10.8.0.175 (d15-1: a04678c2) "15.1 release"
Fixed via PR 7820
This is fixed in Master but still reproducible on 15-4 lane. Reopening the defect as per comments #9 to make sure Fixed get merged into 15-4 lane as well.
Reopening based on Comment #9
Fixed in 15.4 now (ce1fd9bdf24fdd3fc1902009e3fe8a9d1c08690c)