本地和作为XBAP双重部署WPF应用程序

问题描述 投票:2回答:3

如何创建一个可以作为XBAP或本机Windows应用程序部署的WPF应用程序,并尽可能减少开销? XBAP与WPF Windows应用程序二进制兼容,并在同一个CLR之上运行(与Silverlight不同)。他们在某些方面仍有所不同。

从部署的角度来看,它们最大的区别在于,XBAP将Page控件作为主容器,而Windows应用程序具有Window控件。使Windows应用程序使用Page控件是相当简单的,但我觉得(随意不同意)在Windows应用程序中使用页面导航方法相当不直观。

第二个主要区别是默认情况下XBAP在部分受信任的环境中执行。这可以被绕过,并且XBAP可以在完全信任模式下运行。使用XBAP的部分信任模式意味着您无法直接从XBAP访问远程Web服务或本机代码。

在上述问题中实现以下目标的简单且可维护的方法是什么?

要求

  1. 可以通过两种方式进行部署:作为基于http的XBAP和作为独立的WPF可执行文件。
  2. 显示来自远程Web服务器(如flickr)或非托管API的信息。
  3. 如果可能,部署方法应该忠实于他们的平台。也就是说:在XBAP中使用Pages,在那些有意义的Windows应用程序中有意义和对话。

限制

  1. 平台优化。 XBAP所需的东西不应该影响Windows客户端,反之亦然。
  2. 部署选项共享尽可能多的代码。这有助于测试和维护。
  3. 运行XBAP应该尽可能简单。证书要求会破坏XBAP的目的。

我收集的是第一个要求需要两个单独的项目。第二个限制可以通过一个包含所有UI的用户控件项目来处理,并由两个部署项目引用。 WCF Web服务可以解决XBAP的限制。

如果使用类似于上述行的解决方案,第一个限制将需要一些工作,因为Windows客户端可以在没有WCF服务的情况下完成,因为它已经在完全信任模式下运行。此外,第三个要求需要一些特定于部署的代码,因此所有UI代码都不能在用户控件项目中。

我想知道可以使用哪些解决方案来解决这些问题。随意忽略部分解决方案。这主要是为了解释这一点,并防止“已经考虑过这个”的评论。所以,为了澄清,我对这个问题的所有解决方案感兴趣,而不仅仅是那些遵循部分解决方案的解决方案。

感兴趣的是,解决方案意味着不需要在WPF Windows应用程序和XBAP之间进行思考,因为这两者都可以用更少的努力创建,并且客户端可以选择最适合它们的那些。

.net wpf deployment xbap
3个回答
2
投票

您可能想看一下Prism(at codeplex)它有助于以最少的代码更改来定位Wpf,Xbap和Silverlight(额外工作量取决于您的项目)。

以下是如何使用它来创建Wpf和Xbap应用程序:Prism and XBap Applications


3
投票

This scorbs article解释了如何做到这一点,它甚至有一个应用程序模板来做到这一点。

alt text (来源:scorbs.com


0
投票

多年来,我尝试了几种方法。对我来说效果最好的是在一个解决方案中有四个项目:

  • 构建包含业务对象,通信和UI的dll的主项目。
  • 测试项目包含手动和自动单元测试
  • 一个用于Windows应用程序的微小.exe项目
  • 一个小小的.xbap项目

在主项目中既没有Pages也没有Windows,只有UserControls和自定义控件。还有一个用于显示UI的服务类。此类在Windows和XBAP项目中进行子类化,以更改事物的显示方式。在每种情况下,子类都会在应用程序启动时安装在静态属性中。所有其余代码只是引用此静态属性并在其上调用方法。这些方法执行Windows和XBAP应用程序之间不同的服务。

例如,我的服务类有一个“ShowDialog”方法,它接受FrameworkElement并以对话框样式显示它,可以是Window(对于Windows应用程序),也可以是页面上的Popup(对于XBAP)。

使用此技术可以在Windows应用程序和XBAP之间共享大约98%的代码。

我的主应用程序还定义了客户端 - 服务器接口,并将WCF属性应用于其数据对象。所有代码都使用静态属性来访问服务。此静态属性(在类构造函数中)初始化为具体实现类的实例,但XBAP项目中的启动代码将其替换为WCF客户端,因此XBAP运行客户端 - 服务器,而Windows应用程序实际上是本地的调用。在每种情况下,它与服务器端上的对象完全相同。

因为我将WCF实现为接口,所以我能够为WCF服务端部提供简单的.svc文件,而不需要在代理/存根代码中单独生成代码或链接。

© www.soinside.com 2019 - 2024. All rights reserved.