Trying to build a .NET for iOS binding project results in build errors with "The name '_CodeSignature' is reserved and cannot be used."

[brunck]

Apple platform

iOS

Framework version

Other

Affected platform version

.NET 8, .NET 9

Description

I created a NuGet package with .NET for iOS bindings for an .xcframework. I have to build these xcframeworks myself from source to shorten their path due to the Windows long path error in Visual Studio.

Trying to consume this package in a .NET MAUI iOS app which is then submitted to TestFlight results in errors like NSUnderlyingError = "Error Domain=IrisAPI Code=-19241 \"Asset validation failed\" UserInfo={status=409, detail=Missing or invalid signature. The bundle 'x' at bundle path 'y.framework' is not signed using an Apple submission certificate.

So assuming that the .xcframework needs to be signed first, I code-sign it after I build the xcframework.

But then trying to build the binding project (which generates the NuGet package on build) I get build errors stating "The name '_CodeSignature' is reserved and cannot be used."

Is this a bug on the .NET end, and/or do I have to somehow extract the .xcframework after building the NuGet package without code signing, code-sign, then put the NuGet package back together?

Steps to Reproduce

1. Build .NET for iOS binding project with a code-signed xcframework native reference

Did you find any workaround?

No

Build logs

No response

[rolfbjarne]

So assuming that the .xcframework needs to be signed first, I code-sign it after I build the xcframework.

No, the (xc)framework is signed when building the app that consumes the framework.

Trying to consume this package in a .NET MAUI iOS app which is then submitted to TestFlight results in errors like NSUnderlyingError = "Error Domain=IrisAPI Code=-19241 \"Asset validation failed\" UserInfo={status=409, detail=Missing or invalid signature. The bundle 'x' at bundle path 'y.framework' is not signed using an Apple submission certificate.

Either the framework wasn't signed at all, or it was signed using an incorrect certificate.

Can you get an MSBuild binlog for the build that produces such an error? That should show if/how the framework was signed.

[brunck]

Since I'm building everything myself, and the settings are set to not sign the various frameworks that I'm building, I assume that the .frameworks are not ever signed at all. Do I need to sign those before creating xcframeworks with them?

[brunck]

Here is a binlog:

msbuild.binlog.zip

[rolfbjarne]

Trying to consume this package in a .NET MAUI iOS app which is then submitted to TestFlight results in errors like NSUnderlyingError = "Error Domain=IrisAPI Code=-19241 \"Asset validation failed\" UserInfo={status=409, detail=Missing or invalid signature. The bundle 'x' at bundle path 'y.framework' is not signed using an Apple submission certificate.

Which framework(s) exactly is TestFlight complaining about?

[brunck]

Error Domain=IrisAPI Code=-19241 \"Asset validation failed\" UserInfo={status=409, detail=Missing or invalid signature. The bundle 'com.datadogqh.Datadog' at bundle path 'Payload/sevendaytimer.app/ios-arm64_arm64e/DatadogCore.framework' is not signed using an Apple submission certificate.

Not sure why it's complaining about just that one.

[brunck]

Just checking in again here...

[rolfbjarne]

I think the clue is in the path of the framework:

Payload/sevendaytimer.app/ios-arm64_arm64e/DatadogCore.framework'

That's not where a framework should be, the expected path is:

Payload/sevendaytimer.app/Frameworks/DatadogCore.framework'

which is why it's not signed (we sign everything in .app/Frameworks/.framework).

Looking at the binlog, it seems DatadogCore.framework is also in the expected location (in the *.app/Frameworks directory), so the problem is an extraneous copy of DatadogCore.framework in an unexpected location.

Investigating a bit more, this seems to come from the Bcr.Datadog.iOS.Core NuGet, where DatadogCore.framework is included twice: once as DDC.xcframework inside the binding resource package next to the assembly:

$ unzip -l /Users/rolf/Downloads/bcr.datadog.ios.core.2.22.2.nupkg
Archive:  /Users/rolf/Downloads/bcr.datadog.ios.core.2.22.2.nupkg
[...]
  5712896  01-22-2025 15:45   lib/net9.0-ios18.0/core.dll
     1243  01-22-2025 15:44   lib/net9.0-ios18.0/core.resources/DDC.xcframework/Info.plist
  1809488  01-22-2025 15:44   lib/net9.0-ios18.0/core.resources/DDC.xcframework/ios-arm64_arm64e/DatadogCore.framework/DatadogCore
[...]

(this part is correct)

and then also included as a resource inside core.dll:

$ monodis --presources lib/net9.0-ios18.0/core.dll
       0: __monotouch_content_ios-arm64__arm64e_fDatadogCore.framework_fDatadogCore (size 1809488)
  1b9c58: __monotouch_content_ios-arm64__arm64e_fDatadogCore.framework_f__CodeSignature_fCodeResources (size 6310)
  1bb508: __monotouch_content_ios-arm64__x86__64-simulator_fDatadogCore.framework_fDatadogCore (size 1638944)
  34b730: __monotouch_content_ios-arm64__x86__64-simulator_fDatadogCore.framework_f__CodeSignature_fCodeResources (size 6510)
[...]

The resource names encode the target filenames of the resources so it looks a bit weird, but it's easy enough to see that "DDC.xcframework" part of the path is nowhere to be found, which means that the build won't detect these files as a framework, but as plain resource files that are added to the app bundle as-is.

My guess is that the binding project that builds the Bcr.Datadog.iOS.Core NuGet is incorrect - is this something you have control over / access to? Is so, please attach the binding project's csproj here. If not, you'll have to contact the vendor.

[brunck]

Here is the .csproj file.

I’m building the frameworks and xcframeworks from source, so it’s entirely possible that something has gone haywire at that level, although that would still be a bit odd because I did have them building in such a way that things were working, but all as one NuGet package, and haven’t really varied how that was done in this case.

Core.csproj.zip

[rolfbjarne]

Try removing these lines from the csproj:

<Content Include="$(XCFrameworkPath)/**">
  <Pack>true</Pack>
  <PackagePath>lib/net8.0-ios17.0</PackagePath>
</Content>

<Content Include="$(XCFrameworkPath)/**">
  <Pack>true</Pack>
  <PackagePath>lib/net9.0-ios18.0</PackagePath>
</Content>

If you then attach the resulting nupkg here, I can have a look at it.

[brunck]

Here is the .nupkg file.

Bcr.Datadog.iOS.Core.2.22.2.nupkg.zip

[rolfbjarne]

Here is the .nupkg file.

Bcr.Datadog.iOS.Core.2.22.2.nupkg.zip

The managed assembly in that nupkg doesn't have any resource in it, which is how it's supposed to be.

Does your main project still fail code signing with this updated version of the NuGet?

[brunck]

No, after testing deployment to TestFlight using versions created now, like this one, the app is accepted. Looks like the parts you mentioned needing removal fixed it.

[rolfbjarne]

Great, I'll close this then.