mansellan/clickonce

ClickOnce packager

ClickOnce packager

Create ClickOnce packages with minimal fuss.

Why?

ClickOnce was introduced with .Net Framework 2.0, providing an easy way for users to install desktop applications and automatically update them. Since then, Microsoft have created several replacements, such as AppX and MSIX. These have incrementally made life easier for developers and modernised the user experience. Unfortunately they have also become progressively more sandboxed, limiting the capabilities available to application developers.

MSIX is a great technology, and you should use it if possible. Unfortunately it comes with a huge list of restrictions, many of which cannot be avoided even in trusted, domain-managed environments. It also has limited support for older Windows versions. The MSIX Core project is attempting to bridge this gap, but only for currently supported OSs (Windows 7 and 8.1), and without support for application updates. By contrast, ClickOnce is supported everywhere that .Net 2.0 onwards is supported, from Windows 98 (yes, really!) through to Windows 10.

Until there is a complete replacement for for ClickOnce it remains worthwhile supporting this solid and reliable platform, and making it available to modern development environments.

At a glance

• Globbing
• Create ClickOnce packages from SDK projects, native executables and .Net Core applications
• Able to infer most settings, while retaining full override control
• Easier and more configurable than Mage
• Compatible with modern CI platforms
• Localisable help

Getting started

I'm hoping to get this published as a global tool (see #9), but until then you'll have to build it from source and put it onto your PATH variable.

Note that the command acts upon compiled files only, hence you will need to build your application and navigate to the output folder to create a ClickOnce package.

Example

C:\MyApp\bin\debug> clickonce create --version=1.0.0.0

Verbs

The following verbs are supported:

Verb	Description
Create	Creates a new ClickOnce package from scratch
Help	Gets help information
Version	Gets version information

More verbs are planned, for example to update existing manifests or build from project files. Watch this space!

Arguments

Copious arguments are available to take full control of manifest generation, listed below. However, it's not necessary to set all of them explicitly, as almost all of them can be inferred from other sources.

