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.
1) the autogenerated key in entitlements.plist is generated erroneously:
com.Housatonic appears twice - it should appear only once. This results in error when submitting to store.
ERROR ITMS-90286: "Invalid Code Signing Entitlements. Your application bundle's signature contains code signing entitlements that are not supported on Mac OS X. Specifically, value '3P26RN5ZVG.com.Housatonic.com.Housatonic.Project-Viewer' for key 'com.apple.application-identifier' in 'com.Housatonic.Project-Viewer.pkg/Payload/ProjectViewer365.app/Contents/MacOS/ProjectViewer365' is not supported. This value should be a string starting with your TEAMID, followed by a dot '.', followed by the bundle identifier ."
workaround: edit the Entitlements.plist, add the ke with the correct value and it doesn't get overwritten
After fixing this, next signing issue:
2) CFBundleExecutable key missing from info.plist. The build did upload but was instantly marked as invalid binary and an email was sent:
"Bad Bundle Executable - You must include a valid CFBundleExecutable key in your bundle's information property list file." This should normally be auto generated on build
workaround: add the CFBundleExecutable key manually in info.plist
3)using the Archive for Publishing option to sign the app and send to store results in many different weird signing errors reported by the store:
ERROR ITMS-90267: "The name of your application bundle must end with '.app' and not contain characters ':'."
ERROR ITMS-90270: "Unsupported toolchain. Packages submitted to the App Store must be created either through Xcode, or using the productbuild tool, as described in "Submitting your Mac apps to the App Store." Packages created by other tools, including PackageMaker, are not acceptable. [SIS]"
ERROR ITMS-90236: "Missing required icons. The application bundle does not contain an icon in ICNS format, containing both a 512x512 and a 512x512@2x image. For further assistance, see the Apple Human Interface Guidelines."
ERROR ITMS-90296: "App sandbox not enabled. The following executables must include the "com.apple.security.app-sandbox" entitlement with a Boolean value of true in the entitlements property list: [( "com.Housatonic.Project-Viewer.pkg/Payload/mdTmpDir1927807944/Contents/MacOS/ProjectViewer365" )] Refer to App Sandbox page at https://developer.apple.com/devcenter/mac/app-sandbox/ for more information on sandboxing your app."
Submitting the package generated in /bin worked after working around 1) and 2). This is Xamarin.Mac Unified. We have submited a build using Xamarin.Mac classic last week and we encountered no such problems.
1. can you attach your provisioning profile? The value gets expanded from that and the exact same code works fine for iOS (the code is shared).
2. legitimate bug, seems like this key is not being set by the CompileAppManifeest MSBuild task, I think because it was expected that the mmp tool would do that.
3a. well, the app name definitely ends with .app, so that means your app name probably has an illegal character? What is your app bundle name in the bin directory?
3b. pretty sure we use productbuild, so no clue.
3c. Did you specify a *.icns file in your Info.plist? Did you set the BuildAction of your *.icns file to "BundleResource"? Is it in your app bundle? Where?
3d. Did you enable the App Sandbox entitlement in your Entitlements.plist?
@Radu - For us to make progress on this item, we might need a small example application (not you entire app) attached.
Please note, that bugzilla is for reporting actual defects in our products and not requesting assistance. support.xamarin.com (requires a business license) or the forums are the primary channels for that.
Here's two guides on how to write bug reports that have sufficient information to be answered:
Created attachment 11193 [details]
Chris - I don't require assistance and I have not requested any. This is a bug report. Like I said, I already found workarounds for the issues presented and I managed to submit in store. I have just presented and detailed the difficulties which I have encountered which are actual defects in your products...
Jeffrey - about point 3, everything is fine with app. If I submit to store the generated .pkg in the bin folder, it gets accepted (after applying the workarounds for 1 and 2). But if I send the .pkg built using Archive for Production I get all those weird errors. I attached the provisioning profile
I guess one could just make an empty app and try to submit build and see how that goes...
@Jeff - This sounds like a bug in the new publishing workflow?
Probably, yea... but why reassigning to me? I didn't write the publishing workflow code.
Reopening since the provisioning profile has been added.
For iOS, the rule is that you replace * with the CFBundleIdentifier string from the Info.plist
Apparently for Mac it's different, hence the double com.Housatonic.
Wait, no, this is odd. For all of my Mac provisioning profiles, they are in the format:
Chris: parts 1 & 2 should be fixed in maccore master now.
So it appears there is non-trivial problems with the publishing workflow. Assigning to David. Thanks Jeff!
I've got a macios-cycle5-bug-30052 branch for the macios fixes and a monodevelop-5.9-bug-30052 branch for the XS fixes I've got so far
I don't have AppStore publishing keys for Mac, so someone else will have to test this: http://storage.bos.internalx.com/monodevelop-lion-monodevelop-5.9-bug-30052/47/474bfdd07da4d0bf9a24e682d42455f4980005be/XamarinStudio-18.104.22.168.dmg
No idea if it works, but it should be better.
wow... you closed a bug without knowing if it is fixed.
I'm just that good :-)
In the FIXED state, it just means QA will bang on it.
This fix did not make it into C5SR2, and will now be slated for C5SR3.
so this means that allowing your clients to publish mac apps in app store is not high priority? or what?
Reassigning to the Mac team (I'm on the iOS team so I have no idea why this keeps getting assigned to me).
We think we have this fixed now with:
QA will do another pass to see if we got it nailed down.
The final remaining issue discussed in comment 20 - 23 will be addressed in the Cycle 6 release.
If it's for C6, it needs to be cherrypicked into the cycle6 branch.
@lluis already done by @jeff
No, that commit won't fix this problem. That commit only adds the .dSYM directory to the archive once mmp puts the .dSYM directory in the correct location.
The reason this still fails is because mmp is outputting the .dSYM directory inside of the .app bundle.
When the user uploads his .app bundle to itunes-connect, it reports the following errors:
1. App Sandbox is not enabled
2. The app could not be re-signed for submission
3. Invalid bundle: [project.pkg/Payload/project.app/Contents/MacOS/project.dSYM], with bundle identifier com.apple.xcode.dsym.com.companyname.project
All 3 of these errors are due to the fact that the .dSYM directory is dumped into the .app bundle.
1. itunes-connect assumes that the .dSYM directory within the .app bundle is yet another app bundle. Since the main app bundle is being codesigned with the "App Sandbox" entitlement, it expects ALL child app bundles to be code-signed with the sandboxing entitlement because it would make no sense for inner apps to not have that restriction when the parent app does.
2. it can't be re-signed because it doesn't have an executable in the .dSYM directory (because it's not a real app bundle)
3. notice that it is complaining about the dSYM directory with a bundle identifier of com.apple.* which it says is illegal.
This does not appear to be fixed at all. Going to track down all of the use cases, fix them, and get some good manual test coverage if nothing else. We've bounced this around way too much......
Alright, sorry for the confusion. There were 3 bugs here.
1) The archive logic in XS was just broken. @Jeff fixed that up with two additional fixes.
2) The built in validate / publishing workflow is just broken fwict - https://bugzilla.xamarin.com/show_bug.cgi?id=33627
3) If you build as debug and try to submit, it will fail due to https://bugzilla.xamarin.com/show_bug.cgi?id=33628
I'm going to call this bug the first one, which should now be fixed in master and C6. The other two are outstanding, and won't make C6.
I'm going to work with QA to get better testing on this feature.
I have checked this issue with cycle 6 builds
and observed that I am able to submit "MacCoolApp" app to the App Store successfully. Please refer the screencast given below.
This issue has been fixed and working fine with the Cycle 6 builds, so as of now I am closing this issue. If anyone face this issue again so feel free to Re-open it.
=== Xamarin Studio ===
Version 5.10 (build 812)
Installation UUID: 3d25a767-a003-4a7d-9f5e-e57987cf6cf0
Mono 4.2.1 (explicit/cc1cf60)
GTK+ 2.24.23 (Raleigh theme)
Package version: 402010062
=== Xamarin.Profiler ===
=== Xamarin.Android ===
Version: 22.214.171.124 (Enterprise Edition)
Android SDK: /Users/mac360_xamarin/Library/Developer/Xamarin/android-sdk-macosx
Supported Android versions:
2.3 (API level 10)
4.0.3 (API level 15)
4.1 (API level 16)
4.4 (API level 19)
4.4.87 (API level 20)
5.0 (API level 21)
5.1 (API level 22)
SDK Tools Version: 24.3.4
SDK Platform Tools Version: 23
SDK Build Tools Version: 23
Java SDK: /usr
java version "1.7.0_71"
Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)
=== Xamarin Android Player ===
Location: /Applications/Xamarin Android Player.app
=== Apple Developer Tools ===
Xcode 7.0 (8227)
=== Xamarin.Mac ===
Version: 126.96.36.199 (Enterprise Edition)
=== Xamarin.iOS ===
Version: 188.8.131.52 (Enterprise Edition)
Build date: 2015-09-30 15:22:15-0400
=== Build Information ===
Release ID: 510000812
Git revision: feb7640e9c013af8bb30a6a72e5c3d2ebcefdcbd
Build date: 2015-10-02 19:15:27-04
Xamarin addins: f99ff0a7da6a31661870ef3567390a7e84e9a3c4
Build lane: monodevelop-lion-cycle6
=== Operating System ===
Mac OS X 10.10.5
Darwin mac360-xamarins-Mac-mini.local 14.5.0 Darwin Kernel Version 14.5.0
Wed Jul 29 02:26:53 PDT 2015
is this live yet?
I can't seem to be able to publish the pkg generated using the "Archive For Publishing" option. But it does work by choosing the generated pkg file in bin/AppStore.
In other words, 5 months later there's nothing new here. Point 3) behaves exactly the same
"I'm going to call this bug the first one, which should now be fixed in master
The other two are outstanding, and won't make C6."
The first one should be fixed in C6, which is currently in Alpha. If it isn't, please let me know.