Apr 08 2019 10:01 AM
Apr 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.
Jun 02 2021 03:32 PM
Jun 02 2021 03:40 PM
Yes, I see it when I click that link as well. See the following screenshot.
Jun 02 2021 07:26 PM
@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.
Jun 03 2021 11:14 AM
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?
Jun 03 2021 11:38 AM - edited Jun 03 2021 12:02 PM
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...) 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/)