私は大規模な C# アプリケーション (約 450,000 行のコード) を扱っていますが、デスクトップ ヒープと GDI ハンドル リークの問題が常に発生しています。WPF はこれらの問題を解決しますが、アップグレードする最善の方法が何であるかはわかりません (これには長い時間がかかると予想されます)。アプリケーションにはいくつかのフォームしかありませんが、これらには、プログラムによって決定されるさまざまなユーザー コントロールのセットを含めることができます。
これは社内アプリであるため、リリース サイクルは非常に短いです (通常 3 週間のリリース サイクル)。
段階的なアップグレード パスはありますか。
WPFホストを作成することから始めることができます。
次に、<WindowsFormHost/>コントロールを使用して現在のアプリケーションをホストできます。次に、WPFで新しいコントロールのライブラリを作成することをお勧めします。一度に1つずつ、コントロールを作成できます（ユーザーコントロールではなく、カスタムコントロールにすることをお勧めします）。各コントロールのスタイル内で、<ElementHost />コントロールを使用して、「古い」ウィンドウフォームコントロールを含めることから始めることができます。次に、時間をかけて各コントロールを完全なWPFとしてリファクタリングおよび再作成できます。
コントロールラッパーを作成し、アプリケーションのWPFホストを設計するには、まだ初期の努力が必要だと思います。アプリケーションのサイズやユーザーコントロールの複雑さはわかりません。そのため、どれだけの労力がかかるかわかりません。相対的に言えば、この方法でアプリケーションをWPFで起動して実行する方が、労力が大幅に少なく、はるかに高速です。
ただし、コントロールが相互にオーバーレイする際に問題が発生する可能性があるため、これを実行して忘れるだけではありません（WindowsフォームはWPF、特にOHPフィルムやその他のビジュアルではうまく機能しません）
このプロジェクトの状況について更新するか、より具体的なガイダンスが必要な場合は、より技術的な情報を提供してください。ありがとう ：）
作品に多くのユーザーコントロールを使用していますか? WPF は winform コントロールをホストできるため、パーツを部分的にメイン フォームに取り込むことができます。
WPF を使用すると、Windows フォームのユーザー コントロールを WPF アプリケーションに埋め込むことができます。これにより、より小さなステップで移行を行うことができます。
WPF ドキュメントのWindowsFormsHostクラスを見てください。
膨大な Winforms アプリを配置するために ElementHost を探しているだけではないと思います。とにかく、それは実際の WPF への移植ではありません。このスレッドの回答を検討してください。Winforms から WPF への移行で克服すべき大きなハードルは何ですか? 、 とても役に立ちます。
.NET2.0WinformアプリケーションのWPFへの移行に関する非常に興味深いホワイトペーパーがあります。.NET3.5アプリケーションへの進化を参照してください。
論文の要約： この論文では、Microsoft.NETアプリケーションを1.x/ 2.xから3.xに進化させるときに直面しなければならなかった思考プロセス、決定、および問題のいくつかについて概説します。クライアントが新しいテクノロジーを採用するのをどのように支援し、それでもビジネスに受け入れられるリリーススケジュールを維持したかを見ていきます。