Silverlight 业务应用程序的应用程序发布/升级策略？
我很想听听其他人是否已经解决了 Silverlight 应用程序的发布管理问题。
我有一个即将发布的业务应用程序，我关心如何“发布”此应用程序的更新。通常，此应用程序的用户会让应用程序全天（甚至整夜）打开，而不重新加载。
如果需要发布包含 Web 服务接口更改的更改怎么办？如何部署它而不导致客户端出现错误？
我们已经习惯于通过将最新代码放到服务器上来部署 ASP.Net 应用程序。目前我唯一的想法涉及客户端版本号和定期计时器来检查更新。
我很想知道其他人在实施此之前做了什么。
谢谢， 麦克风
I am interesting in hearing if others have addressed release management for Silverlight applications.
I have a business application that is to be released shortly andam concerned about how to "release" updates to this application. Typically this application's users will leave the application open all day (and potentially all night) without reloading it.
What if there is is need to release an change that includes an web service interface change? How can this be deployed w/o causing errors on the client side?
We have grown so used to deploying ASP.Net apps by just dropping the latest code on the server. My only idea currently involves a client version number and a periodic timer on to check for updates.
I would love to know what others have done before implementing this.
Thanks,
Mike
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我刚刚回答了一个有关如何确保 .xap 文件不被浏览器缓存的问题，这可能会有所帮助：
防止 Silverlight xap 被代理服务器缓存< /a>
但如果用户从不重新加载您的应用程序，那就没用了。在我自己的应用程序中，这不是问题，因为每当我们向 Web 服务部署更新时，用户都会被自动排除。但我喜欢你关于计时器的想法，我会同意的。
I just answered a question on how to make sure that .xap files are not cached by the browser, which might be of some help:
Prevent Silverlight xap from being cached by proxy server
But that's no use if the users never reload your application. In my own application this is not a problem since users will be automatically thrown out whenever we deploy an update to the web service. But I like your idea with the timer, I would go with that.
陈述显而易见的事情，但不要做任何惹恼用户的事情。例如，他们是否可以花二十分钟输入数据，然后跑到咖啡机旁，然后返回单击“提交”，发现计时器已过期，注意到更新，并且由于强制重启而导致他们的工作丢失？
如果是这样，我承认这并没有经过太多思考，例如，如果您必须对破坏当前版本的 Web 服务进行更改，您是否可以并排使用新的 Web 服务版本，以便用户不会在计时器到期并且工作单元完成之前不会被扔掉吗？或者这也说明了显而易见的事情？
Stating the obvious but don't do anything to annoy your users. E.g. could they spend twenty minutes entering data, nip off to the coffee machine and return to click Submit to find the timer has expired, noticed an update and their work is lost due to a forced restart?
If so, and I admit this hasn't had a lot of thought, if e.g. you have to make changes to the web service that break the current release, could you have the new web service version side-by-side such that users don't get thrown out until the timer has expired and the unit of work is complete? Or is this also stating the obvious?
对于服务器代码，即端点只需按正常方式执行即可。对于 xap，我认为您有几种选择，具体取决于您处理通信的方式。您可以让请求包含版本号，如果服务器已更新，则强制某些代码重新加载客户端，虽然有点蹩脚、混乱但可行。也许更干净的解决方案是控制客户端会话，这可能是对后端请求的重要组成部分。当您部署新版本时，您可能会使客户端会话无效，可能会强制使用自定义逻辑刷新页面。如果您的协议是推送基础，您可以向客户端发送命令来执行您想要的操作，对于许多全天运行的系统来说，此基础设施很可能会存在（如果您构建得很好:)）。例如，我们的服务层是从存储库模型和视图模型中抽象出来的，在我们的例子中，我们可以发送一个注销或一个特定的命令来在客户端上启动一些自定义逻辑，通知应用程序正在更新并刷新您的应用程序。完成后浏览器。我们的 shell 重量轻，因此我们的模块（基本上是其他 xap 的）可以及时更新以进行刷新。
For server code, i.e. endpoints just do as per normal. for the xap's I think you have a few options depending upon how you handle communications. You could have request contain a version number and if the server has been updated then force some code to reload the client, bit lame, messy but do-able. Perhaps a cleaner solution would be to control the clients session, which presumably is part and parcel with requests to the backedn. When you deploy a new version you could invalidate the client session, perhaps forcing a page refresh with custom logic. If your protocol is push base you could send a command to the client to do what ever you want, for many systems that are on all day its likely that this infrastructure would exist (if u've build it nicely :)). For instance our service layer is abstracted away from the repositories models and view models, in our case we'd could send a logout or perhaps a specific command to kick in some custom logic on the client informing the application is being updated and to refresh your browser when done. Our shell is light weight so our modules (basically other xap's) can be updated in time for the refresh.
我建议您使用 App Arch 指南中提到的解决方案：
我的意思是指南章节 请参阅部署注意事项。
可缓存的模块
单独的，并且可以更换
轻松地无需用户
下载整个应用程序
再次。
I would recommend you to use a solution like mentioned in App Arch Guide:
The Guide Chapter I mean see Deployment considerations.
modules that can be cached
separately, and that can be replaced
easily without requiring the user to
download the entire application
again.
您是否考虑过保留 WCF 轮询双工 通道会在需要重新加载时提醒应用程序吗？此外，您可以将 WCF 调用直接发送到包含“接口”调用的虚拟目录。例如：
托管在“xxxx\Default.aspx”的 Silverlight 应用程序
Silverlight 与位于“xxxx\Version2\DataPortal.svc”的 WCF 进行对话
DataPortal.svc 与 GAC（或其他基础）程序集对话，该程序集可以识别哪个版本可以处理哪些调用。
这样，如果您升级到“xxxx\Version3\DataPortal.svc”，您仍然可以对 Version2 进行调用，假设这些调用具有将其转换为 Version3 概念的代码。
如果您的业务线应用程序具有动态 xap 下载（“主要”、“客户”、“库存”等）并且您希望独立发布它们，这会很有帮助。
Have you considered keeping a WCF polling duplex channel going that alerts the app when it needs to reload? In addition, you can have your WCF calls direct to a virtual directory that contains 'interfaced' calls. For example:
Silverlight app hosted at "x.x.x.x\Default.aspx"
Silverlight talks to WCF at "x.x.x.x\Version2\DataPortal.svc"
DataPortal.svc talks to a GAC (or otherwise base) assembly that can identify what version can handle what calls.
This way, if you upgrade to "x.x.x.x\Version3\DataPortal.svc", you can still make calls against Version2, assuming those calls have code to convert them to a Version3 concept.
This helps in cases where your line of business app has dynamic xap downloading ('main', 'customer', 'inventory', etc.) and you want to release them independently.