Argument	Description
Source	Specifies the base directory for all source globbing patterns. If not specified, defaults to the current directory.
Target	Specifies the directory to which ClickOnce packages will be published. If a relative path is specified, it will be relative to the Source directory. This directory will be automatically excluded from all source globbing patterns. If not specified, defaults to 'publish'.
Identity	Specifies the identity of the application. This is used for the application and deployment manifest file names and the package folder name. If not specified, a name is inferred from the EntryPoint.
Product	Specifies the name of the product. This name is used for the shortcut name on the Start menu and is part of the name that appears in the Add or Remove Programs dialog box. If not specified, defaults to the Name.
Version	Specifies the version of the deployment. This need not be (and usually isn't) the same as the version of the application. Must be a dotted version number with 1 to 4 elements, each less than 63356. If not specified, the version number of the EntryPoint is used.
Suite	Specifies the name of the suite to which the application belongs. If specified, this determines the folder on the Start menu where the application is located after deployment.
Publisher	Specifies the publisher of the application. This name is used for the folder name on the Start menu and is part of the name that appears in the Add or Remove Programs dialog box. If not specified, a publisher is inferred from the EntryPoint.
Description	Specifies a description for the application.
EntryPoint	Specifies the application assembly that starts when the application is run. Must be an .exe file. If this is not a .Net Framework assembly, a launcher must be used via the UseLauncher option. If not specified, the source directory is recursively searched for .exe files. If exactly one is found, it will be assigned to be the entry point.
IconFile	Specifies the application icon file. This is used for the Start Menu and Add/Remove Programs dialog. Must be an .ico file. If not specified, the source directory is recursively searched for .ico files. If exactly one is found it is used; othewise, a default icon is used.
PackagePath	Specifies the path under the Target where the application package will be created. This should incorporate the Version number so that multiple versions can be published. If not specified, a value is inferred from the EntryPoint, e.g. 'Application Files/MyApp_1_0_0_0'.
ApplicationManifestFile	Specifies the name of the application manifest file. Must be a valid file name, and should use a .manifest extension. If not specified, a name is inferred from the EntryPoint, e.g. 'MyApp.exe.manifest'.
DeploymentManifestFile	Specifies the name of the deployment manifest file. Must be a valid file name, and should use an .application extension. If not specifed, a name is inferred from the EntryPoint, e.g. 'MyApp.application'.
Platform	Specifies the target platform of the application. Must be one of 'AnyCPU', 'x86', 'x64', 'Itanium'. If not specified, the target platform will be inferred from the EntryPoint. Note, setting this value can cause ClickOnce validation errors if the specified value does not match the entry assembly, therefore it is recommended to leave this option unset.
Culture	Specifies the culture of the application. Must be 'neutral' or a valid culture (e.g. 'en-GB'). If not specified, the culture of the EntryPoint is used.
OsVersion	Specifies the minimum required operating system (OS) version required by the application. For example, the value '5.1.2600.0' indicates the operating system is Windows XP. Must be a dotted version number with 2 to 4 elements. The first 2 elements must match a known Windows version (e.g. '6.0' for Windows Vista). If not specified, the value is inferred from the TargetFramework.
OsDescription	Specifies a description of the OsVersion. If not specified, a value is inferred from the OsVersion.
OsSupportUrl	Specifies a support URL for the OsVersion. Must be a valid and absolute URI (a URL or a UNC).
TargetFramework	Specifies the target framework of the application. Only .Net Framework targets net20 through to net48 are valid. Must be a net framework from 'net20' onwards. If not specified, defaults to 'net472'.
Assemblies	Specifies a colon-separated list of globbing patterns to match assemblies to be included. Will only consider managed assemblies, hence a pattern of *.dll will exclude native libraries.
Files	Specifies a colon-separated list of globbing patterns to match non-assembly files to be included.
DataFiles	Specifies a colon-separated list of globbing patterns to match data files to be included. These files are considered mutable, and can be migrated between application versions.
UpdateUrl	Specifies the deployment and update location for the application. Required if target framework is prior to net35 and UpdateMode is any value other than 'none'. Must be a valid and absolute URI (a URL or a UNC). If not specified, defaults to 'net472'.
ErrorUrl	Specifies the URL of the web page that is displayed in dialog boxes during ClickOnce installation. Must be a valid and absolute URI (a URL or a UNC).
SupportUrl	Specifies the URL of the web page that is displayed in the Add or Remove Programs dialog box for the application. Must be a valid and absolute URI (a URL or a UNC).
PackageMode	Specifies which manifests to create. Must be one of 'none', 'application', 'deployment', 'both'. If 'none', only validation of supplied arguments is performed. If not specified, defaults to 'both'.
LaunchMode	Specifies whether the application can be launched from the Start menu, from a URL, or both. Also allows browser-hosted deployments (Internet Explorer only). Must be one of 'start', 'url', 'both', 'browser'. If not specified, defaults to 'both'.
UpdateMode	Specifies how application updates should be deployed. Must be one of 'none', 'starting', 'started', or a number of hours, weeks or days (e.g. '1w'). Only one unit can be specifed, and the interval cannot describe more than 1 year, regardless of unit. If not specified, defaults to 'none'.
MinimumVersion	Specifies the minimum version the user must update to when starting the application. Has no effect is LaunchMode is 'url' or UpdateMode is 'none'. Must be a dotted version number with 1 to 4 elements, each less than 63356. Must be equal to or lower than Version. If not specifed and UpdateMode is not 'none', defaults to Version.
TrustUrlParameters	Boolean. Specifies whether URL query-string parameters should be made available to the application. Has no effect if LaunchMode is 'start'. If not specified, defaults to false.
UseDeployExtension	Boolean. Specifies whether the .deploy file name extension mapping is used. If this parameter is true, every program file is published with a .deploy file name extension. This option is useful for web server security to limit the number of file name extensions that must be unblocked to enable ClickOnce application deployment. If not specified, defaults to false.
UseLauncher	Specifies whether or not a launcher should be created. If 'auto', a launcher will be created if the EntryPoint is not a .Net Framework executable. Must be one of 'true', 'false', 'auto'. If not specified, defaults to 'auto'.
CreateDesktopShortcut	Boolean. Specifies whether a shortcut to the application should be added to the user's desktop'. Has no effect if LaunchMode is 'url'. If not specified, defaults to false.
CreateAutoRun	Boolean. Specifies whether or not to create an autorun.inf to launch the ClickOnce installer when deployed to removable media. If not specified, defaults to false.
UseApplicationTrust	Boolean. Specifies which manifest should be used for trust decisions. If true, the Product, Publisher, and SupportUrl properties are written to the application manifest; otherwise, they are written to the deployment manifest. If not specified, defaults to false.
Quiet	Boolean. Displays only minimal information when the ClickOnce package is built. If not specified, defaults to false.
Verbose	Boolean. Displays extra information when the ClickOnce package is built. If not specified, defaults to false.
Help	Display a help screen.

Future

This is a fairly contained problem domain, limited explicitly by the ClickOnce manifest reference. If it's not supported in the manifest, it's not supported by ClickOnce. My aim is to support all edge-cases and (most) conveniences provided by Visual Studio, to provide a complete migration path for existing ClickOnce users. I think the issues list represents most of what's needed to achieve this.

I also hope to create a UI and CI pipeline integrations for Visual Studio, Azure DevOps and perhaps others.

Thanks

• CommandLineParser My life would have been much more complicated without you.
• Microsoft extensions, particularly Globbing and Options.

clickonce's Issues

Azure pipeline

Hi, great work!

I'm using it on azure pipeline and there's something weird going on. The version of the publish.htm file is always set to the assembly version, not the application being published version. Maybe I'm doing something wrong. Below is part of the code of my pipeline:

`variables:
Solution: '**/*.sln'
BuildPlatform: 'Any CPU'
Version: '1.0.0.$(Build.BuildId)'

steps:

• task: NuGetToolInstaller@1

• task: NuGetCommand@2
  inputs:
  restoreSolution: '$(Solution)'

• task: DownloadSecureFile@1
  inputs:
  secureFile: 'Certificado.pfx'
  displayName: 'Download Secure PFX File'

• task: MSBuild@1
  inputs:
  solution: '$(Solution)'
  msbuildArchitecture: 'x64'
  configuration: 'Release'
  platform: '$(BuildPlatform)'
  msbuildArguments: '-p:target=publish -p:ApplicationVersion="1.0.0.$(Build.BuildId)" -p:AppxPackageSigningEnabled=false -p:OutputPath="$(build.ArtifactStagingDirectory)\Publish\"'

• task: clickonce@1
  inputs:
  source: '$(build.ArtifactStagingDirectory)\Publish'
  entryPoint: '$(build.ArtifactStagingDirectory)\Publish\GerenciadorArquivos.exe'
  target: 'publish'
  version: $(Version)
  description: 'Gerenciador de arquivos do Planck para o Escolando'
  product: 'Gerenciador de Arquivos Planck'
  publisher: 'Escolando'
  launchMode: 'start'
  iconFile: '$(build.ArtifactStagingDirectory)\Publish\logo.ico'
  deploymentUrl: 'https://arquivosplanck.blob.core.windows.net/apps/GerenciadorArquivos'
  targetFramework: 'net472'
  signingMode: 'file'
  certificate: 'Certificado.pfx'
  certificatePassword: 'xxx`

Allow autorun.inf

Visual Studio allows auto-generation of an autorun.inf file, for CDROM based installations.

Allow manifest signing

In the real world, ClickOnce manifests are of limited use if they are not signed. Best-case is a warning dialog, worst-case is installation failure. Currently, manifests are hashed but not signed.

Options:

• SignTool
• Mage
• Hand-rolled

Allow manifest merging

ClickOnce does some magic with manifests. In Visual Studio, if a project is configured to use an embedded manifest, the publish system intercepts it, merges some of it with the ClickOnce manifest it is creating, then suppresses it from being embedded in the executable.

As this project works with compiled files, this approach is not possible. Indeed, if an executable with an embedded manifest is packaged, it will likely fail to install as there is likely to be a mismatch between the embedded and external application identities.

To solve for this, the entry point should be examined for an embedded manifest. If one is found, its contents should be merged with the ClickOnce manifest and then the embedded manifest should be removed. This is likely non-trivial, and would also break any executables that incorporate tamper detection :/

On the way to a full solution, perhaps the embedded manifest could be detected and fail the package with an error.

Package Version in Azure DevOps

Hi,

I'm using this extension to generate clickonce package and it works very well, however I have a trouble.

I need to set up the version on each release. I tried to use the classic artifacts variable $(Release.ReleaseId), it would be enougth. The problem is that it's not working!

I used the same pattern to see the version in the Display Name field and it workd properly. Why it does not work in the Version field?

See below the evidences:

Please if you can help me I thank you!

Regards

Integrate with Azure DevOps

Provide a VSIX extension to Azure DevOps Deploy Pipelines, and publish to the Visual Studio Marketplace

Entry point Parameter under Application File Section in Gui eats 6 chars in the begining of the value

If I just put entrypoint in the gui interface to : StockSys.Client.App.exe
Then in the command line i get and error, and when i check what was passed along to the command line i find out that it is:
--entryPoint ockSys.Client.App.exe

So in reality i have to type the first 6 chars twice to fix this issue, i dont think that is how you intended this to work ?

Here you see the value i am typing in:

And then it runs fine.

Implement CI

Probably with GitHub Actions.

.net 5?

Can you add .net 5 to the supported framework versions?

Sign prerequisites installer (setup.exe)

Currently, when selecting both prerequisites and signing, the setup.exe installer is left unsigned (only the manifests are signed).

Allow optional groups

ClickOnce allows files to be assoicated into optional download groups. Such files are not downloaded at installation, they are optionally downloaded at runtime using the ClickOnce API. They are typically used for optional features and language packs.

Given the age of ClickOnce, it's possible that this feature is not widely used. Until commented otherwise, considered low prioirty.

Allow named and custom TrustInfo

One of the required elements of a ClickOnce application manifest is TrustInfo. This allows fine-grained control of trust settings, with convenience shortcuts for the following templates:

• Full Trust
• Partial Trust
  • Internet
  • Intranet
  • Custom

We should be able to accomodate all except Custom as named arguments, and accomodate Custom by reference to a trust XML file. Currently we just instantiate a new TrustInfo class, which defaults to full trust.

Allow parameters and environment variables when using launcher

ClickOnce does not natively allow parameters or process-level environment variables to be passed to the entry point. However, this limitation need not apply when using a launcher.

Allow prerequisites

ClickOnce application manifest allow Prerequisite assemblies (DependencyType=prerequisite). Such assemblies are required to be present in the user's GAC before the ClickOnce deployment is permitted. Ordinarily, this is limited to a (mandatory) entry for the CLR (either v2 or v4).

In Visual Studio, the Pre-requisites button allows the user to create a Setup.exe, which installs selected prequisites and then invokes the ClickOnce deployment manifest. The Setup.exe is not part of ClickOnce, it's provided as a convenience to Visual Studio developers. It also does not affect the ClickOnce dependency collection, rather, it pre-empts it.

Not proposing to replicate creation of a Setup.exe, that would be extremely complex (the source is proprietary). Rather, to consider allowing prerequisites to be declared in the application manifest, as per the original ClickOnce schema intention. This would act as a backstop to prevent dependancy failures.

Users could then create a Setup.exe from Visual studio, and include it in the globbing patterns for files to replicate VS behaviour.

Publish as a global tool to NuGet.org

Publish a global tool to NuGet.org, such that users can install from the command line:

dotnet tool install -g clickonce

Note, this only works for .Net Core assemblies, so will likely need to wrap with a netcore console app.

Implement workaround for strong-named .Net Core assemblies

ClickOnce seems to have a problem verifying the identity of strong-named .Net Core assemblies, which can cause application validation to fail at install time. A workaround is to add such assemblies as files, rather than assemblies. This causes MSBuild to emit warnings when creating the application manifest, but these seem to be harmless.

This workaround currently requires manual intervention, but could be automated:

For all assemblies;

1. Identify whether it is .Net Core, if so
2. Check whether strong-named, if so
3. Add as a file rather than an assembly, with an appropriate log message.

Undecided whether or not the resultant MSBuild warnings should be filtered from the log (perhaps show them only on Verbose logging?)

Azure devops Clickonce package task not working in my release pipeline with virtualmachine as environment. But worked in build pipeline where azure pipelines is my agent. I used same steps as mentioned for clickonce task. Help me how to solve

I have created Build pipeline for .net in azure dev

In Windows Virtual machine this will deploy. using environment section.
steps:

• task: DownloadBuildArtifacts@1
  inputs:
  buildType: 'specific'
  project: '6dec2f04-2e6f-4691-b194-a9d1741f8e9a'
  pipeline: '484'
  buildVersionToDownload: 'latest'
  downloadType: 'specific'
  downloadPath: '$(System.ArtifactsDirectory)'

• task: clickonce@1
  inputs:
  source: '$(System.ArtifactsDirectory)\ac_drop\bin\Release'
  target: '$(System.ArtifactsDirectory)\ac_drop\bin\Release\publish'
  product: 'Apex Corp'
  version: '${{parameters.version}}'
  publisher: 'Logistics'
  launchMode: 'start'
  deploymentUrl: 'https://apps.com/Corporate'
  targetFramework: 'net462'
  prerequisitesMode: 'vendor'
  prerequisite1: '.NETFramework,Version=v4.6.2

Getting error like
C:\azagent\A1_work_tasks\clickonce_540cd748-7752-4245-936d-d18d292a1000\1.1.1\bin\ClickOnce.exe create --source C:\azagent\A1_work\1\a\ac_drop\bin\Release --target C:\azagent\A1_work\1\a\ac_drop\bin\Release\publish --deploymentUrl https://apps.com/Corporate --product "Apex Corp" --version 5.6.5.0 --publisher "Logistics"
--deploymentPage publish.htm --prerequisitesLocation vendor --prerequisites .NETFramework,Version=v4.6.2
##[debug]Exit code 2148734720 received from tool 'C:\azagent\A1_work_tasks\clickonce_540cd748-7752-4245-936d-d18d292a1000\1.1.1\bin\ClickOnce.exe'
##[debug]STDIO streams have closed for tool 'C:\azagent\A1_work_tasks\clickonce_540cd748-7752-4245-936d-d18d292a1000\1.1.1\bin\ClickOnce.exe'
##[debug]task result: Failed
##[error]The process 'C:\azagent\A1_work_tasks\clickonce_540cd748-7752-4245-936d-d18d292a1000\1.1.1\bin\ClickOnce.exe' failed with exit code 2148734720
##[debug]Processed: ##vso[task.issue type=error;]The process 'C:\azagent\A1_work_tasks\clickonce_540cd748-7752-4245-936d-d18d292a1000\1.1.1\bin\ClickOnce.exe' failed with exit code 2148734720
##[debug]Processed: ##vso[task.complete result=Failed;]The process 'C:\azagent\A1_work_tasks\clickonce_540cd748-7752-4245-936d-d18d292a1000\1.1.1\bin\ClickOnce.exe' failed with exit code 2148734720

BUT in build it worked. where we have used Azure pipelines and agents. Please help me in this

Allow non-netfx entry points

ClickOnce was designed to deploy managed assemblies, at a time when "managed" meant .Net Framework.

However, that only applies to the application entry point. It is capable of deploying any kinds of file, including native DLLs and .Net Core assemblies. The only requirement is that the entry point targets netfx.

This leads to the possibilty that native and netcore "entry" points can be accomodated by using a netfx launcher app.

Ideally, the entry point should be examined to see if it's netfx. If not, a simple launcher app should be emitted which uses Process.Create to spawn the actual entry point. This requires and imples full tust,

Integrate with Visual Studio

Provide a VSIX extension to Visual Studio, and publish to the Visual Studio Marketplace

Support updating of existing manifests

Similar to Mage, allow existing manifests to be updated:

clickonce update --createdesktopshortcut=true --version=1.0.1.0

Allow file associations

ClickOnce applications allow file associations to be registered, such that files of a given extension associate with the deployed application.

This should be accommodated, with the potential complexity that it may be difficult to express at the command line.

Implement unit tests

Will probably need to wind back on the statics :-)

