如何創建可作爲XBAP部署的WPF應用程序或作爲本地Windows應用程序以儘可能少的開銷部署? XBAP與WPF Windows應用程序二進制兼容,並且在相同的CLR之上運行(與Silverlight不同)。它們在某些方面仍然不同。雙重部署WPF應用程序本身並作爲XBAP
從部署的角度來看,它們最大的區別在於,當Windows應用程序具有Window控件時,XBAP具有Page控件作爲主容器。讓Windows應用程序使用Page控件是相當簡單的,但我感覺(可以自由地不同意)在Windows應用程序中使用頁面導航方法相當不直觀。
第二個主要區別是默認情況下,XBAP在部分信任的環境中執行。這可以被繞過,並且XBAP可以在完全信任模式下運行。使用XBAP的部分信任模式意味着您無法直接訪問例如遠程Web服務或來自XBAP的本機代碼。
什麼是一個容易和可維護的方式來實現以上問題與以下問題?
要求
- 部署在兩個方面:作爲一個XBAP通過HTTP和作爲一個獨立的WPF可執行文件。
- 顯示來自遠程Web服務器(如flickr)或非託管API的信息。
- 如果可能,部署方法應該忠實於他們的平臺。也就是說:在XBAP中使用頁面,這些頁面在Windows應用程序中是有意義的,對話框是有意義的。
限制
- 平臺優化。 XBAP所需的東西不應該影響Windows客戶端,反之亦然。
- 部署選項共享盡可能多的代碼。這有助於測試和維護。
- 運行XBAP應該儘可能簡單。證書先決條件將會破壞XBAP的目的。
我收集的是第一個需求需要兩個單獨的項目。第二個限制可以通過具有包含所有UI並且由兩個部署項目引用的用戶控制項目來處理。 WCF Web服務可以解決XBAP的侷限性。
如果採用類似於上述各行的解決方案的第一限制將需要一些工作作爲Windows客戶端可以在不WCF服務做的,因爲它是已經完全信任模式下運行。第三個需求也需要一些特定的部署代碼,這樣所有的UI代碼都不能在用戶控制項目中。
我想知道有什麼解決辦法可以用來解決這些問題。隨意忽略部分解決方案。它主要是爲了解釋這一點,並防止「已經有過這種想法」的評論。因此,爲了澄清,我對全部解決方案感興趣,而不僅僅是那些遵守部分解決方案的解決方案。
對此感興趣的原因是,解決方案意味着無需在WPF Windows應用程序和XBAP之間進行思考,因爲這些應用程序都可以在創建時多付出一點努力,並且客戶端可以選擇最適合他們的任何一種。
嗡嗡聲。通過快速瀏覽,Prism似乎專注於源代碼級代碼共享。這在WPF和Silverlight之間是必需的,因爲這兩者不是二進制兼容的。我主要是指彙編級代碼共享。雖然這是一個快速瀏覽。早晨需要更好看。 – 2009-05-02 23:07:16