長い間 Windows 8 にアップグレードできないお客様を放置するわけにはいきません。ただし、アプリの「タブレット」/「タッチ」バージョンの需要があります。
では、単一のコード ベースから、Windows 8 上の Metro を使用したタッチと現在の顧客の両方をサポートするにはどうすればよいでしょうか?
WPF が出てきたとき、マイクロソフトはそれ以来多くの「プッシュ」を行い、Windows XP で動作するようにしました。
(XP のサポートは終了しているため、XP で動作するソリューションは期待できません。)
関連項目: ARM バージョンの Windows 8 では、Metro (WinRt) スタイルのアプリしか実行できませんか?
最善の答えは、Windows 7 と Windows 8 の Metro スタイルで同じアプリケーションを実行したくないということです。マウスとキーボード (Windows 7) で最適に機能する UI は、タッチ ファースト プレゼンテーションでは適切に機能しません。2 つの異なる世界の UI を再考することが重要です。
とはいえ、多くのコードを共有したい場合は、次の 2 つのオプションがあります。1) 主に JavaScript/HTML5 で記述します。これにより、多くのアセット (特にビジネス ロジック部分) を再利用できます。2) (デスクトップ) Silverlight に書き込みます。Silverlight XAML は、Windows XAML に最も近いものです。WPF は遠く離れており、後でさらに再作業が必要になります。
いずれの場合も、クロスプラットフォーム コードを記述する際に使用される原則を確認して従う必要があります。プラットフォームの依存関係を理解し、間接的な境界の背後に分離します。変更が必要なすべてのコードをローカライズしたいと考えています。たとえば、Windows.System.Storage 呼び出しに変更する必要があることがわかっている .Net System.IO.File API への呼び出しを、コード全体に分散させたくありません。代わりに、後で変更できる 1 つの関数にローカライズする必要があります。
他の人が指摘しているように、Win8 Metro と Win7 / Vista Desktop でまったく同じアプリケーションを動作させることは望ましくありません。適切な設計パターンを使用してアプリケーションを適切に構成すると、必要なさまざまなバージョン間でかなりの量のコードを共有できます。Win8 バージョンでは WinRT を使用し、Win7/Vista では Silverlight または WPF を選択できます。
これがどのように行われるかを示すいくつかの記事を公開しました。それらにはかなりのコードも含まれています。
私が考えることができる唯一の方法は、アプリケーションを HTML5/CSS3/JS で実装し、WinRT API をできるだけ使用しないことです。これは、アプリが正確に何をする必要があるかによっては実現可能かもしれません (たとえば、ポータブル 2D グラフィックスは簡単ですHTML5 キャンバスを使用)。
次に、Win8 の場合、これを Metro Web アプリとしてパッケージ化します。Win7 以下の場合、選択したブラウザー (IE9 ではなく、XP では動作しないため、Firefox または Chrome) を埋め込み、すべてのクロムを非表示にして、その埋め込みブラウザー内に HTML5 アプリを読み込む単純なアプリを作成します。
Windows 8に導入された再設計のレベルにより、MicrosoftがMetroスタイルのアプリケーションフレームワークを過去のリリースに戻すことはほとんどありません。
私はこの点でザックに同意します。Microsoftは、Windows 8（およびWindowsランタイム）の導入により、テクノロジーと使いやすさの両方を確実に推進しているようです。
MetroUIは別のUIパラダイムです。現在のWin32コントロール（WPFコントロールを含む）を使用している場合、アプリケーションはMetroで実際に古くなっているように見えます。これを修正する唯一の方法は、Metroコントロールを使用してUI（MVVMデザインのViewクラス）を再実装することです。ただし、C＃および.NET APIの大部分は、この新しい環境では第一級市民です。アプリケーションの残りの部分は問題ないはずです。
すでにかなり大きなアプリケーションを想定しているので、最善の解決策は、ビューをmodel-viewmodelから分離することです。その後、Windows 8 Metroのフルスクリーンタッチフレンドリーな素晴らしいインターフェイスと「クラシック」ウィンドウインターフェイス（過去x年間行ってきたこと）の両方を開発し続けることができます。優れた分離、設計、および優れたソース管理ソリューション（つまり、Perforce）を使用すると、多くのコードベースを共有できます。
Windowsランタイムに関する最近の質問に対する回答に加えて、Bill Wagner（私がフォローしている多くのC＃ブロガーの1人）がWinRTと管理言語の会議セッションに関する要約を投稿しました。よく読んで、数分あればお勧めです。彼の要約が（最後のFAQで）明らかにしたことの1つは、使用するフレームワークのブランドとしての.NETの将来がWindowsランタイムに置き換えられることでした。
ビルのブログ投稿からの別の作品：
一部の.NETAPIはWinRT用に変更されています。完全なリストはありませんが、まだあるかどうかはわかりません。他のAPIはWinRTを介して公開されません。（Metro / WinRT APIとしてではなく、.net APIとして引き続き利用できます。）
Windows 8 に移行した再構築のレベルにより、Microsoft が Metro スタイル アプリケーション フレームワークを過去のリリースに戻す可能性は低いです。
Pavel が言ったように、アプリケーションで WinRT ライブラリをできるだけ多く使用しないようにすれば、それは可能ですが、繰り返しになりますが、通常の Web アプリを構築していることになります。