[Question] build coomand to generate vsix

Hi I need to use clickonce in a provate Azure DevOps instance, and I'd like to author the vsix package. What command do you use to generate the vsix package?

Allow SHA-256 hashing

The hashing algorithm selected by the manifest generation API is driven by the target framework. Curently we coerce this to ensure SHA-1, as SHA-256 leads to malformed hashes. This should be addressed.

Support promoting earlier versions

Allow earlier packaged versions to be easily promoted to current:

clickonce promote --sourceVersion=1.0.0.0 --version = 1.1.0.0

Will scan for version 1.0.0.0, copy its application package and reversion it to 1.1.0.0, and update the deployment manifest to point to it.

Support configurable defaults

Allow defaults to be set from the command line:

clickonce configure create --publisher="Acme Ltd" --supportUrl=https://support.acme.com

The initial version stores defaults in a json file, we should make this configurable from the command line. Also, it should be possible to list configured defaults by not specifying any arguments, e.g.:

clickonce configure create

Multiple deployments of same build can fail to install

Manifest identities are unique per machine, and compromise the identity name, version and culture. Moreover, a given application manifest cannot be referenced by more than one deployment manifest. If this rule is violated, only the first deployment to be installed will succeed. This can cause problems in multi-environment settings, where the same entry point assembly may be deployed into several environments (e.g. moving a deployment version from Test to QA to Production).

