Conversation
| 1. Copy all files from the previous step, including the application manifest file itself, to a temporary directory. | ||
| 1. Sign files in the following order: files alongside the application manifest, the application manifest itself, then the deployment manifest. | ||
| 1. Copy the files back. | ||
| 1. If the signed deployment manifest file is a `.vsto` file, copy it to the versioned application manifest file directory and overwrite if necessary. |
There was a problem hiding this comment.
I'm debating this. I feel like Sign CLI should not do this; Sign CLI should focus on signing, not emulating behaviors of a build-time task. Users who desire this behavior --- not just for .vsto files, but any ClickOnce app --- can do the copy after signing.
In trying to provide an equivalent experience to the VSTO build-time task, I think this will set up Sign CLI to do more non-signing-related chores. This is not a sustainable direction for Sign CLI.
There was a problem hiding this comment.
Since it's not called out, I wanted to mention that if you are taking an existing published application and signing it's manifest/binaries, the deployment manifest will have to be re-generated after signing the application manifest to update its assembly identity in the deployment manifest.
You can see it happening for ClickOnce apps here:
https://github.com/dotnet/msbuild/blob/014f3faab9cc9a5c3387d04190fbca51abac34e7/src/Tasks/Microsoft.Common.CurrentVersion.targets#L6336
| 1. Interate through both [`AssemblyReferences`](https://learn.microsoft.com/dotnet/api/microsoft.build.tasks.deployment.manifestutilities.manifest.assemblyreferences?view=msbuild-17-netcore) and [`FileReferences`](https://learn.microsoft.com/dotnet/api/microsoft.build.tasks.deployment.manifestutilities.manifest.filereferences?view=msbuild-17-netcore), manually resolve `TargetPath` property to the base path of the application manifest file. | ||
| * Note: it seems like calling `Manifest.ResolveFiles()` would resolve the full file path for every file dependency in the application manifest. However, this fails because `ResolveFiles()` assumes dependency files do not have `.deploy` file extension, but they do. We could temporarily remove the `.deploy` extension and then call `ResolveFiles()` but a user's glob patterns might filter out files based on the `.deploy` extension. The safest option is to resolve file paths ourselves. | ||
| 1. Copy all files from the previous step, including the application manifest file itself, to a temporary directory. | ||
| 1. Sign files in the following order: files alongside the application manifest, the application manifest itself, the deployment manifest, then `setup.exe`. |
There was a problem hiding this comment.
You can sign files programmatically using https://github.com/dotnet/msbuild/blob/a9d68ab58eab3c25b6378a90be8060dd1429a6ef/src/Tasks/ManifestUtil/SecurityUtil.cs#L552
dtivel
force-pushed
the
dtivel/clickonce-spec
branch
from
e9d0f84 to
608a5d3
Compare
4 participants
See #842.
This PR adds a specification for changes to the ClickOnce signing algorithm. The goal is to make ClickOnce signing simpler, more correct, more efficient, and easier to maintain over time.
Rendered view: https://github.com/dotnet/sign/pull/843/files?short_path=4b4a06c#diff-4b4a06c79e12d36a20f2eba719fd1d56a9634b06d678fe75561f05130209b48e
(The rendered view is best viewed in light mode, because the animated GIF, which you can see clearly here, does not display well in dark mode.)