Codesign fails with replacing existing signature and errSecInternalComponent

[tpitman]

Description

I was using MAUI SDK 401. Everything was working fine. I got tired of dealing with VSCode issue and decided to switch to using VS 2022 on Windows on ARM in Parallels. I am on a Mac.

I had everything installed, but saw there was an update to 17.11.5. I installed the update and it seems that it installed an update to 8.0.403.

When I tried to debug with that it said I needed XCode 16. I had been holding off, but decided to go ahead and see if I could get this all working on the latest.

Long story short I am able to build and debug to an iOS physical device, but when I try to do a release build for distribution to the app store I get an error.

It happens during the codesign step.

I get 2 and they are happening on one of the framework files included in my app as far as I can tell. Here are the 2 lines for the errors:

If I use the publish feature in VS 2022 for Windows it does build an archive, but when I try to upload it I get an error trying to upload it.

The command I use to do the build is:

dotnet publish -f net8.0-ios -c Release

That is the command I have been using ever since I had to stop using VS For Mac and it has worked fine until 8.0.403.

Now I am stuck and can't release the app update that I really need to update.

Please help. I am in a bad way right now.

Steps to Reproduce

1. Build on command line for release.
2. Get codesign error

Link to public reproduction project repository

No response

Version with bug

8.0.82 SR8.2

Is this a regression from previous behavior?

Yes, this used to work in .NET MAUI

Last version that worked well

8.0.70 SR7

Affected platforms

iOS

Affected platform versions

iOS 15

Did you find any workaround?

No

Relevant log output

No response

[similar-issues-ai]

We've found some similar issues:

• Code Signing fails for iOS #15344 , similarity score: 81%

If any of the above are duplicates, please consider closing this issue out and adding additional context in the original issue.

Note: You can give me feedback by 👍 or 👎 this comment.

[ninachen03]

This issue has been verified using Visual Studio 17.12.0 Preview 3.0(8.0.92) iOS version is 17.5. Cannot repro it.

[tpitman]

I am trying to do the build on the Mac using the command line. Can you tell me how to update the dotnet stuff to 8.0.92? I have been using the VSCode .NET Install Tool plugin for VSCode. It only shows 8.0.403 as an option when it gets to the version.

[PureWeen]

#20159
https://github.com/dotnet/maui/wiki/Nightly-Builds

Have some info that should help you

[tpitman]

There are so many moving parts and pieces. I just realized that the 8.0.92 you are talking about is the nuget component versions that I just have to change in my csproj files. I did that and that was able to build at the command line without giving the signing error.

It is amazing we are able to ever get anything done with all the different parts and pieces that have to come together in the right sequence. SDKs, workloads, nuget packages.

I thank you and your team for making it all happen. It is complicated and you guys are amazing.

[tpitman]

I spoke too soon. I did a build for the app store and it succeeded. I then uploaded it and downloaded it to a device using TestFlight. As soon as the app started it crashed. I have not made any changes to the app since the last time I uploaded it, so the only difference was changing the things mentioned above.

I have found that sometimes when changing between building with my Mac command line or VSCode and using VS for Windows via the Mac remote connection it can do this and the solution is usually to delete the bin and obj folders and do a new build.

I did this and now I get the signing error again.

So I am not sure what to do now. I do not know what fixed it and I don't know what broke it again.

[tpitman]

As an FYI, I decided to try publishing from Windows VS again. It built fine, but then wouldn't upload. So I copied the IPA file to my Mac and used my command line to try to upload it. It said the provisioning profile was invalid.

The exact same settings in the csproj project file work fine when I publish on the Mac and it was set to automatic provisioning.

I then tried manually setting the profile in the settings, built and that uploaded fine and the build doesn't crash.

So I am able to build and upload using Windows VS, but not the Mac on the same project.

I will do that for now, but am not happy about this result.

I know others have said this, but I sure wish VS for Mac had not been discontinued. It was soooooo sweet. The new VSCode path just doesn't work well and this Windows VS combined path is also not great.

I will try to make due.

[twriverside]

@tpitman I'm not sure if this is your issue, but I have recently gone through the gauntlet of having to do all iOS building, debugging, and publishing on the mac due to the recent Apple Developer account login issue, and I got a lot of errSecInternalComponent errors until I realized that you must run the build on the mac first in order to unlock the keychain for the signing certificate before it will work over SSH.

They apparently don't have any way to prompt you for authentication other than the graphical popup on the mac when the code signing tool runs, and I believe you have to check the option to keep it unlocked for it to work in the future without that prompt (and at all if your are using SSH).

I found some SO answers saying that you can lock and then unlock the login keychain with the security command, but they did not mention that this will have no effect on SSH unless the keys your are using have been unlocked already during the signing step. I accidentally fooled myself into thinking it worked when debugging with my development certificate because I was also playing around with VSCode on the mac (since that appears to be the only way to get debug log output, I get nothing when using dotnet run). When I went to publish I ran into the same issue where I couldn't finish the build due to errSecInternalComponent because I hadn't used the distribution certificate before.

Also, I found that when I went to publish to the store in XCode I had to use the Custom path because it was not detecting the provisioning profile. The custom process lets you select it manually. For the actual dotnet publish step I believe you can't use automatic provisioning by design, but if you set <ProvisioningType> to manual and set <CodesignKey> to your distribution certificate it is able to automatically find your provisioning profile (but this is confusingly not "automatic provisioning", since that involves talking to Apple's servers and generating the needed development certificate and profile for development only).

With Apple pulling this kind of sudden breaking change nonsense I think MS needs to focus on having the basics covered for the dotnet CLI for all phases of development (so we at least have a solid thing to fall back on regardless of what your primary tool is). It makes sense to showcase the nice convenient tools, but they are so complex (and so dependent on external factors) that it makes them feel unreliable.

[tpitman]

That may be why it started working without me knowing why. I thought is was other things I changed, but now I back at 8.0.82 and it is still working, so maybe?

[Kanat9494]

I'm getting the same error after I bought a new mac. I can't run app on ios simulators, though I can publish ios app with Windows Visual Studio, but I can't run and check the app on simulators. I'm just testing on Android and publishing for ios without testing on ios device or simulator