The application manifest name is arbitrary (it need not equal the entry point assembly name), therefore to resolve this, the inferred application manifest identity should include, at a minimum, in priority order:

1. Identity name (advanced setting, infrequently set)
2. Product name (likely to include environment in multi-environment settings)

(to be incorporated into existing inference strategy)

Create a standalone UI

Provide a standalone UI, similar in functionality to MageUI and Visual Studio, and make it available on GH.

Labelling this an an integration, because the implementation process is identical (wrap the core with a UI)

Using Github as update location in ClickOnce

Hi, so I created a simple app versioned 1.0.0.0 and published it to a local path via clickonce and set the update location to a github repository. Now I've made changes to the app and it is now versioned 1.0.0.1. I've uploaded the updated files of the app (Version 1.0.0.1) to a public Github repository. I have installed Version 1.0.0.0 on my PC and now when opening it, it throws an error saying that:
Following errors were detected during this operation.

• [08-01-2022 08:42:23] System.Deployment.Application.InvalidDeploymentException (ManifestParse)

• Exception reading manifest from https://github.com/MyTechApplications/MyPC/blob/main/MyPCInfo.application: the manifest may not be valid or the file could not be opened.
  Kindly help!

Support single character parameter aliases

ERROR: An error occurred signing the manifest. Check that all signature parameters are correct.

