Pack the IceRpc.Protobuf.Tools task assembly from bin instead of obj - #4942
Conversation
The release workflow signs the assemblies under bin/Release and then runs `dotnet pack --no-build`, but IceRpc.Protobuf.Tools packed its MSBuild task assembly from $(IntermediateOutputPath), so tasks/IceRpc.Protobuf.Tools.dll in the published package was the unsigned obj copy. Pack it from $(OutputPath), as IceRpc.Slice.Tools already does. Fixes icerpc#4814
There was a problem hiding this comment.
🟢 Approval recommended
The focused packaging change has no unresolved review issues.
Pull request overview
Updates Protobuf tools packaging to use the signed task assembly from bin instead of obj.
Changes:
- Packs the task DLL from
$(OutputPath). - Aligns with the Slice tools packaging convention.
File summaries
| File | Summary |
|---|---|
src/IceRpc.Protobuf.Tools/IceRpc.Protobuf.Tools.csproj |
Packages the task assembly from the bin output directory. |
Review details
- Files reviewed: 1/1 changed files
- Comments generated: 0
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
bernardnormier
left a comment
There was a problem hiding this comment.
Three things on the description.
Drop the last sentence: the 0.6.1 milestone is how we say a PR needs a backport.
It needs a What's Changed section, per the PR template: None — packaging fix, the task assembly is now signed like the other assemblies in the package.
Please file an issue for the unsigned first-party dependency copies in tools/ and link it from the description
instead of describing the gap here.
Fixes #4814
The release workflow signs the assemblies matching
src/<Project>/bin/Release/net*/<Project>.dlland then runsdotnet pack --no-build.IceRpc.Protobuf.Toolspacked its MSBuild task assembly from$(IntermediateOutputPath), sotasks/IceRpc.Protobuf.Tools.dllin the published package was the unsigned obj copy. This packs it from$(OutputPath)instead, asIceRpc.Slice.Toolsalready does.Verified locally: after a Release build, appending bytes to the bin copy (to stand in for signing) and running
dotnet pack --no-buildproduced a package whosetasks/dll matched the obj copy before this change and the bin copy after it.The unsigned first-party dependency copies in the Tools packages'
tools/folder are tracked in #4949.What's Changed entry
None — packaging fix, the task assembly is now signed like the other assemblies in the package.