WPF - 是否有人真正使用 XBAPS？使用它们是否有充分的理由
除此之外，人们可以在可能熟悉的浏览器中查看该应用程序。是否有任何真正令人信服的理由在 WPF 中使用 XBAP 模型而不是直接的独立 WPF 应用程序。
我所看到的只是潜在的安全问题和限制，但没有任何好处。我错过了什么吗？
Apart from the fact people get to view the app in a browser which may be familiar. Is there any actual compelling reason to use the XBAP model in WPF rather than a straightfoward stand alone WPF app.
All I can see are potential security issues and restrictions but no benefits. Am I missing something?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我曾经使用过 XBAP。
我们需要完全信任，并且需要应用程序像浏览器托管一样运行。 XBAP 是我们唯一真正的选择，我很高兴有它。
除了这个小缝隙之外，Silverlight 和单击一次是更好的所有选项。
I have used an XBAP, once.
We needed full-trust, and we needed the application to act as if it were browser hosted. XBAP was the only real option we had, and I'm glad it was there.
Outside of this tiny nitch, Silverlight & Click Once are better all around options.
实际上，“否”和“否”将是您问题的答案。我从未真正见过它们在生产中使用，也没有真正合理的理由使用它们。
正如 Kent 提到的，Silverlight 或 Click Once 几乎总是更好的选择。
有人可能会说，在完全信任的仅 Windows 环境中，XBAPS 使您能够利用完整的 WPF 框架和 Web 部署的灵活性。当然，这就是 Click Once 的用途。然而，根据我的经验，ClickOnce 对于任何简单的单一应用程序安装来说都是一场噩梦，因此您可能会主张使用 XBAP 来避免 ClickOnce 带来的麻烦。
但我的回答是，Silverlight 可能是更好的选择。
In practice No and No would be the answers to your questions. I have never actually seen them used in production nor is there ever really a justified reason to use them.
As Kent mentioned Silverlight or Click Once is almost always a better option.
One could argue, in a full trust Windows only environment, XBAPS gives you the ability to leverage the full WPF framework with the flexibility of web deployment. Of course that is what Click once is for. However, in my experience ClickOnce is a nightmare for anything more then a simple, single application install so you might argue in favor of XBAP to avoid ClickOnce headaches.
But again, my response would be, Silverlight is likely a better choice.
我们使用它来为应用程序提供单一来源的解决方案，该解决方案可以在浏览器中运行，也可以作为桌面应用程序运行。双方充分信任。
We use it to have a single sourced solution for an application that can run in a browser but also as a desktop application. Both full trust.
实际上，由通过 Web 服务进行通信的 xbap 组成的模块化设计的应用程序非常高效。这种类型的场景将允许执行模块化片段以并发运行并在单独的内存空间中运行。这有利于用户和应用程序的开发人员。
该应用程序不会在 ie 中运行，而是在自定义浏览器 shell 中运行，以控制应用程序本身的流程和执行。当所有内容都可以简单地在单个或多个项目中运行时，这似乎确实需要做很多工作，但这种类型的解决方案适用于大型企业应用程序。应用程序程序员将能够处理应用程序的包含不同功能、实用程序和功能的片段或不同部分。用户永远不知道或意识到每个部分实际上是独立运行的，因为它看起来是无缝的。由于 shell 不是 xbap 并且具有完全权限，因此消除了部分信任问题。现在来说说好东西……如果碰巧出现故障（这种情况永远不会发生，对吧？），应用程序的其他部分将继续执行而不会出现故障。 Try-catch-finally 工作得很好，直到你错过了一个......最后但并非最不重要的是，没有更复杂的后台线程处理它在浏览器中并且默认情况下是异步的。大多数系统会同时打开多个窗口，每个窗口只包含一个运行 xbap 的浏览器。独特...是的...有用...是的...这是一种不同的方法，但它干净简单。
人生就是一场比赛……当你到达终点线时，谁会在那里为你加油，你会为这场比赛感到自豪吗？
Actually a modular designed app consisting of xbap(s) communicating via webservice is very efficient. This type of scenario would allow for execution of the modular pieces to run concurrent and in separate memory spaces. This benefits the user and the application's developer(s).
The app would not run in an ie but rather a custom browser shell to control the flow and execution of the application itself. It does seem like a lot of work when everything could simply run with in a single or multiple projects but this type of solution would be pertinent in large enterprise app(s). The application Programmer(s) will be able to work on segments or distinct parts of the app which contain distinct functions, utilities, and capabilities. The user never knows or realizes that each part is actually running independently because it appears seamless. The partial trust issue is eliminated because the shell is not an xbap and has full permission. Now to the good stuff ... if there happens to be a fault (that never happens right?) other parts of the application continue to execute without failure. Try-catch-finally work great until you miss one... Last but not least no more complicate background thread processing it's in a browser and by default is async. Most systems will have multiple windows open at a time each window simply contains a browser running an xbap. Unique...Yes...Useful...Yes... It is a different approach but it is clean and simple.
Life is a race ... When you reach the finish line who will be there cheering for you and will you be proud of the race that was run?
如果您需要运行 WPF 客户端而无需管理员权限且无需在客户端计算机上安装任何内容（忽略用户的配置文件缓存），则使用部分信任的 XBAP 非常有用
XBAPs using Partial Trust are useful if you have a requirement that the WPF client should be run without requiring admin privileges and without installing anything on the clients machine (disregarding the user's profile cache that is)
我也在想同样的事情，这是我的收获。
主要原因是用户体验，WPF应用程序比Silverlight更强大并且更容易编写。人们会点击网站，但在安装应用程序时会三思而后行。 XBAP 非常接近网站体验，并且性能优于 Click Once 和 Silverlight。
然而，由于它仅适用于非常狭窄的用户群，因此它可能最适合 Intranet 应用程序。
WPF、XBAP、Silverlight - 我该使用什么？
I was thinking the same thing, here is my takeaway.
The main reason is the user experience, WPF apps are more powerful and easier to write than Silverlight. People will click on a web site, but will think twice about installing an application. An XBAP is very close to a website experience, and can out perform Click Once and Silverlight.
However since it only works for a very narrow user base, it would probably be best for intranet applications.
WPF, XBAP, Silverlight - What do I use?