ClickOnce Support for .NET Core

[nakarnam]

Objective

Provide ClickOnce Support for .NET Core apps in the .NET 5 timeframe i.e. the ability for .NET Core apps to auto update on launch. This brings functional parity across most of the ClickOnce scenarios for the developer community, particularly those in Enterprise/Line of business.

High level User Experience and Scope

Developer experience includes an updated integrated publish experience in VS with ClickOnce as a new provider option, a new open sourced Mage tool for enabling the command line experience for manifest generation and updated MSBuild tasks to support the changes required in VS and Mage for .NET Core Projects.

At a high level, the proposal is to use a .NET Framework based launcher application, transparent to the user and responsible for activating the .NET Core app specified in the launcher’s config/manifest file. There are no changes expected to the OS components that ClickOnce Runtime relies on, such as Dfshim, DFSVS etc.

Please note that ClickOnce ApplicationDeployment class and its APIs will not be available for use by .NET Core applications. For example, downloading assemblies at will and Custom hosting – InPlaceHostingManager scenarios are not supported. Also, scope does not include support for in-app updates or updates upon app close since the launcher app closes once the .NET Core app is activated. Partial trust is not a supported feature in .NET Core, therefore not in scope.

Windows 7 is not a supported platform. However, Win 7 users with .NET 4.5.2+ will not be blocked from using ClickOnce for deploying .NET Core apps.

[billybednar]

Please note that ClickOnce ApplicationDeployment class and its APIs will not be available for use by .NET Core applications.

That's a bit disappointing. The standard update check has behavior that's problematic in our environment (silently continuing if the update check failed) and we use the CheckForUpdate API to supplement it. We just need the boolean result (or exception) and don't actually need to trigger the update. If it's not possible to include at least a subset of the ApplicationDeployment class, perhaps there could be a way to specify a custom launcher application.

What about URL parameters, specifically for file associations? The launcher could translate AppDomain.CurrentDomain.SetupInformation.ActivationArguments.ActivationData into command line arguments.

[NikolaMilosavljevic]

Please note that ClickOnce ApplicationDeployment class and its APIs will not be available for use by .NET Core applications.

That's a bit disappointing. The standard update check has behavior that's problematic in our environment (silently continuing if the update check failed) and we use the CheckForUpdate API to supplement it. We just need the boolean result (or exception) and don't actually need to trigger the update. If it's not possible to include at least a subset of the ApplicationDeployment class, perhaps there could be a way to specify a custom launcher application.

What about URL parameters, specifically for file associations? The launcher could translate AppDomain.CurrentDomain.SetupInformation.ActivationArguments.ActivationData into command line arguments.

We are tracking work to add support for URL parameters.

I understand that failure in update check, before app launch seems to be ignored today. @billybednar what are the common reasons for failures in update check in you environment?

[billybednar]

I understand that failure in update check, before app launch seems to be ignored today. @billybednar what are the common reasons for failures in update check in you environment?

Server issues, not being connected to the network, and the deployment being deleted. The first two typically aren't a big deal since they're temporary, but in some cases a warning or other action is desirable. The removal of deployments, typically betas, is our real problem because it leaves behind installations that appear to be getting updates but aren't really. The ApplicationDeployment class allows us to detect an update failure, classify it as temporary or permanent, and provide a response appropriate for the application.

[NikolaMilosavljevic]

The removal of deployments, typically betas, is our real problem because it leaves behind installations that appear to be getting updates but aren't really. The ApplicationDeployment class allows us to detect an update failure, classify it as temporary or permanent, and provide a response appropriate for the application.

I see - you are doing silent updates. ApplicationDeployment class is not available in .NET (Core). But, Launcher could do the update check and, in some way, communicate the result to the application. We'll take a look at this and come up with the solution - I've created an issue for this: #27

[wjk]

One question, although I don't think it would be possible to achieve in the near future. As I understand it, ClickOnce installations always prompt the user to click a button during removal, with no way to suppress it. This has resulted in projects like this one needing to exist. Is there any way we could work around this? This issue precludes being able to uninstall ClickOnce-packaged applications using automated scripts in mass deployments. (I don't think it precludes inclusion in winget, however, as winget does not yet offer the feature of completely silent removals AFAICT.) Thanks!

[NikolaMilosavljevic]

@wjk unfortunately there is no way to uninstall applications silently without writing a custom application to wrap uninstallation process and send keys to accept the dialog prompt. Project you linked works differently and imitates ClickOnce uninstall actions by deleting files and registry keys. I have not investigated it closely and cannot endorse it.

[wjk]

@NikolaMilosavljevic That's fine. Just wanted to throw it out there. Besides, I always install my apps with /passive rather than /quiet, so I’m used to dealing with popups. 😄 Thanks anyway!

[mansellan]

I recently wrote an open-source project to do this, with a very similar modus operandi - when a net core executable is detected, it creates a netfx launcher (albeit without any finesse wrt parameters). I also wrapped it as an Azure DevOps pipeline task.

In doing so, I noticed the following which might apply to this effort:

• If strong-named .Net Core assemblies are marked as assemblies, the ClickOnce runtime will reject them with a signature failure. If they are marked as files, the build API will warn, but the runtime accepts them. My company is using this workaround right now to deploy a Net Core application which includes some strong-named assemblies over ClickOnce. Net Core assemblies that are not strong-named can be marked as assemblies without problem.
• If a Net Core executable includes an embedded manifest, it will be rejected by the ClickOnce runtime.(1)
• Reg Free COM and File Associations are difficult to accomodate.
• In theory, if you're going to allow Net Core executables to be launched, there's no extra effort in allowing any executable to be launched.
• If you're going to allow the launcher to accept URL parameters, please consider allowing them to accept command-line parameters as well. I appreciated why these were excluded at the time, but it would now be extremely useful to permit them (e.g. to tie into the Net Core config pipeline for CI)

(1) In Visual Studio under the old project system for net fx, if a project includes a manifest, it will be intercepted by the ClickOnce publish pipeline. Instead of being embedded (regardless of project setting), it will be intercepted and merged with the external ClickOnce manifest being created. As I was working with compiled binaries, this was a problem - I would have to detect it in the binary, extract it, modify the binary and then merge it with the external manifest. I elected to avoid the issue by mandating that executables must not have an embedded manifest.

[mansellan]

I would also agree with @billybednar that the "silent fail" update that ClickOnce ships with is unsatisfactory. We've had to write bespoke telemetry to even notice it, and will likely need to come up with enforcement strategies soon.

[NikolaMilosavljevic]

@mansellan your solution looks great! You are right in all of the points you bring, we have encountered all of them and made decisions to, for instance, do simple-file dependencies and modify MSBuild task to not warn for Core apps. We will also require executable to not have an embedded manifest, that is simply the requirement imposed by ClickOnce runtime. We will be working soon on update, check and failure, improvements, adding support for URL parameters and bringing Mage tool into this repo.

[RealDotNetDave]

I have asked for this too. Let me know if you need any help with testing or ideas!

David McCarter