We have an issues that is not possible to reproduce.

Once in a while we get an error thrown. "ERROR: An error occurred signing the manifest. Check that all signature parameters are correct"

The thing is that the parameters are correct and the same as the previous build that worked.

Any suggestions ?
Best regards
Marcus Pettersson

Unable to create package if multiple .exe files exist even if entry point specified

I set argument --entryPoint, but I get bug 'Unable to infer entry point, multiple .exe files found' anyway. I determined entryPoint in input parameters.. --entryPoint OdipDesktop.exe

In devOps I get the same error

Could you help me with this Issue

[Question] How to avoid duplicated .exe.application and .exe.manifest

Hi,
I'm using ClickOnce Packager Task on a CI/CD pipeline. Thing is that after I build on a VM via agent I upload the deployment files to blob storage. This I've been doing for years now but using MSBuild to publish and not just build. Thing is, with ClickOnce Packager I can see two manifest files and two exe. [name].application and [name].application.deploy, [name].manifest.exe and [name].manifiest.exe.deploy
In the old way of doing things, the option to add .deploy to files is checked and the only two files after publishing that do not contain such extension are .application and exe.manifest. But using Packager adds the replication as stated above. Any ideas what I'm doing wrong or what could it be? Thanks before hand!

TimestampUrl is an invalid URL when this argument is empty

