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.
Created attachment 7244 [details]
Sample project to demonstrate the regression
The update to Xamarin Studio 18.104.22.1689 breaks sandboxing, simple as that.
Attached is a newly created project with the only changes being the sandbox entitlements switched on (and the Client permission). If you do a release build on Xamarin Studio 5.1 and check if it's sandboxed (eg. RB App Checker Lite or run it from Applications to see if it creates a container) you'll note that it doesn't. Downgrade to Xamarin Studio 5.0, rebuild and note that this time the app is indeed sandboxed as it should be.
Note that you'll need developer ID certificates on your system to test it properly.
Also note that I've tried this on two machines and seen the same problem on both. Am running on OS X Mavericks 10.9.3 with everything updated.
I can confirm that sandboxing is broken on the latest version.
I have a work around to get you up and running until a fix can be developed and pushed out to stable.
If you bring up the errors pad and click "build output", you'll notice a bunch of lines of commands during the build. One of them will look similar to:
codesign -v --force --sign "Mac Developer: Chris Hamons (#######)" "--resource-rules=/Users/donblas/Downloads/TestSandboxing/TestSandboxing/bin/Release/TestSandboxing.app/Contents/ResourceRules.plist" "/Users/donblas/Downloads/TestSandboxing/TestSandboxing/bin/Release/TestSandboxing.app"
The problem is that the command is missing:
If you add the full absolute path instead of PATH_TO_Entitlements.plist and run that command in the terminal, your app should be correctly sandboxed.
I'm going to work on a fix to Xamarin Studio to fix this, but as I noted it will take a nontrivial amount of time to reach you.
Let me know if that doesn't work for you.
Another thing I've noticed that may be useful.
The issue appears to be related to trouble finding the "Provisioning profile". If you right click your project, properties, select Mac Signing, and then select a specific "Provisioning profile" instead of the default Automatic, your issue might be worked around as well.
We should be doing a better job either reporting an error or selecting the correct profile (so this still is a bug).
Alright, it appears the real bug is that we don't warn if you select signing \ entitlements but have provisioning set to None. In the stable version, I can "fix" this issue by setting a non-None provisioning option.
We should at least warn in this case.
Promoted to a build error in master \ 8b4bcf7b2fea73e6d99b06646d40cff10d0b1e68.
It will make its way to stable after some time, but selecting a provisioning profile is the correct solution either way.
you might be able to try proposing this change for 5.2
Thanks for the workaround Chris. And picking a provisioning profile does indeed allow me to proceed.
As an aside, in my app not being able to sandbox without a provisioning profile is not a problem as my embedded login helper (which I don't want to use a provisioning profile to sandbox as I don't believe it would be accepted to the app store) is written in Objective-C (and XCode lets me sandbox without a PP), but if I were building a Xamarin.Mac helper app (admittedly unlikely) that I'd want to sandbox without a PP then the command line argument workaround is fine, albeit not as nice as 5.0 behaviour.
I filed this bug:
so we don't forgot to look at allowing that use case in the future.