You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A complicated implementation with several edge cases. Also, it will only be useful for developers or publishers who can afford a code-signing certificate. Nuget.org only allows signed packages if they are signed by one of their trusted root authorities.
It may be preferable to instead encourage users to use an "AfterTargets"="Pack" target to sign packages...
Parameters/Types for this function would need to be
Notable Edge Case: multiple keys, multiple registries, one package ID
This is highly unusual, but may be employed in highly unusual enterprise environments. I suggest dotnet pack ${projectPath} --output ${PackageOutputDirectory}/${SourceName}/${PackageId} so you don't need to parse file names.
Create package A
Sign package A with private key A
Push signed package to registry A
Recreate package A (clean slate so we don't sign an already-signed package) -OR- Recreate package with different output dir
Sign package A with private key B
Push signed package to registry B
The text was updated successfully, but these errors were encountered:
Alternatively, users can wrap package signing with an MSBuild Task and a Target that runs after Pack e.g. <Target Name="SignNupkgAfterPack" AfterTargets="Pack">
In fact, this is probably preferable. If something related to .NET MSBuild can be done without leaving the .NET MSBuild system, it probably should be done there.
A complicated implementation with several edge cases. Also, it will only be useful for developers or publishers who can afford a code-signing certificate. Nuget.org only allows signed packages if they are signed by one of their trusted root authorities.
It may be preferable to instead encourage users to use an
"AfterTargets"="Pack"
target to sign packages...Parameters/Types for this function would need to be
Notable Edge Case: multiple keys, multiple registries, one package ID
The text was updated successfully, but these errors were encountered: