来自原始站点的 CloudFront 更新上的 ClickOnce
我在我的网站上发布了 ClickOnce 设置。我使用 Amazon CloudFront 尽可能靠近客户端缓存文件。问题是我现在必须使每次部署的应用程序清单失效。
是否可以让 ClickOnce 在一个位置检查更新，但从另一个位置下载应用程序？
谢谢你， 我愿意
I have ClickOnce setup publish on my site. I'm using Amazon CloudFront to cache the files as close the clients as possible. The problem I now have to invalidate the app manifest every deployment.
Is it possible to have the ClickOnce check for update on one location yet download the app from another?
Thank you,
Ido
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
为什么每次部署时都需要使清单失效？ CloudFront 是否类似于 CDN，您需要告诉边缘服务器在更改时从源检索新版本？
ClickOnce 应用程序始终从与部署清单相同的位置下载文件。如果我是对的，CF 是某种 CDN，那么问题就不是文件，而是部署清单。
此外，ClickOnce 用于安装和更新的 URL 是部署 ID 的一部分，并且不能随意更改。在大多数情况下，您的用户必须卸载并重新安装才能从不同的 URL 访问部署。
另一方面，您可以避免整个问题，并将部署托管在 Azure blob 存储中，每月仅需几分钱（http://robindotnet.wordpress.com/2011/07/18/host-your-clickonce-deployment-in-azure -for-pennies-per-month/) 相反...您甚至可以使用 Azure CDN 为您的客户提供最快的性能。在 Azure 上，我认为您可以在部署清单上将生存时间设置为 0，以便在每次访问更新时进行检查。
Why do you need to invalidate the manifest with each deployment? Is the CloudFront something like a CDN, where you need to tell the edge servers to retrieve a new version from the origin when it gets changed?
The ClickOnce app always downloads the files from the same location as the deployment manifest. And if I'm right and CF is some kind of CDN, then it's not the files that are the problem, it's the deployment maniest that's being picked up.
Also, the URL that ClickOnce uses to install and update from is part of the ID of the deployment, and it can't be changed willy-nilly. In most cases, your uses would have to uninstall and reinstall to access the deployment from a different URL.
On another note, you could avoid this whole problem and host your deployment in Azure blob storage for pennies a month (http://robindotnet.wordpress.com/2011/07/18/host-your-clickonce-deployment-in-azure-for-pennies-per-month/) instead... You could even use the Azure CDN to give the speediest performance to your customers. On Azure, I think you can set the Time-To-Live to 0 on the deployment manifest to have it check each time it's accessed for an update.