WPFアプリをネイティブにXBAPとしてデュアル展開する

Question

できるだけ少ないオーバーヘッドでXBAPまたはネイティブWindowsアプリケーションとしてデプロイできるWPFアプリケーションを作成する方法は？ XBAPはWPF Windowsアプリケーションとバイナリ互換性があり、同じCLR上で実行されます（Silverlightとは異なります）。まだいくつかの点で異なっています。

展開の観点から見た場合の最大の違いは、XBAPにはメインコンテナーとしてPageコントロールがあり、WindowsアプリケーションにはWindowコントロールがあることです。 Windowsアプリケーションでページコントロールを使用するのは簡単ですが、Windowsアプリケーションでページナビゲーションメソッドを使用するのはかなり直感的ではないと感じます（お気軽に同意してください）。

2番目の大きな違いは、XBAPはデフォルトで部分的に信頼された環境で実行されることです。ただし、これはバイパスでき、XBAPは完全信頼モードで実行できます。 XBAPを使用した部分信頼モードは、XBAPからリモートWebサービスやネイティブコードなどに直接アクセスできないことを意味します。

上記の問題で以下を達成するための簡単で維持可能な方法は何ですか？

要件

1. 両方の方法でデプロイ可能：httpを介したXBAPとして、およびスタンドアロンのWPF実行可能ファイルとして。
2. flickrなどのリモートWebサーバーまたはアンマネージAPIからの情報を表示します。
3. 可能であれば、展開方法はプラットフォームに忠実でなければなりません。つまり、XBAPでページを使用し、Windowsアプリでダイアログを使用して意味を理解します。

制限

1. プラットフォームが最適化されました。 XBAPが必要とするものは、Windowsクライアントに影響を与えるべきではなく、その逆も同様です。
2. 展開オプションは、できるだけ多くのコードを共有します。これはテストとメンテナンスに役立ちます。
3. XBAPの実行は可能な限りシンプルにする必要があります。証明書の必要条件は、XBAPの目的に反します。

私が集めたのは、最初の要件には2つの別個のプロジェクトが必要だということです。 2番目の制限は、すべてのUIを含み、2つの展開プロジェクトによって参照されるユーザーコントロールプロジェクトを持つことで対処できます。 WCF Webサービスは、XBAPの制限を回避できます。

上記の行と同様のソリューションを使用する場合、WindowsクライアントはWCFサービスが既に完全信頼モードで実行されているため、WCFサービスなしで行うことができるため、最初の制限には多少の作業が必要になります。また、3番目の要件には展開固有のコードが必要になるため、すべてのUIコードをユーザーコントロールプロジェクトに含めることはできません。

これらの問題を解決するために使用できるソリューションを知りたい。部分的な解決策を無視してください。主にポイントを説明し、「これについての考え」を防ぐためにあります。コメント。明確にするために、部分的な解決策に従うだけでなく、この問題に対するすべての解決策に興味があります。

これに関心がある理由は、ソリューションはWPF WindowsアプリとXBAPの両方をもう少しの労力で作成でき、クライアントが最適なものを選択できるため、WPF WindowsアプリとXBAPを熟考する必要がないことを意味するからです

Answer 1

Prism（ codeplexで）をご覧ください。 最小限のコード変更でWpf、Xbap、Silverlightをターゲットにするのに役立ちます（追加の作業量はプロジェクトによって異なります）。

これを使用してWpfおよびXbapアプリケーションを作成する方法は次のとおりです。 PrismおよびXBapアプリケーション

Answer 2

このscorbsの記事でその方法を説明しています、それを実行するためのアプリテンプレートもあります。

_{（ソース： scorbs.com ）}

Answer 3

私は長年、これに対していくつかのアプローチを試みてきました。私にとって最もうまくいったのは、1つのソリューションに4つのプロジェクトがあることです。

• ビジネスオブジェクト、通信、UIを含むdllをビルドするメインプロジェクト。
• 手動と自動の両方の単体テストを含むテストプロジェクト
• Windowsアプリケーション用の小さな.exeプロジェクト
• 小さな.xbapプロジェクト

メインプロジェクトには、PagesもWindowsもありません。UserControlsとカスタムコントロールだけです。 UIを表示するためのサービスクラスもあります。このクラスは、WindowsおよびXBAPプロジェクトでサブクラス化され、表示方法を変更します。いずれの場合も、アプリケーションの起動時にサブクラスが静的プロパティにインストールされます。残りのコードはすべて、この静的プロパティを参照し、そのメソッドを呼び出します。これらのメソッドは、WindowsアプリケーションとXBAPアプリケーションで異なるサービスを実行します。

たとえば、私のサービスクラスには＆quot; ShowDialog＆quot;があります。 FrameworkElementを取得し、ウィンドウ（Windowsアプリケーションの場合）またはページ上のポップアップ（XBAPの場合）としてダイアログスタイルで表示するメソッド。

この手法を使用すると、WindowsアプリケーションとXBAPの間で約98％のコード共有が可能になります。

メインアプリケーションには、クライアントサーバーインターフェイスが定義されており、そのデータオブジェクトにWCF属性が適用されています。サービスにアクセスするためにすべてのコードで使用される静的プロパティがあります。この静的プロパティは（クラスコンストラクターで）具体的な実装クラスのインスタンスに初期化されますが、XBAPプロジェクトのスタートアップコードはこれをWCFクライアントに置き換えます。したがって、XBAPはクライアントサーバーを実行し、Windowsアプリケーションは実際にローカルを作成します呼び出します。いずれの場合も、サーバー側のオブジェクトとまったく同じです。

WCFをインターフェイスとして実装したため、WCFサービスの終了のための単純な.svcファイルに過ぎず、別のコード生成やプロキシ/スタブコードのリンクは必要ありませんでした。