mansellan / clickonce Goto Github PK
View Code? Open in Web Editor NEWClickOnce packager
License: Other
ClickOnce packager
License: Other
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
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.
Probably with GitHub Actions.
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.
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`
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.
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.
Will probably need to wind back on the statics :-)
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!
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
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.
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,
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.
Is there any chance to get support for net 5.0 and 6.0?
Similar to Mage, allow existing manifests to be updated:
clickonce update --createdesktopshortcut=true --version=1.0.1.0
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?
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:
(to be incorporated into existing inference strategy)
Provide an analogue of the "Publish" option from Visual Studio, which sources arguments from:
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.
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.
Provide a VSIX extension to Visual Studio, and publish to the Visual Studio Marketplace
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 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.
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.
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.
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.
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
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:
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.
Visual Studio allows auto-generation of an autorun.inf file, for CDROM based installations.
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.
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.
Currently, when selecting both prerequisites and signing, the setup.exe installer is left unsigned (only the manifests are signed).
Provide a VSIX extension to Azure DevOps Deploy Pipelines, and publish to the Visual Studio Marketplace
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
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)
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:
Can you add .net 5 to the supported framework versions?
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;
Undecided whether or not the resultant MSBuild warnings should be filtered from the log (perhaps show them only on Verbose logging?)
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.