Forum Discussion
ClickOnce application downloads instead of directly opening the app
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: 6776
When 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.NET
Any ideas? Thanks again!
MJ
Microsoftmjonestx 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.
Thanks for this. I can get it to work fine in an IIS site outside of SharePoint; however, it appears that SharePoint is putting that in regardless of what I try. Even if I remove it from the web.config of the IIS site, when clicking on the link to the .vsto file, it reappears in the response headers.
Any ideas on a way around that?
- Eric_Lawrence
Unfortunately, no, I don't know much about SharePoint's header configuration. It looks like there's a simple UI that applies to ALL responses (https://blog.bugrapostaci.com/2019/08/23/unable-to-open-documents-using-direct-links-from-sharepoint-2019/) but to remove the token selectively for only certain types seems likely to require a custom HTTPModule (e.g. something like https://tesitgeek.wordpress.com/2016/04/07/ho-to-remove-http-response-headers-for-sharepoint-sites/)