dotnet
Sign many applications and manifestfiles in batch for click-once
Is your feature request related to a problem? Please describe. Cant sign many application-files in one batch. We have a setup where we have a *.application and *.manifest file per customer and we have about 100 customers. I would like to sign all files in one run.
Describe the solution you'd like When signing CustomerA.application file the program should look for a manifestfile named CustomerA.dll.manifest
Describe alternatives you've considered My workaround now is to temporary move customerA.application and customerA.dll.manifest to a temporary folder and sign them and them move them back.
Do you actually have a .manifest per customer, or just per-version of your application? We do something similar - with a .manifest for e.g. v1 of the app and another for v2, and then per-customer .application files with a unique update URL and that we configure to point to either v1 or v2 of the .manifest file.
I merged some changes to this tool a few weeks ago that should support signing multiple .application files but there's not been a release since then so you'd have to compile it yourself.
Yes we have 1 manifestfile for each customer, since we have an unique URL for each customer. I have compiled the latest code and run but fails with "Sequence contains more than one matching element" from \ClickOnceSignatureProvider.cs:line 130 which has a SingleOrDefault FileInfo? manifestFile = filteredFiles.SingleOrDefault(f => ".manifest".Equals(f.Extension, StringComparison.OrdinalIgnoreCase));
We are facing the same issue as @klamfeldt outlined as our solution contains multiple .manifest files in the same directory. The current implementation of the ClickOnceSigner assumes a single .manifest file which is pretty limiting and renders the sign tool unusable without having to implement some sort of workaround.
I've written #758 which should hopefully solve your problem. I've given it a test locally with a clickonce package that contains a the proper clickonce app manifest (MyApp.dll.manifest) as well as a separate .dll.manifest which isn't related to clickonce at all; it's just a regular windows manifest file and it worked fine.
For anyone with an app manifest (.dll.manifest/.exe.manifest) per customer though, I am curious why you need that because the URL isn't contained within those files - their contents depends only on the hashes of the binaries, so they should be 1:1 with versions of your application so unless you're actually building your app separately for each customer then you only need one app manifest per version, and you can construct however many deployment manfiests (.application) you need with different update URLs.
For anyone with an app manifest (.dll.manifest/.exe.manifest) per customer though, I am curious why you need that because the URL isn't contained within those files - their contents depends only on the hashes of the binaries, so they should be 1:1 with versions of your application so unless you're actually building your app separately for each customer then you only need one app manifest per version, and you can construct however many deployment manfiests (.application) you need with different update URLs.
We don't have a per customer manifest, but we originally planned on using a submodule and publishing directly into the submodule's directory. sign doesn't like seeing multiple .manifest files due to the multiple versions in a single directory as outlined in my issue #760. We developed a workaround that ended up working better for our deployment strategy anyways. I have not yet gotten a chance to try this change, but looking at the commits, I'm not sure it would address this issue as the manifests are all still named the same.
