現在、vs 2005 (winforms) から vs 2008 (wpf) への移行について議論することを考えています。私の主なポイントは、新しい UI デザイン機能です。
2010 年になっても同じことをしなければならないためだけに、すべてをアップグレードするために多大な労力を費やすことになるのではないかと少し心配しています。したがって、これは 2008 をスキップして、リリースされたらすぐに 2010 を採用することも検討することにつながります。
同じような状況になった人いますか？
また、賛否両論も歓迎します。
乾杯。
個人的には、2010 は単なる拡張機能であり、Visual Studio のデザイン時の WPF サポートの拡張であるため、2008 に移行することはかなり安全だと思います。したがって、移行はそれほど複雑ではありません。WinフォームまたはASP.NETプロジェクトの2005年から2008年のアップグレードのようなもので、簡単です。
既存のフレームワーク/システムに「行き詰まる」ことがないように、遅かれ早かれアップグレードする方が良いと思います。最終的に置き換えるものの上に構築し続けると、経営陣に移動を正当化することがますます難しくなります。
私があなたの立場にあったら、私は今ジャンプします。すでに慣れなければならない多くの新機能に慣れることで、2010年のジャンプダウンの影響を最小限に抑えることができます。さらに、2010年が利用可能になる前に、何ヶ月にもわたってより優れたパフォーマンスと機能を楽しむことができます。
WinformsとWPFは違いの世界です。2005年から2008年への移行を検討するよりもはるかに大きな変化です。2008年にアップグレードする主な理由としてはありません。また、プロジェクトの範囲や、WPFが本当に最善の方向性であるかどうかもわかりません。製品。または、Expression Blendがすべてのツールである場合は、これらのUIを実行するために必要です。
WPFピッチを提案する代わりに、すぐに得られる本当のメリットに焦点を当てます。2008ではマルチターゲティングを使用できるため、2005年に構築に使用したすべてのアプリケーションを構築し、2.0フレームワークをターゲットにすることができます。私の経験では、2008年の方が速く、リファクタリングの改善は素晴らしい追加です。2008年には、他にもたくさんの新しい改善点があり、すぐに使用でき、1日目から使用を開始できます。
2010年のヘッドアーキテクトであるRicoによると、2010年にはさらに豊富なマルチターゲティングが可能になり、2010年を早期に採用でき、最初からCLRバージョン4を使用する必要がなくなります。
私は同じ状況にあり、MSDN サブスクリプション ルートをたどることを選択しました。そこでは、新しい開発ツールがリリースされるたびに入手できます。移行テストに使用する「次のバージョン」のコンパイラに使用する予備のマシンがあるため、少なくとも、決定を下す必要があるときに何を期待するかはわかっています。これは私にとってはうまく機能します。適切な仮想化設定があれば、さらに良いと思います。
新しいコンパイラ バージョンは、私のビルドを壊すことはありませんでしたが、多くの自動化されたテストとアドインの生産性向上ツールに損害を与えました。基本的。新しいバージョンへの移行が引き起こす可能性のある損害を確認するために、何らかの回帰テストが必要です。
あなたの質問は私にはあまり意味がありません。既存のアプリケーションを Winform から WPF に移行する必要があるかどうか尋ねていますか? それとも、新しい WPF アプリケーションの作成を開始したいだけで、既存の Winform プロジェクトを引き続き使用したいですか?
いずれにしても、Visual Studio 2005 から 2008 への移行は非常に簡単です。既存の Winform プロジェクトは、数秒かかる変換を要求し、私にとって失敗したことはありません (過去数か月間に数十のソリューションと数百のプロジェクトが変換されました)。
ただし、これは Winforms および WPF とは関係ありません。
WPF アプリの構築を開始する場合、VS 2010 を待つ必要はありません。VS 2008 は、両方のアプリケーション タイプを優れたサポートを備えています。
VS 2008 を今すぐ採用することを提案する人たちに同意します。ただし、考慮すべきことの 1 つは、WPF にはかなりの学習曲線が伴うということです。私は WPF と Silverlight に少し触れたことがありますが、WinForms モデルから完全に「考え方が変わった」と感じています。幸運を。
現時点では、できるだけ早く最新バージョンにアップグレードすることを実践しています。アプリケーション開発者にとっては、独自の落とし穴があります。.Net Framework 3.5はほとんどのコンピューターにありません。また、20 MBのブートストラップインストーラーを出荷すると、必要なファイルをダウンロードするためにアクティブなインターネット接続が必要になります。フルインストーラーは198MBで、気に入らないのですが、ソフトウェアと一緒に出荷する必要があります。
Web開発者にとっては、問題の解決は簡単ですが、サーバーで問題が機能するようにすることだけを心配する必要があり、ユーザーにとっては自動的に機能します。したがって、Webソリューションを作成している場合は、移行が簡単だと思います。
アプリケーションソフトウェアを作成している場合は、移行が提供する利点と、展開スキームに加える変更を比較検討する必要があると思います。何人の人がこれに同意するかはわかりませんが、アプリケーション開発者は1つ遅れてアップグレードする必要があると思います。
ここには、見逃してはならないと思う根本的なプロセスの質問があります。
開発ツールと本番環境をアップグレードする適切な時期はいつですか？
一方では、2008年をスキップできますが、これにより、2010年がいつ採用されるかという疑問が生じます。最初のリリース、最初のサービスパックのリリース、またはその他のマイルストーンですか。これにより、2.0フレームワークを使用して2005に固定されたままで、他のフレームワークが他のフレームワークに移行した場合、より多くのレガシーコードが作成される可能性があります。2008に切り替えた場合でも、2.0フレームワークをターゲットにできるため、.Netフレームワークのアップグレードが個別に行われる可能性があります。このキャンプのもう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.66GHzのデュアルコアプロセッサと160GBのハードドライブがあります。さらに10年間で、数百GBのRAMを搭載したマシンを使用できますか？それはばかげているように思えるかもしれませんが、私が他の少数の開発者とマシンを共有している場合、私たち全員の間で大量のメモリを分割することは理にかなっているかもしれません。