Hello... Thanks for this greate AzureDevOps extension.

I've a problem when using a certificate with a Thumbprint, but without Timestamp URL.
I've received an error Error setting value to option 'timestampurl': Invalid URI: The format of the URI could not be determined. because the argument --timestampUrl is set.

Can you remove this parameter if the timestampUrl is empty?

Thanks

Find here the Yaml used.

steps:
- task: mansellan.clickonce.clickonce-task.clickonce@1
  displayName: 'ClickOnce Package'
  inputs:
    source: '$(System.DefaultWorkingDirectory)/drop'
    target: '$(System.DefaultWorkingDirectory)/Publish'
    product: 'MyProduct'
    version: '$(Build.BuildNumber)'
    publisher: MyCompany
    createDesktopShortcut: true
    deploymentUrl: 'https://mywebsite.net/'
    targetFramework: net48
    prerequisitesMode: vendor
    prerequisite1: '.NETFramework,Version=v4.8'
    signingMode: installed
    thumbprint: 84599cec4d8b0d567b819a3eb75a100749b8f155
    verbosity: verbose 

Allow HTML page generation

Visual Studio offers a simple checkbox option to generate an HTML page in the target folder, which links to the installer and setup files. This is not part of ClickOnce, but offered as a convenience to Visual Studio developers.

