Forum Xamarin.Mac


The Xamarin Forums have officially moved to the new Microsoft Q&A experience. Microsoft Q&A is the home for technical questions and answers at across all products at Microsoft now including Xamarin!

To create new threads and ask questions head over to Microsoft Q&A for .NET and get involved today.

Issue running bundled executable within application after code-signing / notarization

MichaelBothMichaelBoth AUMember ✭✭✭

For some time now, one application I work on with Xamarin for Mac has bundled the WKHTMLTOPDF application for production of PDF files from HTML. Until recently - a couple of weeks ago - this worked fine, and there wasn't any need to code-sign WKHTMLTOPDF separately. However, recently Apple must have tightened their requirements, and without WKHTMLTOPDF being code-signed, the resultant installer package for the application would not be notarized. To address this I've run the following command:
codesign -s "Developer ID Application: Company Name (CompanySigningID)" --timestamp --entitlements entitlements.plist -o runtime wkhtmltopdf
... and with this the overall application passes notarization. The 'entitlements' are the same as the ones we've used for the main application.

However, after code-signing, WKHTMLTOPDF doesn't run properly... examining standard out / error out dumps, it fails when it starts to load the HTML file (which is a file produced and stored on the local file system), with an exit code of 138 (which I suspect is the exit code from the embedded / patched QT functionality within WKHTMLTOPDF; I haven't been able to track down exactly what this exit code means, though, just yet). My suspicion is that, with the code-signing, the running of WKHTMLTOPDF (via Process.Start) is requiring file system, but there is no provision for prompting the user to allow this access, and it just fails.

Without WKHTMLTOPDF being code-signed, it runs and functions correctly, however then the notarization fails, so this is a non-starter. I am at a bit of a loss how to progress from here, or even how to gather extra information that might help in narrowing down the issue. Does anyone have any tips or information that might be of assistance, please?


  • ChrisHamonsChrisHamons USForum Administrator, Xamarin Team Xamurai
    • Is the application using the hardened runtime?

    Try running the application from the command line with runtime logging enabled:

    (Fix up path and app name)

    MONO_LOG_LEVEL=debug /Applications/

    and post it here.

  • MichaelBothMichaelBoth AUMember ✭✭✭
    edited July 2020

    Thanks Chris. Yes, the 'host' application is running with 'Enable hardened runtime' checked for it's Entitlements, and this is the Entitlements file used by both the 'host' application and WKHTMLTOPDF (for better or worse):
    <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" ""> <plist version="1.0"> <dict> <key></key> <true/> <key></key> <true/> <key></key> <true/> </dict> </plist>

    Also, if I pause debugging within the main application (inside Visual Studio) just prior to running WKHTMLTOPDF as a process, but instead run the exact same command via Terminal, it completes without error and produces the PDF.

    I'll do what you've suggested re: debugging ASAP, and will post back here.

  • MichaelBothMichaelBoth AUMember ✭✭✭

    Chris, attached is a ZIP of a the log file after a basic session with MONO_LOG_LEVEL=debug (run from within VS). I can find the reference to the WKHTMLTOPDF call, and the related "Setting pid 9078 signalled, exit status 138" return, but can't make much sense of anything else in-between.

  • MichaelBothMichaelBoth AUMember ✭✭✭

    I managed to solve this issue via trial and error - eventually I tried using an 'entitlements.plist' for WKHTMLTOPDF that had all the (6?) runtime exception entitlements enabled, and after that WKHTMLTOPDF runs without errors for a code-signed and notarized installer. Whew!

  • ChrisHamonsChrisHamons USForum Administrator, Xamarin Team Xamurai

    It is surprising that the required entitlements changed, but I could see Apple changing their minds here. It isn't like they document this behavior in detail.

  • MichaelBothMichaelBoth AUMember ✭✭✭

    My code-signing / notarization procedure hadn't changed for a while - months? - and this situation arose after a new Developer Agreement had to be confirmed, so I assume Apple had tightened up requirements at the same time.

Sign In or Register to comment.