Forum Discussion
ClickOnce application downloads instead of directly opening the app
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:
https://docs.microsoft.com/en-us/DeployEdge/edge-learn-more-co-di?branch=pr-en-us-105
Thanks everyone for your patience!
I am using Version 91.0.864.37 (Official build) (64-bit) of Edge and have enabled the ClickOnce flag; however, I am still just seeing the download behavior and am not able to click and run the .vsto add-in from the server url. Am I missing something?
Thanks for your help!
- Eric_LawrenceJun 02, 2021
Microsoft
mjonestx: On which version of Windows are you having this problem? Is your server URL public, or can you otherwise see what `Content-Type` response header it's sending (using Fiddler or similar?) If you try the sample link at https://webdbg.com/test/clickonce/, does it pop the UI?
- mjonestxJun 02, 2021Copper Contributor
Thanks!
My client pc is running Windows 10 Pro, Version 1909, OS Build: 18363.1500
The Server that is hosting the .vsto Word add-in, is a Windows Server 2016 server running SharePoint 2016 on-prem.
When I click on the url you provided in Edge, I see what is in the following screenshot.
When I click on the 'Launch' link in the "Otherwise, install HelloClickOnce via a setup.exe" section, I see what is in the following screenshot:
, which is not what I see when I click on a link to the .vsto file on my server, such as in the next screenshot:
Here is only download the file directly and does not give me an option to open/run it from the server.
The response header that I get when I click on the v.sto file name is:
HTTP/1.1 200 OK
Cache-Control: max-age=31536000
Content-Type: application/x-ms-vsto
Last-Modified: Wed, 16 Dec 2020 22:47:16 GMT
Accept-Ranges: bytes
ETag: "a1e2e366fdd3d61:0"
Server: Microsoft-IIS/10.0
X-SharePointHealthScore: 0
SPRequestGuid: bb05ce9f-cb20-90a6-2691-8f6809719a7f
request-id: bb05ce9f-cb20-90a6-2691-8f6809719a7f
X-FRAME-OPTIONS: SAMEORIGIN
SPRequestDuration: 8
SPIisLatency: 1
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 16.0.0.5149
X-Content-Type-Options: nosniff
X-MS-InvokeApp: 1; RequireReadOnly
Date: Wed, 02 Jun 2021 19:24:07 GMT
Content-Length: 6776When I click on the 'launch' link on the site you posted, I get the following response header:
Accept-Ranges: bytes
Content-Length: 5915
Content-Type: application/x-ms-application
Date: Wed, 02 Jun 2021 22:00:52 GMT
ETag: "5bb16917add41:0"
Last-Modified: Tue, 15 Jan 2019 21:12:34 GMT
Server: Microsoft-IIS/8.5
X-Powered-By: ASP.NETAny ideas? Thanks again!
MJ
- Eric_LawrenceJun 03, 2021
Microsoft
mjonestx Thanks for reporting this. Fun.
So, the trick here is that, when the RequireReadOnly parameter is present on the X-MS-InvokeApp response header (as it is in your example):
...the Shell verb used to open the URL is changed from Open to OpenAsReadOnly. However, the VSTO file type's registration doesn't support that verb, so as a consequence the DirectInvoke code says "Hrm, the requested operation isn't supported, I'm not going to DirectInvoke that." If you were to change your registry such that the type claimed support for that verb:
... you'd find that your scenario starts working again. Of course, for deployability reasons, it's probably more straightforward to remove the RequireReadOnly directive.