04-08-2019 10:01 AM
04-08-2019 10:01 AM
When opening a ClickOnce app, the *.application file gets saved to my Downloads folder instead of directly opening it. Additionally, since the file is downloaded, then opened from Downloads, it loses the cookie information required for our app to function correctly.
04-08-2019 10:12 AM
I'm experiencing this as well. This is known behavior for how Chrome handles ClickOnce applications, but we use Edge today for launching ClickOnce applications.
04-08-2019 10:28 AM
@CodeDJ I have this same issue. I get around it by calling iexplore.exe in front of the app to launch it from IE. This is a workaround, I would like Microsoft to fix this so it is handled correctly.
Here is my example that I use in the shortcut:
"C:\Program Files\Internet Explorer\iexplore.exe" http://website.com/example.application
04-08-2019 10:36 AM
@Jesse Cook Thanks for the tip. Clicking on the downloaded abc.application opens the clickonce app for me using Edge Insider but it doesn't include any cookies from my website - which is a requirement for my apps. Thanks!
04-08-2019 02:24 PM
Yep same here, this was one of the first things I wanted to check as we really need this to be working out of the box for the new Edge.
04-10-2019 12:05 PM - edited 04-10-2019 12:06 PM
@CodeDJ There is a Chrome extension called "ClickOnce for Google Chrome". This can be installed in Edge, if you allow extensions from other stores and then acquire the extension from the Chrome Web Store. Although, this is not a built-in function, the extension does allow ClickOnce apps to execute normally, instead of being downloaded.
I do hope that this ClickOnce function will be addressed in Edge, so that we don't have to use an extension or another work-around.
04-10-2019 05:52 PM
@CodeDJ We really appreciate the feedback! ClickOnce support was on our mind as we were thinking through the Downloads workflow in Edge. It is feedback like yours, and others responding to this post, that help us in prioritizing ClickOnce support relative to other areas we are investing in. ClickOnce is a feature that we are working towards implementing, so stay tuned!
05-30-2019 07:02 PM
Hi @Vidmo, thanks for checking in! We have engineers actively working on getting ClickOnce support and this is high on my priorities. While I can't reveal the timeline for this, I will try to update this post when I have more information to share. Feel free to ping this thread again if you don't hear back from me!
06-17-2019 05:39 AM
06-20-2019 07:08 PM
06-21-2019 10:18 AM
@aclowe Thanks for the feedback, it definitely helps that we can show customer need when prioritizing our features. Engineering work is still being put into this feature, so it is definitely still a priority! Will keep people updated via this thread!
09-23-2019 11:05 AM - edited 09-23-2019 11:07 AM
@CodeDJ Just updating this thread to say that ClickOnce support is now in Canary (79.0.283.0). Users may opt into using ClickOnce by heading to the about:flags page and looking for "#edge-click-once".
More information on this is available here:
Thanks everyone for your patience!
09-24-2019 10:23 AM
@i-am-kent awesome! I have verified it works as expected, except for what's documented in the url you provided. For our internal website, I keep getting the Open/Cancel popup and have to click it each time.
09-25-2019 06:35 AM - edited 09-25-2019 08:19 AM
@i-am-kentI read the documentation page you listed and I'm confused. Why would ClickOnce NOT be turned on by default?
We're expecting a solution that behaves as IE and Edge do today. They both have ClickOnce on by default, why shouldn't Edge DEV as well? Also, will there be a GPO method to turning this on? If not, then how can you claim it's for Enterprises to use?
09-25-2019 07:30 AM
@Vidmo this is how they release new features, first in canary, a lot of times behind a flag, when stable it becomes the default.
09-25-2019 08:17 AM - edited 09-25-2019 08:19 AM
@CodeDJPlease re-read the documentation page. https://docs.microsoft.com/en-us/DeployEdge/edge-learn-more-co-di?branch=pr-en-us-105
That page states specifically "Because ClickOnce is an enterprise-focused feature that’s used by a specific group of power users and not intended for general use, ClickOnce is disabled by default."
09-25-2019 08:24 AM
@i-am-kent To somewhat answer my own question about GPO support it looks like the manual enable option does state that "This feature flag will be overridden if your organization configures the "Allow users to open files using the ClickOnce protocol" policy."
So maybe we will have some control over this.
09-25-2019 09:50 AM
@i-am-kentJust tested with a ClickOnce .application URL and it worked fine. But what about .vsto? Its not being treated as a ClickOnce URL install.
09-25-2019 11:05 AM
09-25-2019 02:17 PM
@Vidmo didn't see that. I agree this should be on by default just like IE and MSEdge.
09-25-2019 03:57 PM
Thanks for the update, working perfectly for me after enabling the flag.
Our business would not be opposed to having to enable the option with it off by default if that decision is made for security or other purposes. It would be nice to have this available via Group Policy or other deployment options.
09-25-2019 05:30 PM
@CodeDJ , thanks for the feedback! We would definitely need to think through some interesting security implications here (it would be analagous to setting "Always run executables" for downloads).
@Vidmo , sorry I couldn't get back to you earlier; it looks like you were able to answer your question. We do not currently have plans to enable ClickOnce for ALL users, but you currently should have access to group policy to ensure that your organization has ClickOnce turned on by default if necessary. The policy is described here https://docs.microsoft.com/en-us/DeployEdge/microsoft-edge-policies#clickonceenable
@aclowe , please take a look at https://docs.microsoft.com/en-us/DeployEdge/microsoft-edge-policies#clickonceenabled for the group policy to support exactly what you mentioned
As Eric mentioned, we will be looking into the vsto bug! Thanks everyone for your feedback!
11-20-2019 09:25 AM
Our customers have relied on Microsoft .NET ClickOnce support for a long time, and we are unclear how to document the path forward with Edge chromium.
We obviously prefer to have ClickOnce enabled by default, but if not there should be a simple configuration option each user can toggle. We don't have any plans to retire our ClickOnce feature at this time, so continued support is critical.
11-20-2019 09:31 AM
11-22-2019 03:34 PM
I can't reproduce the mime issue anymore (Version 80.0.341.0 (Official build) canary (64-bit)). It only happened once after installing the nightly, and now it's fine. I wonder if it was due to having 3 different Edge versions running on the same system (Edge, Edge Beta, Edge Canary).
It's a Windows 10 system that had no prior ClickOnce issues with Edge or IE11. When attempting to open the .application file from the file system, the mime dialog shows it is associated with the "ClickOnce Application Deployment Support Library," which appears normal.
12-03-2019 01:30 PM
@Vidmo we believe that we have fixed the "vsto does not work with" issue in the latest Canary. Are you able to confirm this? It should work with 80.0.351.0.
12-28-2019 01:02 PM
@i-am-kentThanks, I can confirm that links for VSTO apps do now work in Version 80.0.361.9.
01-28-2020 12:36 PM
4. A screenshot and/or OS information should be helpful here. File associations are owned by Windows, not the browser. If you save a .application file to your desktop and open it on the machine in question, what happens?
Per 4), in Version 80.0.361.40 (Official build) beta (64-bit) on Windows 10 Pro (1903) (64-bit), upon accessing a ClickOnce URL for the first time, the user is prompted to either open the file or cancel (as expected), but when the user clicks Open, a system app chooser is displayed and the user is forced to choose Edge to open the file, rather than Edge simply handing off to dfshim.dll or VSTOInstaller and letting ClickOnce do its thing. After associating .application and .vsto manifests with Edge (selecting "Always use this app" is not necessary), the user is never subsequently prompted to choose applications. The system's file association for these types is not altered, nor is it set to Edge, so this is not on the OS. On Windows, it should be Edge's responsibility to provide the manifest URLs directly to the handler for each MIME type, and an appropriate association should not need to be established by the user.
02-19-2020 07:15 AM
by vctgomes on May 24, 2020
by theshaunsaw on May 23, 2020
by Stephen_Macknik on May 21, 2020