Sign many applications and manifestfiles in batch for click-once

[klamfeldt]

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.

[jackmtpt]

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.

[klamfeldt]

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));

[ottD]

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.

[jackmtpt]

I think I can put together a fix for this.

[jackmtpt]

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.

[MH-ZShearer]

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.

[dtivel]

@klamfeldt, @ottD, @MH-ZShearer, can you help me visualize the file/directory structure for your unsigned ClickOnce applications? I'm imagining it's something like this:

App1.application
App2.application
App3.application
...
    Application Files
        App1_1_0_0_0
            App1.application
            App1.exe.config.deploy
            App1.exe.deploy
            App1.exe.manifest
        App2_1_0_0_0
            App2.application
            App2.exe.config.deploy
            App2.exe.deploy
            App2.exe.manifest
        App3_1_0_0_0
            App3.application
            App3.exe.config.deploy
            App3.exe.deploy
            App3.exe.manifest
        ...

[ottD]

@dtivel Thanks for following up. In our case, we have several VSTO add-ins for extending Word, Excel and PowerPoint in the same directory. They are in the same directory because we are essentially building the same add-in for different Office applications. So the file /directory structure is something like this:

    Output 
        myAddin.Word.dll
        myAddin.PowerPoint.dll
        myAddin.Excel.dll

        myAddin.Word.vsto
        myAddin.PowerPoint.vsto
        myAddin.Excel.vsto

        myAddin.Word.dll.manifest
        myAddin.PowerPoint.dll.manifest
        myAddin.Excel.dll.manifest

[MH-ZShearer]

Ours is just a basic ClickOnce example with a simple version bump, outputting to the same directory again. An example is:

App.application
    Application Files
        App_1_0_0_0
            App.dll.deploy
            App.dll.manifest
            App.exe.deploy
            ...
        App_1_0_1_0
            App.dll.deploy
            App.dll.manifest
            App.exe.deploy
            ...
        ...
...

We do not have an .application file within our version directories, just the primary application manifest in the root directory. This use case is what we have on our local servers for backup purposes. There have been times when App_1_1_0_0 existed on the server, but due to a roll back, App_1_0_9_0 was the latest version, for example.