複数の AppDomains で実行される WPF UI の作成を検討しています。アプリ ドメインの 1 つはアプリケーションを実行し、残りの AppDomain は一連のユーザー コントロールとロジックをホストします。もちろん、この考え方は、これらのユーザー コントロールとロジックをメイン アプリケーションからサンドボックス化することです。
MAF/System.AddIn を使用してこれを行う例を次に示します。他の人はこれについてどのような経験をしていますか? このソリューションは、1 つのユーザー コントロール内で発生する可能性がある RoutedEvents/Commands をどのように処理し、これらを AppDomains 間で適切にシリアル化しますか? WPF リソースはどうですか? AppDomain 間でシームレスにアクセスできますか?
ここで同様の質問に答え、WPF 用に編集しました。コンパイル エンジンがどのように動作するかの興味深いプロパティを使用して、ディスパッチャー ポンプをレンダリング コンテキストの 1 つにテール コートできます。それは本当に軽量のオプションです。
また、エンタープライズ ライブラリとユニティについてご存知でしょうか。
WPF アプリケーション ブロックがあるので、そのパターンを使用するのはそれほど苦痛ではありません ;) しかし、彼らは「苦痛なしで得られるものは何もない」とは言いませんか?
CAB (Composite UI Application Block) もあり、統合されています。WPF SDKの人々は、Silverlight & WPF プラットフォームを作成しました。（別名プリズム）。
そうそう、リソースについても尋ねましたか? Application クラスでリソースを手動でロードすることを好みます。サブフォルダーに ResourceDictionary があり、その ResourceDictionary に MergedDictionaries をロードしているとします。そのため、Application クラスで "my-res-dir/MergedDictionaryLoader.xaml" を (コードまたは xaml で) ロードすると、今後の MERGEDDICTIONARIES のすべてのロードは "my-res-dir" からロードされます。
あなたが私に尋ねると、非常識なことですが、プロセスの現在のディレクトリは変更されていないので、すべての追加ディレクトリに「my-res-dir/foo.xaml」を指定する必要があると思います。ただし、これは事実ではありません (これは少なくともどこにも非常によく文書化されているとは思わず、バグと見なす必要があります)。
そのため、WPF リソース ディクショナリの読み込みは、現在のXAMLがあるディレクトリに基づいて行われることを覚えておいてください。そのため、「my-res-dir/MergedDictionaryLoader.xaml」内から Source="foo.xaml" を指定します。私はURIパック/絶対構文で遊んだことさえありますが、それがあまりにも直感的であることに気づいたことはありません.