この質問は他の質問と似ている可能性があることは知っていますが、VB6開発者がC＃に切り替える必要がある理由を実際に探しています。
私の会社は最近、プロジェクトをC＃で作成することを承認したため、VB.Netプログラマーがたくさんいますが、VB6を使用しているレガシーアプリ開発者もいます。これらのアプリを.NetWebアプリに書き直す時間枠があります。だから、彼らが新しいことを学ばなければならないことに関係なく。
今日の開発者の1人は、「なぜC＃に切り替える必要があるのか」と具体的に尋ねました。
私は、コミュニティがC＃がC＃の例の約80％を使用する方法であると主に決定したと答えました。私はVB.Netプログラマーであり、ついにC＃に歯を食いしばることに興奮していますが、私はとても新しいので、「なぜ」に答えられるかどうかわかりません。質問。私の理由はそれを学びたいからです。
したがって、VB対C＃に降りることなく、これらの開発者に神経を落ち着かせるために送信できるリソースがあるかどうか、私は本当に興味があります。
ご意見をお待ちしております！
.NETへの移行が進む限り、これまでにないほど遅くなります。私のアドバイスによると、あなたのマイレージは変わるかもしれません、それはあなたがそれのために払っているすべてのペニーの価値があります！
私はあなたが正しい選択をしていると個人的に信じています。VB開発者にとっての最初の本能は、VB.NETに切り替えることです。それは完全に合理的に聞こえますが、私の意見では、それは間違った選択です。切り替えの理由を2つのカテゴリに分類する必要があります。.NETに切り替える理由とC＃に切り替える理由です。
VB6経由で.NETに切り替える理由：
VB6でのマルチスレッド化は、プログラミングの観点からは技術的には可能ですが、IDEを使用する場合はほぼ不可能です。
VB6で64ビットのネイティブアプリケーションを作成できるとは思いません。それは多くを除外します。
VB6には新しい拡張機能はありません。
OK、考えられる理由はたくさんあります。おそらくそこで止まります。
VB.NETではなくC＃に切り替える理由
開発者は、VB.NETに慣れているという誤った感覚に陥る可能性があります。つまり、完全な概念を理解せずに、VB6で行ったようにリソースを処理します。例：リソースを解放する魔法の方法であると信じて、オブジェクトをNothingに設定するVB.NETへの新しい変換をよく目にします。そうではない。
ほとんどの例が現在C＃になっているのは事実です。さらに重要なことに、Jeff Richterの本は現在C＃のみです。.NETが実際にどのように機能するかを理解したい場合は、IMOの本がほぼ必須です。
.NETでは、特にLinqで操作する場合は、常にラムダ式を使用することがわかります。IMO VBの冗長性は、これまでになかった方法で、ここでの理解と読みやすさの障壁になります。foo.Select(x => x > 50)ほぼすべての標準で、よりもはるかに流暢で読みやすくなっていfoo.Select(Function(x) x > 50)ます。式が複雑になるにつれて、状況はさらに悪化します。
VB6での最悪のプラクティスのいくつかは、C＃では不可能であるか、少なくともアクセスしにくいものです（ReDimPreserveやOnError Resume Nextなど）。
VBにはいくつかの構文が含まれているため、汎用CLRライブラリを作成するときに使用するのはかなり面倒で混乱を招きます。たとえば、C＃では、角かっこ[]付きのインデクサーを使用します。VBでは、parensを使用します。そのため、サブルーチンのユーザーは、それがインデクサーなのか関数なのかを判断するのが非常に困難になります。誰かがVBの外部でライブラリを使用しようとした場合、違いは重要ですが、VB開発者は、類似しているため、関数としてインデクサーとなるサブルーチンを作成する傾向があるかもしれません。
これに関するデータはありませんが、優れたプログラマーを雇おうとしている場合、一般的に、C＃を介してVB.NETを作成しているショップで働く傾向が少ないでしょう。彼らは通常、同僚が生成するコードが標準以下の.NETコードである可能性が高いことを恐れています。率直に言って、VB.NET開発者とコミュニティでのコードの品質に対する不名誉があります。三。私はそれを言いました。炎を始めましょう...
脚注として、私の観点からは、VB.NETはMSにとって本当に逃した機会でした。本来あるべきことは、最初から動的な呼び出しと高品質のCOM相互運用機能を使用して、古いVB6コードを.NETの世界にシームレスに変換する方法でした。最終的には、より冗長な構文を備え、下位互換性がほとんどまたはまったくないC＃の機能セットのクローンに近いものになりました。本当に悲しい。それは長い間多くの組織を.NETから締め出しました。それからまた、多分それは過去からの「冷たい七面鳥」のきれいな休憩を強制しました...
私は過去にたくさんのVB6を実行し、多くのC / C ++を実行しましたが、.NETの大規模な移行が行われたとき、C＃が最適な方法であることに疑いの余地はありませんでした。そうは言っても、VB6の人たちが実際に学ばなければならないのは、.NETとCLR（ダムCOMフロントエンドではなく適切なオブジェクト指向ランタイム）であり、構文ではありません。それに焦点を合わせて、宗教戦争を回避してください。
これはあなたの質問に答えないかもしれません、実際それはあなたの応答と矛盾し、あなたの友人が正しいことを証明するかもしれません、しかしここにVB.NETとC＃の間の類似点（そして相違点）の良いリストがあります：
このリストを下に行くと、2つの言語がどれほど似ているかに気付くでしょう。新しいバージョンごとに、切り替える理由がますます少なくなっている可能性があります。しかし、結局、切り替えを行うと、ウィキペディアの記事は、C＃がVB.NETよりも優れている点をほぼ要約しています。
VB.netイベントの構文はC＃よりもはるかに優れているようです。クラスがサブスクライブしているすべてのWithEventsハンドラーのサブスクライブを解除するか、他のオブジェクトがそのイベントに対して持つすべてのサブスクリプションを強制終了する手段がないため、イベントリークを回避するのは少し困難ですが、その点ではC＃よりも悪くありません。 。
また、vb.netでは、Finallyハンドラーに、実際にキャッチしなくても、Tryブロックで発生した例外（存在する場合）を認識させることができます。Finalブロックで例外が発生した場合、元の例外をCleanupFailedExceptionに含めることができます（Finallyブロックで発生した他の例外と一緒に）。それは素晴らしい利点のようです。
「開発者は、VB.NETに慣れているという誤った感覚に陥る可能性があります。つまり、完全な概念を理解せずに、VB6で行ったようにリソースを処理します。」（@Markle）
私はこれまで議論にこれを使用したことがありませんが、それは非常に良い点です。たくさんのnew-to.netVBプログラマーによって書かれたVB.NETアプリを手にしたとき、古いVisualBasic名前空間へのレガシー互換性呼び出しが散らばっていました。CStr（）、VbNewLine、Mid（）など...レガシーコード変換をサポートするように設計されていない言語で作業すると、これらの遺物を使用できなくなります。（レガシー名前空間FYIへの参照も削除します。）
私はVB.NETとC＃をかなり定期的に切り替えています。VBからC＃に移行するときはいつでも、「これは違います。調整には数分かかります」と思います。C＃からVBに移行するときはいつでも、「これは非効率的なプログラミング言語です。入力が多すぎるので、面倒です」と思います。
他の回答は、技術的なポイントをカバーするのに良い仕事をしたと思います。また、vb6開発者には、c＃を対象とした本や、c＃に関するSOに関する質問が増えているだけでなく、おそらくもっと重要なこととして、求人情報も増えていることを指摘しておきます。
SOのキャリアに関するクイック検索：
VB6開発者がC＃に切り替える必要がある理由
他の人はVB.NETよりもC＃の技術的な理由を挙げていますが、あなたは人の問題を扱っていると思うので、開発者がそれを好む最も説得力のある理由であると私が思うものを提供します：
また
C＃がVB6本体に対して持つ最大の利点は、継承である必要があります。
（わかりました、公平を期すために、それは私の個人的なお気に入りなので、私は完全に偏っています。）
その他の利点：
そして、以下は言語自体よりも.NETプラットフォームに関連しています。
最後に、人気の議論は常に厄介です（人気のある<>良い）が、それはそれぞれのコミュニティのサイズ、したがってそこにどのような助けがあり、業界が一般的に何に向かっているのかについての考えを与えます。
SOに関する質問：
技術的/社会的利点がよりビジネス指向であることを除けば、VB6のメインストリームサポートはすでに終了しており、確かに高価な拡張サポートはまもなく終了します。この場合、新しいプラットフォームに移行することは、よりビジネス的に意味があります。また、IDEはMicrosoftによってサポートされなくなったため、問題が発生した場合はSOLになり、光沢のある新しいラップトップにインストールすると、楽しい体験が得られない可能性があります。
すべてのアプリケーションを移植する必要はなく、comで公開された.Netアセンブリに置き換える必要のある部分のみを非推奨にすることに注意してください。
一方、古いプラットフォームから新しいプラットフォームへのソフトウェアの移植の経験があると、新しいプラットフォームを進んで学ぶことができれば、これらの人は豊かになります。
VB6は完全にオブジェクト指向ではなく、適切なコレクション/構造のセットがありません。VB.NetとC＃はどちらも完全にオブジェクト指向であり、.NETの一部として適切なコレクションクラスのセットが含まれています。.NET 2は、さらに柔軟性を高めるためにジェネリックも追加しました。
私は、VB.Netが少し不必要だと思う人たちに同意します-それはVB6の問題を修正し、C＃と並んで少し「私も」になってしまいました。そうは言っても、私は多くのCOM相互運用機能を実行し、VB.Netの昔ながらのON ERRORが、タイムアウトと関数の再試行を処理する便利な方法を構築していることに気付きました。あなたはtry...catchでそれを行うことができますそれはもっと複雑です。
SOに関する質問：
[C#]: 116,337
[VB.NET]: 11,740
[VB6]: 1,897
それは何も証明しません。VB6は、SOが存在するずっと前から存在していました。すべての優れたVBプログラマーは、知っておくべきことを学び、MSFTはVB6を廃止しました。新しいMSFT初心者のほとんどは、BASIC（まだ存在している-Xojoを見てください）ともちろんMSFTマーケティングに対する不合理な憎しみのために、C＃に群がりました。しかし、Windows8プラットフォームのC++と比較して、C＃の変更が短いと彼らはどのように感じていますか？（例えば、XNAはなくなっています）。市場は、VB.netよりもC＃をかなり要求しています。