It would be easy enough to replicate this, with additional templating to adjust the generated HTML. This could be of benefit to developers looking to direct their users to an intuitive installation web page.

Allow --noInfer flag to prevent parameters being inferred

It's possible one might wish not to have any value inferred, instead requiring explicit values to be supplied. Add a flag to allow this. Might need #24 to be completed first.

Azure devops task deleting secure file is causing problems with launcher signing

I've been using the clickonce packager tool and Azure Devops task template for a few months now. So far it's been an absolute lifesaver when we were struggling to move from publishing our application (directly) in Visual Studio to CI/CD with Azure.

The problem we're currently experiencing is as part of a proof of concept to move from .NET Framework 4.8 to .NET6/7.
In theory, we should be able to use a launcher to deploy a .NET 6/7 application but we have encountered a security related issue. Our environment requires all exes to be signed. The issue is that although we have signed our application (and similarly sign the manifests for ClickOnce), the launcher is not signed and is therefore blocked.

We had planned to sign the launcher after the package is generated but the the clickonce packager deletes the certificate (downloaded as a secure file) after the package is generated.

Our packaging task is set up as follows (for reference)
- task: clickonce@1 displayName: Create ClickOnce Package inputs: source: '$(ClickOnceSource)' target: '$(ClickOnceTarget)' product: '$(Product)' version: '$(GitVersion.AssemblySemVer)' publisher: '$(clickOnce.Publisher)' launchMode: 'start' deploymentUrl: '$(DeploymentUrl)' targetFramework: 'net48' entryPoint: '$(WindowsAssemblytoSign).Launcher' iconFile: '$(IconAndPathForClickOnce)' signingMode: 'file' certificate: '$(innitechCertificate.secureFilePath)' certificatePassword: '$(innitechCertificate.password)' timestampUrl: '$(innitechCertificate.TimestampUrl)' useLauncher: 'true' verbosity: 'verbose'
Most of the values are set by pipeline variables, but are included to show which options we are using for packaging.

So because secure files can't be re-downloaded we appear to have no way to sign the launcher. Possible solutions could be:

1. Make deleting the secure file optional, or remove this entirely as the file is deleted automatically when the pipeline job completes
2. Integrate signing of the generated launcher as part of the task

Allow Reg-Free COM

ClickOnce allows installation of dependant COM components without system-wide registration, using Reg-Free COM. This requires that the relevant interface IDs be discernable, either from the registry of the build machine or as manifest files.

Enhance project validation

There is a project validation stage already, but it only includes a few basic checks. Need to go through the MSB source to find the conditions for vairous failure conditions and add them to the project validator.

Support for net50 and 60

Is there any chance to get support for net 5.0 and 6.0?

Support publishing of existing projects

Provide an analogue of the "Publish" option from Visual Studio, which sources arguments from:

1. Command-line arguments
2. Build files (.csproj/.vbproj/.publish*)
3. Configured defaults
4. Inferred

clickonce publish --PublishFile=MyApp.csproj --version=1.1.0.0

This should ideally work even with new-style SDK projects. Either by adding the "old" ClickOnce properties to them or by extracting them into a seperate "publish" file, following the same MSBuild format.