Stack Overflow で、C#2.0 から C#3 に変換した人を読んだことがありますが、本当に価値があるのでしょうか?
メンテナンス段階に入る前に 75% で完了したプロジェクトがあります。C#3.0 に切り替える価値があるかどうか自問自答しています。
プロジェクトには Web インターフェイスが含まれるため、メンテナンス フェーズに入る前に Web パーツを開発する必要があります (すべて Windows フォームを使用して内部目的で行われました)。ほとんどの部品は再利用されます (バックエンド)。ほとんどの人は、すでに 75% だったので、それは価値がないと言いましたが、今でも価値がないと思いますか?
最後に、Web インターフェースでプロジェクトを継続しているため、新年には 3.5 に更新します。皆様、ご意見をお寄せいただきありがとうございます。
明確化
C＃3.5は存在しません。C＃1.0、C＃2.0、C＃3.0があります。
次に、.NET 1.0、.NET 1.1、.NET 2.0、.NET 3.0、および.NET3.5があります。
2つを混同しないでください。
C＃3.0とC＃2.0
さて、C＃3.0は移動する価値がありますか？拡張メソッドとLambda式が存在する場合、答えは「はい」です。これらの2つの機能だけで、コードの読み取りと記述が容易になります。これを自動実装されたプロパティ、LINQ、および部分メソッドに追加すると、C＃3.0はそれ自体が有利な動きであることを示しています。
ただし、既存のプロジェクトを移動することは必ずしも有益ではありません。既存の作業を移行することを決定する前に、特に新しいバグと不安定性の導入に関して、長所と短所を比較検討する必要があります。新しいプロジェクトの場合は、C＃3.0から始めます。
いいえ、私はお勧めしません。特に理由がない限り、新しいプロジェクトでのみ 3.5 を開始することをお勧めします。再コンパイルするだけでは、3.5 から何のメリットも得られません。コードは既に (または少なくともその 75% は) 書かれているからです。
将来 3.5 に移行する必要がある場合は、簡単に移行できます。もちろん、コードは 2.0 スタイルになりますが、実行されることは完了です。
新しいプロジェクトを始めるときは、ぜひ切り替えてください。新しいフレームワーク バージョンは非常に興味深いものであり、切り替えを強くお勧めします。
この段階でどうしても欲しい C# 3.5 の機能はありますか? :)
LINQ の場合は、LINQBridgeを試してみてください。Studio のマルチターゲット機能と LINQBridge を使用すると、C# 3.0 コンパイラの全機能を使用してローカル (LINQ to Objects) クエリを作成できますが、プログラムはFramework 2.0 のみが必要です。
これの多くはあなたの個人的なスタイルに帰着すると思います. 私見、C# 3.5 の最高の機能は、実際には次のようになります。
私の OO コードは、まだ少し機能指向に見える傾向があります。したがって、3.5 は大きな利点であり、アップグレードする価値があると確信しています。
さらに優れているのは、3.5 コンパイラを使用してターゲット CLR 2.0 をダウンできることです。これにより、新しいフレームワークを使用して、(3.0/3.5 インストールに対して) 2.0 インストールに基づいて展開できます。プログラムに適切な型を追加する意思がある場合は、このシナリオで上記のすべてを実行できます。
私の意見では、3.5 に切り替えない正当な理由はありません。
本当のキラー機能は、すべての新しい言語機能を使用しながら、ランタイムの古いバージョン (2.0+) を引き続きターゲットにできることです。したがって、新しいラムダ式、拡張メソッド、匿名型、およびその他すべての優れた機能を使用できます。また、顧客がまだ主に 2.0 フレームワークを使用している場合は、引き続き以前のランタイムをターゲットにすることができます。
(以前のランタイム バージョンをターゲットにする必要がある場合は、3.5 フレームワークのクラスを使用しないでください。)
個人的には、デスクトップ GUI アプリを作成している場合、3.0 または 3.5 フレームワークを使用するのが最善の策だと思います。なぜなら、WPF は私が今まで使った中で最高のユーザー インターフェイス ライブラリだからです (長い目で見れば)。
一方、ほとんどの GUI を WinForms で既に作成している場合は、WinForms と WPF GUI 要素の (限定的な) 混在を可能にする 3.5 フレームワークに興味があるかもしれません。既に行った作業をそのまま使用できますが、WPF コントロールを使用して、必要に応じてあちこちにいくつかの優れたタッチを追加できます。
3.5 フレームワークのもう 1 つの便利な機能は、「コレクション初期化子」です。これをチェックしてください：
var myDictionary = new Dictionary<String, String> {
{ "key-1", "value-1" },
{ "key-2", "value-2" },
{ "key-3", "value-3" },
};
いいですね。
もう少し JSON に似ていれば、もう少し良かったのにと思います。でもとにかく便利な機能です。
2.0 ランタイム用にそのコードをイベント ターゲットにすることができます。
私は何度も変換を行いました。主な理由は、ラムダ式からの明確な構文により、コードがわかりやすくなるためです（とにかく私にとっては）。
私はReSharperを使用しています。これにより、ReSharperによるリファクタリングの提案として、かなりの数の機能が表示されるので、新しい3.5機能を簡単に使用できます。このようなツールを使用すると、この移行が非常に簡単になります。
プロジェクトがほぼ完成している場合、おそらく 3.5 の新機能を利用することはできません。新しいプロジェクトの場合、一見の価値があります。
それは、プロジェクト、対象者、目的によって異なります。
.NET Framework 2.0 は、バージョン 3.5 よりもはるかに多くのコンピューターに搭載されていると推測できます。
さらに、.NET 3.5 で必要なもののうち、2.0 では利用できないもの (LINQ など) はありますか? 大量のクエリとデータを扱っている場合は、切り替えます。ただし、繰り返しますが、顧客と、このアプリケーションを近い将来維持するつもりかどうかによって異なります。
コストと利益を比較検討する必要があります。プロジェクトに関する十分な情報が提供されていないため、ここでアドバイスすることはできませんが、次のことを考慮してください。
それは本当にあなたが何をする必要があるかによって異なります。プロジェクトで、明確な構文を持つクエリ オブジェクトである Lambda 式が必要な場合は、3.0 を検討する必要があります。
私は現在、Jon Skeet によるC# In Depthを読んでいます。彼は、C# 1.15 でソリューションをレイアウトするアプローチを取り、2.0 および 3.0 で得られる新しい便利な機能を描写するためにソリューションを進化させます。このタイプの進行は、質問に答えるのに最適な手段です。この本もよく読めるので、すぐに読み終えることができます。
技術的な観点から言えば、これはすべてフレームワーク バージョン 2 であり、達成するのは非常に簡単です。2.0、3.0、および 3.5 の違いは、追加のライブラリ コードとコンパイラの構文糖衣にすぎません。
何かを変更する必要があるわけではありません。フレームワーク 3.5 をターゲットにすることで、より多くのオプションがあります。
チームの観点から: はい、それだけの価値があります。古いコードベースで作業したいと思う人はいません。開発の真っ只中にいる間は、最新の安定したテクノロジを利用することもできます。
3.5 は 2.0 の上に構築されるため、3.5 に直接ジャンプしても問題はありません。
私は...害はなく、新しい機能からいくつかの利点が得られます
やめろと言っている皆さんの気持ちが理解できません。.NET 2.0 が現在の (CLR) ランタイムです。.NET 3.0 と .NET 3.5 はどちらも 2.0 ランタイムで実行されます。.NET 3.5 に移行して C# 3.0 の機能を利用するには、文字通り、プロジェクト プロパティの 1 つのドロップダウンを変更するだけです。(わかりました。LINQ などの 3.5 機能を使用している場合は、ターゲット マシンに 3.5 ランタイムをデプロイします。3.5 のインストールが問題である場合、それはそれほど簡単な答えではありません。)
プロジェクトに拡張機能がある場合は、今すぐ最新バージョンの .NET に切り替えるのが良いかもしれません。
正当な理由がない限り、私は何も変更しません。つまり、2.0 では回避できないバグがあります。
プロジェクトのこのような遅い時点でフレームワークをアップグレードすると、現時点では必要のない問題が発生する可能性があります。