Codesign Error with Large Framework #20193
Comments
|
It certainly looks like we should add some deduplication logic to avoid signing the same file multiple times. As a potential short-term workaround I could implement a way for you to disable signing in parallel - that way the codesign invocation won't step on eachother's toes. Would that work for you? I could probably get this workaround in the next service release. |
|
Any sort of work around in the interim would be great, thanks! |
…eable. We currently have an issue with codesigning duplicated files in parallel (xamarin#20193). The proper fix is somewhat complex, so this implements a simple workaround for customers, where they can just disable parallelism if they run into this problem (and since it's simple, it's easier to backport too). Ref: xamarin#20193.
…eable. (#20242) We currently have an issue with codesigning duplicated files in parallel (#20193). The proper fix is somewhat complex, so this implements a simple workaround for customers, where they can just disable parallelism if they run into this problem (and since it's simple, it's easier to backport too). Additionally, it's not a bad idea to be able to configure the level of parallelism. Ref: #20193.
…n the codesign task configureable. We currently have an issue with codesigning duplicated files in parallel (xamarin#20193). The proper fix is somewhat complex, so this implements a simple workaround for customers, where they can just disable parallelism if they run into this problem (and since it's simple, it's easier to backport too). Additionally, it's not a bad idea to be able to configure the level of parallelism. Ref: xamarin#20193. Backport of xamarin#20242.
|
I've added a property you can set to limit the number of concurrent codesign processes. Setting it to 1 will effectively disable any concurrent codesigning processes, thus avoiding any race conditions: <PropertyGroup>
<CodesignMaxDegreeOfParallelism>1</CodesignMaxDegreeOfParallelism>
</PropertyGroup>This won't be included in the next service release (too late for that), but it will be in the subsequent one. |
|
@rolfbjarne Thank you for the assistance. Will this fix be available for projects using dotnet maui 7 or will this only be available for dotnet maui 8? |
…n the codesign task configureable. (#20247) We currently have an issue with codesigning duplicated files in parallel (#20193). The proper fix is somewhat complex, so this implements a simple workaround for customers, where they can just disable parallelism if they run into this problem (and since it's simple, it's easier to backport too). Additionally, it's not a bad idea to be able to configure the level of parallelism. Ref: #20193. Backport of #20242.
Only for .NET 8. |
We have added a framework with a lot of plugins and libraries to our application. We are seeing periodic build failures on our CI system and on local machines when building the release build.
The error always refers to failing to sign libz.dylib in the framework, which definitely exists. Looking at the verbose logging, it appears that libz.dylib is getting signed and resigned a lot of times. Each library in the framework has a reference to libz.dylib. It appears the signing process tries to follow all the dependencies of each library, which causes libz.dylib to get signed way more than needed.
Removing a bunch of unneeded files from the framework reduced the frequency of error. Passing /m:1 to the dotnet command has no effect on the issue.
Steps to Reproduce
Example command:
dotnet publish -f:net7.0-maccatalyst -c:Release BuildIssue.csproj
Expected Behavior
No errors
Actual Behavior
Intermittent error that is returned:
Tool /usr/bin/codesign execution finished (exit code = 1).
..libz.dylib: replacing existing signature
..libz.dylib: No such file or directory
Environment
dotnet maui 7 and 8
Tested with XCode 14.3.1, 15.0.1, and 15.1.
Build Logs
msbuild2.binlog.zip
Example Project (If Possible)
The text was updated successfully, but these errors were encountered: