質問

現在、vs 2005 (winforms) から vs 2008 (wpf) への移行に関する議論を提案することを検討しています。私の主なポイントは、新しい UI デザイン機能です。

すべてをアップグレードするために多大な労力を費やし、2010 年になったときに同じことをしなければならないのではないかと少し心配しています。したがって、2008 年をスキップし、2010 年がリリースされたらすぐに採用することも検討する必要があります。

同じような状況になった人はいますか?

賛否両論も歓迎です。

乾杯。

役に立ちましたか?

解決

個人的には、2010年はその上にある拡張機能であり、WPFのVisual Studio設計時サポートの拡張機能であるため、2008年に行くことはかなり安全だと思います。したがって、移行はそれほど複雑ではありません。 Win-FormsまたはASP.NETプロジェクトの2005-2008アップグレードのようなもので、これは簡単なものです。

「遅くなった」という事態に陥らないように、後より早くアップグレードする方が良いと思います。既存のフレームワーク/システムで。最終的に置き換えるものに基づいて構築を続けると、経営陣が動くことを正当化することがますます難しくなります。

他のヒント

私は同じ状況にあり、MSDNサブスクリプションルートに進むことを選択しました。MSDNサブスクリプションルートでは、新しい開発ツールがリリースされるたびに入手できます。私は、移行テストに使用するコンパイラの「次のバージョン」に使用する予備のマシンを持っています。したがって、少なくとも、決定を下す必要があるときに何を期待するかを知っています。これは私にとってはうまく機能します。まともな仮想化設定があればなおさらです。

新しいコンパイラーのバージョンは私のビルドを壊しませんでしたが、多くの自動テストとアドイン生産性ツールを傷つけました。基本的に。新しいバージョンへの移行が引き起こす可能性のある損傷を確認するために、何らかの種類の回帰テストが必要です。

あなたの質問は私にはまったく意味がありません。既存のアプリケーションをWinformsからWPFに移行するかどうかを尋ねていますか?または、新しいWPFアプリケーションの作成を開始するだけで、既存のWinformプロジェクトで作業したいですか?

どちらの方法でも、Visual Studio 2005から2008への移行は非常に簡単です。既存のWinformプロジェクトは、数秒かかり、私にとって決して失敗したことのない変換を要求します(過去数か月で変換された数十のソリューションと数百のプロジェクト)。

ただし、これはWinformsおよびWPFとは関係ありません。

WPFアプリの構築を開始する場合、VS 2010を待つ理由はありません。VS2008は、両方のアプリケーションタイプに対して優れたサポートを提供しています。

VS 2008を現在採用することを提案している人々に同意します。考慮すべきことの1つは、WPFにはかなり高い学習曲線が付属していることです。私はWPFとSilverlightに少ししか触れていませんでしたが、それらが完全な「心の変化」であることがわかりました。 WinFormsモデルから。幸運を祈ります。

私があなたの靴を履いていたなら、今すぐにジャンプします。既に慣れなければならない多くの新機能に慣れることで、2010年の急降下の影響を最小限に抑えることができます。さらに、2010年が利用可能になる前に、何ヶ月もパフォーマンスと機能を向上させることができます。

WinformsとWPFは違いの世界です。 2005年から2008年への移行を検討するよりもはるかに大きな変更です。2008年にアップグレードする原動力となる理由はありません。また、プロジェクトの範囲と、WPFが本当に最適な方向であるか製品。あるいは、エクスプレッションブレンドがすべてのツールである場合、これらのUIを実行するために必要です。

WPFピッチをピッチングする代わりに、すぐに得られる本当のメリットに焦点を当てます。 2008ではマルチターゲティングが可能なため、2005年にビルドするために使用したすべてのアプリケーションをビルドし、2.0フレームワークをターゲットにすることができます。私の経験では、2008年の方が早く、リファクタリングの改善は素晴らしい追加です。 2008年には、すぐに使用でき、1日目から使用を開始できる新しい改良点が数多くあります。

2010年の主任アーキテクトであるRicoによると、2010でより豊富なマルチターゲティングが可能になります。

現時点では、できるだけ早く最新バージョンにアップグレードすることを実践しています。アプリケーション開発者にとっては落とし穴がありますが、例.Net Framework 3.5はほとんどのコンピューターには見当たりません。20MBのブートストラップインストーラーを出荷すると、必要なファイルをダウンロードするためにアクティブなインターネット接続を要求します。完全なインストーラーは198 MBで、気に入らないのですが、ソフトウェアと一緒に出荷する必要があります。

Web開発者にとっては、問題は簡単に解決できますが、サーバーで問題が発生することだけを心配するだけで、ユーザーにとっては自動的に機能します。したがって、Webソリューションを作成している場合は、移行が簡単だと思います。

アプリケーションソフトウェアを作成している場合、移行が提供する利点と移行スキームに加える変更を比較検討する必要があると思います。これに何人の人々が同意するかはわかりませんが、アプリケーション開発者は1つアップグレードする必要があると思います。

ここには、見逃すべきではないと思われる根本的なプロセスの問題があります。

開発ツールと運用環境をアップグレードする適切な時期はいつですか?

一方で、2008 年をスキップすることもできますが、そうすると 2010 年がいつ採用されるのかという疑問が生じます。最初のリリース、最初のサービス パックのリリース、またはその他のマイルストーンのとき?これにより、2.0 フレームワークを使用して 2005 に固執し、他のフレームワークに移行した場合、より多くのレガシー コードが作成される可能性があります。2008 に切り替えた場合でも、引き続き 2.0 フレームワークをターゲットにすることができるため、.Net フレームワークのアップグレードが個別に発生する可能性があり、これを好む人もいるかもしれません。このキャンプのもう 1 つの重要なポイントは、バージョン間の違いを評価してどちらを移行する価値があるかを判断するための調査を誰が行うかということです。

もう 1 つは、過去 10 年間の Visual Studio リリースがおよそ 2002、2003、2005、2008 年であることから、3 年ごとにアップグレードの準備をするという継続的な戦略があることを示唆することもできます。まったく固定されたままになるのではなく、継続的な進化が起こっているので、これはより良いアプローチであるように私には思えます。この場合、移行が大きなステップとみなされる最初のケースに比べて、新しいツールがすぐに登場するため、新しい機能が使用される可能性がありますが、この場合は常に移行を検討しているため、それほど大きなステップではありません。 2~3年。

もちろん、これを言っている間、私の古い作業マシンには Visual Studio 2003、2005、および 2008 がインストールされているため、私は後者の陣営に属しているのですが、これは私にとっては理にかなっています。10 年前、私の仕事用マシンには NT 4.0、Pentium II 333 MHz プロセッサ、64 MB の RAM、および 4 GB のハード ドライブが搭載されていましたが、1 つのパーティションをそれほど大きくすることができないため、2 つのパーティションにする必要があったことを思い出します。現在、私の仕事用マシンには 4 GB の RAM、2.66 GHz デュアル コア プロセッサ、160 GB のハード ドライブが搭載されています。あと 10 年後には、数百 GB の RAM を搭載したマシンを手に入れることができるでしょうか?それはばかげているように思えるかもしれませんが、他の数人の開発者とマシンを共有している場合、大量のメモリを全員で分割するのが理にかなっているかもしれません。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top