MacOS code signing with "dotnet publish"

[borjafdezgauna]

Hi there,

When I started using Eto Forms, I had to make little modifications in the source code to make it work for my project. So I downloaded the source code and included it in my project instead of referencing the Nuget package. Now, all the issues I had seem to have been solved and I am trying to use the Nuget package again.
Some of the users of the apps I develop still use "old" versions (High Sierra and later) of MacOS and so, I need to use NetCore 3.1 instead of the more up-to-date Net5/6. On Windows and Linux, everything builds properly but I'm having issues notarizing my app on MacOs.

I use this command on my Azure pipeline (this works in my machine and on Azure with my modified copy of Eto):

dotnet publish <project> -c Release -r osx-x64 --self-contained true -f netcoreapp3.1

And I get this error with Eto 2.6.1 (from Nuget):

  ../../bin/mac/osx-x64/<MyApp>.Mac.app/: bundle format unrecognized, invalid, or unsuitable
/Users/runner/.nuget/packages/eto.platform.mac64/2.6.1/build/CodeSign.targets(37,5): error MSB3073: The command "codesign --force --deep --options runtime --entitlements "/Users/runner/.nuget/packages/eto.platform.mac64/2.6.1/build/CodeSign.entitlements" --sign "<signature>" "../../bin/mac/osx-x64/<MyApp>.Mac.app/"" exited with code 1. [/Users/runner/work/1/s/Apps/<MyApp>.Mac/<MyApp>.Mac.csproj]

Anyone has any idead what could have changed that makes my build on Azure fail?

Thanks!

Edit: I had missinterpreted the source of my error. I have updated the error message. Sorry

[cwensley]

Not sure what is going on with the error, but in any case notarization doesn't work with .NET Core 3.1 anyway due to the way they build the executables. You must use .NET 5 or later to pass notarization.

It could also be the later updates to the build scripts that fix the error(s) you are using that aren't in 2.6.1. You could try one of the 2.6.2 CI nuget packages from myget to see if that resolves the above issue (see the readme for the myget source link).

[borjafdezgauna]

Thank you Curtis for you answer. I had missinterpreted the source of my error and it works fine on my machine (Monterey, NET6), but fails on my Azure pipeline. I will keep digging into this, but if anyone has any idea what could be causing this, I would much appreciate it
Cheers!

[cwensley]

Are you installing your apple developer certificate on the azure pipeline?

[borjafdezgauna]

Yes, I am

…

On Wed, Apr 27, 2022, 17:01 Curtis Wensley ***@***.***> wrote: Are you installing your apple developer certificate on the azure pipeline? — Reply to this email directly, view it on GitHub <#2201 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACYT3LUGIBD7FLWYUDOVWZDVHFJETANCNFSM5UITLNDQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[cwensley]

Could you generate a binlog of the build and send it over? (/bl command line option) You can email it to me at curtis dot wensley at picoe dot ca if it has any sensitive data.

Also, are you using the .NET 5 or 6 SDK? Even though you're targeting netcoreapp3.1, you can still use the newer sdks. I have not tested with the .NET Core 3.1 sdk specifically.

[cwensley]

Thanks for sending the binlog file. Looks like you have set MacAutoPublishBundle to false in your project, which is required to be true. Also you don't need to use dotnet publish, just dotnet build with the Release configuration. Hope this helps!

[cwensley]

Hmm, there's this in the BundleDotNetCore.targets:

<MacAutoPublishBundle Condition="$(MacAutoPublishBundle) == '' AND $(RuntimeIdentifier) == ''">True</MacAutoPublishBundle>

So, if you specify a RuntimeIdentifier it doesn't set it to True.. I have to dig further..

At any rate, if you simply specify <RuntimeIdentifiers>osx-x64</RuntimeIdentifiers> (note the 's'), and build Release without specifying the RID, it may work.

[borjafdezgauna]

I did some tests and added to my mac64 project:
<RuntimeIdentifiers>osx-x64</RuntimeIdentifiers>

I was only able to build it us doing:
dotnet publish c Release -r osx-x64 --self-contained true -f netcoreapp3.1

No luck doing just dotnet build. Might be related to setting a specific version of netcore3.1 (they dropped support of HighSierra after this version):

- task: UseDotNet@2 displayName: 'Use .NET Core sdk' inputs: packageType: sdk version: 3.1.413 installationPath: $(Agent.ToolsDirectory)/dotnet

Now I am back to having the code signing error. I will email you the log in case you have time to take a look. Much appreciated!! Thank you!!

[cwensley]

Get rid of all your parameters. Just do dotnet build -c Release. And use the .NET 5 or 6 SDK.

[borjafdezgauna]

For future reference: I did as suggested (simply dotnet build -c Release) and solved the NETSDK1102 error by adding (as suggested here):
<PublishTrimmed>false</PublishTrimmed>

Problem fixed. Thank you so much Curtis for your time and patience!!

[borjafdezgauna]

Yes, sure. I will email it to you on Monday (I just went on holiday yoday). I am using Net6. Thank you so much for your valuable time!

…

On Wed, Apr 27, 2022, 18:23 Curtis Wensley ***@***.***> wrote: Could you generate a binlog of the build and send it over? (/bl command line option) You can email it to me at curtis dot wensley at picoe dot ca if it has any sensitive data. Also, are you using the .NET 5 or 6 SDK? Even though you're targeting netcoreapp3.1, you can still use the newer sdks. I have not tested with the .NET Core 3.1 sdk specifically. — Reply to this email directly, view it on GitHub <#2201 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACYT3LWB4BYTGCM6YCLBFCLVHFSXFANCNFSM5UITLNDQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>