说服遗留应用程序 VB6 开发人员转向 C#
我知道这个问题可能与其他问题类似，但实际上我正在寻找 VB6 开发人员应该切换到 C# 的原因。
我的公司最近批准了用 C# 编写的项目，因此我们有很多 VB.Net 程序员，但是，我们也有一些使用 VB6 的遗留应用程序开发人员。我们有一个时间框架将这些应用程序重新编写为 .Net Web 应用程序。所以无论什么他们都必须学习新东西。
今天一位开发人员特别问“为什么我们要转向 C#？”
我回答说，社区很大程度上已经决定 C# 是 C# 中大约 80% 的示例的最佳选择。我是一名 VB.Net 程序员，我很高兴终于能开始接触 C#，但是，由于我太新了，我不确定我能回答“为什么？”问题。我的原因更多是因为我想学习它。
因此，在不深入讨论 VB 与 C# 的情况下，我真的很好奇是否可以向这些开发人员发送任何资源来安抚他们的紧张情绪。
期待您的意见！
I know this question could be similar to others but really I'm looking for reasons why VB6 developers should switch to C#.
My company recently approved project to be written in C#, so we have a lot of VB.Net programmers, however, we have some legacy app developers as well that are in VB6. We have a time frame to re-write those apps into .Net web apps. So no matter what they will have to learn new stuff.
One of the developers today specifically asked "why should we switch to C#?"
I responded that the community largely has decided that C# is the way to go with about 80% of the examples in C#. I am a VB.Net programmer and I am excited to finally cut my teeth on C#, however, being that I'm so new I'm not sure I can answer the "why?" question. My reasons are more because I want to learn it.
So without descending into a VB verses C# I really am curious if there are any resources that I can send to these developers to calm their nerves.
Looking forward to your input!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（11）
C# 相对于 VB6 的最大优势就是继承。
（好吧，公平地说，这是我个人最喜欢的，所以我完全有偏见。）
其他优点：
以及以下内容与 .NET 平台比语言本身更相关：
最后，流行度的争论总是令人讨厌（流行<>好），但它确实给出了社区规模的一个概念每种情况都有哪些，因此可以提供哪些帮助以及该行业的总体发展方向。
关于SO的问题：
The biggest advantage C# has over VB6 proper has got to be inheritance.
(OK, to be fair it's my personal favourite, so I am totally biased.)
Other advantages:
And the following are more related to the .NET platform than languages themselves:
Finally, the popularity argument is always icky (popular <> good), but it does give an idea of the community size of each and therefore what help is available out there and what the industry is going towards in general.
Questions on SO:
VB6 不是完全面向对象的，并且缺乏一套像样的集合/结构。 VB.Net 和 C# 都是完全面向对象的，并且包含一组不错的集合类作为 .NET 的一部分。 .NET 2 还添加了泛型以实现更大的灵活性。
我同意那些认为 VB.Net 有点多余的人——它解决了 VB6 的问题，最终与 C# 一起变得有点“我也是”。话虽如此，我做了很多 COM 互操作，并发现 VB.Net 的老式 ON ERROR 构造是处理超时和函数重试的便捷方法。你可以用 try...catch 来做到这一点，只是它更复杂。
VB6 is not fully object oriented and lacks a decent set of collections/structures. VB.Net and C# are both fully object oriented and include a decent set of collection classes as a part of .NET. .NET 2 also added generics for even more flexibility.
I would agree with those who think VB.Net is a bit superfluous - it fixed the problems with VB6 and ended up being a bit of a "me too" alongside C#. Having said that, I do a lot of COM interop and find VB.Net's old fashioned ON ERROR construct a convenient way of handling timeouts and function retries. You can do it with try...catch just it is more complex.
关于SO的问题：
这证明不了什么。
VB6 早在 SO 出现之前就已经存在了。所有优秀的 VB 程序员都学到了他们需要知道的知识，而 MSFT 已经废除了 VB6。大多数 MSFT 初学者都涌向 C#，因为他们对任何 BASIC（仍然存在 - 只需看看 Xojo）以及 MSFT 营销都有非理性的仇恨。
但他们现在对 Windows 8 平台上的 C# 与 C++ 相比变化不大有何感想？ （例如 XNA 消失了）。
市场对 C# 的需求几乎超过了 VB.net。
Questions on SO:
That proves nothing.
VB6 existed long before SO did. All the good VB programmers learned what they need to know and MSFT had done away with VB6. Most of the new MSFT beginners flocked to C# because of their irrational hatred of anything BASIC (that still exits - just look at Xojo) and of course MSFT marketing.
But how do they feel now with C# getting short change compared to C++ on the Windows 8 platform? (eg XNA is gone).
The market pretty much demands C# over VB.net.
就迁移到 .NET 而言，迟到总比不到好！就我的建议而言，您的里程可能会有所不同，但您所付出的每一分钱都是值得的！
我个人相信您正在做出正确的选择。 VB 开发人员的第一反应是转向 VB.NET。这听起来完全合理，但在我看来，这是错误的选择。您确实必须将切换的原因分为两类：为什么切换到 .NET，以及为什么切换到 C#？
为什么切换到 .NET 而不是 VB6：
从编程角度来看，VB6 中的多线程在技术上是可行的，但如果您想使用 IDE，则几乎不可能。
我不相信您可以在 VB6 中创建 64 位本机应用程序。这排除了很多可能性。
VB6 没有新的增强功能。
好吧，我能想到的原因有很多，我可能就到此为止。
为什么要转向 C# 而不是 VB.NET
开发人员可能会陷入一种对 VB.NET 熟悉的错误感觉 - 像在 VB6 中那样对待资源，而不理解完整的概念。举个例子：你经常看到VB.NET的新皈依者将对象设置为Nothing，相信这是释放资源的神奇方法。事实并非如此。
确实，现在大多数示例都是用 C# 编写的。更重要的是，Jeff Richter 的书现在仅使用 C# 语言。如果您想了解 .NET 的真正工作原理，在我看来，他的书几乎是必读的。
在 .NET 中，您会发现始终会使用 lambda 表达式，尤其是在使用 Linq 进行操作时。 IMO VB 的冗长 在某种程度上确实成为理解和可读性的障碍以前根本没有这样的情况：
foo.Select(x => x > 50)从任何标准来看，都比foo.Select(Function) 更加流畅和可读(x)x>50)。随着表达式变得更加复杂，情况会变得更糟。VB6 的一些最糟糕的做法在 C# 中是不可能的，或者至少很难实现（例如 ReDim Preserve 和 On Error Resume Next）。
VB 的一些语法使其在创建通用 CLR 库时使用起来非常麻烦和混乱。例如，在 C# 中，您可以使用带有括号 [] 的索引器。在 VB 中，您使用括号。这使得子例程的用户很难判断它是索引器还是函数。如果有人尝试在 VB 之外使用您的库，则差异将很重要，但 VB 开发人员可能倾向于创建应该作为函数的索引器的子例程，因为它们看起来很相似。
我没有这方面的任何数据，但如果您想雇用一批优秀的程序员，最好的程序员通常不太愿意在用 C# 编写 VB.NET 的商店工作。他们通常担心同事生成的代码可能是不合格的 .NET 代码，坦白说，社区中存在针对 VB.NET 开发人员及其代码质量的耻辱。那里。我说过了。让火焰开始吧...
作为脚注，从我的角度来看，VB.NET 对于 MS 来说是一个真正错失的机会。它应该是一种将旧的 VB6 代码无缝转换到 .NET 世界的方法 - 从一开始就具有动态调用和高质量的 COM 互操作。它最终成为 C# 功能集的近乎克隆，具有更冗长的语法，并且几乎没有向后兼容性。悲伤，真的。它使许多组织长期无法使用 .NET。话又说回来，也许它迫使我们与过去“冷火鸡”彻底决裂……
As far as the migration over to .NET goes, better late than never! As far as my advice goes, your mileage may vary, it's worth every penny you're paying for it!
I personally believe you are making the correct choice. The first instinct for VB developers is to switch to VB.NET. That sounds entirely reasonable, but in my opinion, it's the wrong choice. You really have to break down the reasons for the switch into two categories: Why switch to .NET, and why switch to C#?
Why switch to .NET over VB6:
Multithreading in VB6 is technically possible from a programming perspective, but just about impossible if you want to use the IDE.
I do not believe you can create a 64-bit native application in VB6. That rules out a lot.
No new enhancements are being made to VB6.
OK, there are so many reasons I can think of, I'll probably just stop there.
Why switch to C# instead of VB.NET
Developers may be lulled into a false sense of familiarity with VB.NET - treating resources like they did in VB6 without understanding the full concepts. An example: you often see new converts to VB.NET setting objects to Nothing, believing that it's a magical way to release resources. It is not.
It's true that most examples are now in C#. More importantly, Jeff Richter's book is only in C# now. If you want to understand how .NET really works, IMO his book is pretty much mandatory.
In .NET, you'll find that you will use lambda expressions all of the time, especially when operating with Linq. IMO VB's verbosity really becomes a barrier to comprehension and readability here, in ways where it simply wasn't before:
foo.Select(x => x > 50)is, by just about any standard, much more fluent and readable thanfoo.Select(Function(x) x > 50). It gets worse as the expressions get more complex.Some of the worst practices with VB6 are impossible or at least much less accessible in C# (such as ReDim Preserve and On Error Resume Next).
VB is saddled with some syntax which makes it pretty cumbersome and confusing to use when creating general-purpose CLR libraries. For example, in C#, you use indexers with brackets[]. In VB, you use parens. That makes it pretty difficult for the user of a subroutine to tell if it's an indexer or a function. If someone tried to use your library outside of VB, the difference would be important, but a VB developer might be inclined to create subroutines which should be indexers as functions, since they look similar.
I don't have any data on this, but if you are trying to hire a good set of programmers, the best ones will generally be less inclined to work in a shop which writes VB.NET over C#. They usually fear that the code their colleagues will be generating is likely to be substandard .NET code, and let's be frank here -- there's a stigma against VB.NET developers and the quality of their code in the community. There. I said it. Let the flames begin...
As a footnote, from my perspective, VB.NET was a real missed opportunity for MS. What it should have been was a way to seamlessly convert your old VB6 code to the .NET world - with dynamic invocation and high-quality COM interop from the start. What it ended up being was a near-clone of C#'s feature set with a more verbose syntax and little to no backward compatibility. Sad, really. It locked a lot of organizations out of .NET for a long time. Then again, maybe it forced a "cold-turkey" clean break from the past...
我过去学过很多 VB6 和很多 C/C++，当我们进行大型 .NET 迁移时，我毫不怀疑 C# 是正确的选择。话虽如此，VB6 人员真正应该学习的是 .NET 和 CLR（一个适当的面向对象的运行时而不是愚蠢的 COM 前端），而不是语法。专注于此，回避宗教战争。
I've done a LOT of VB6 in the past, and a lot of C/C++, and when our big .NET migration happened I had no doubts that C# was the way to go. Having said that, what the VB6 guys should really be learning is .NET, and the CLR (a proper object-oriented runtime rather than a dumb COM front-end), and not a syntax. Focus on that, and sidestep the religious war.
这可能无法回答您的问题，事实上，它甚至可能与您的回答相矛盾并证明您的朋友是对的，但这里列出了 VB.NET 和 C# 之间的相似点（和差异）：
C# / VB.NET 比较
当您浏览此列表时，您会注意到这两种语言变得多么相似，并且每一个新语言都变得非常相似版本，切换的理由可能会越来越少。但是，最后，如果您确实进行了转换，维基百科文章很好地总结了 C# 相对于 VB.NET 的优势：
维基百科文章列出了 C# 相对于 VB 的优势，反之亦然
This may not answer your question, in fact it may even contradict your response and prove your friend right, but here is a good list of the similarities (and differences) between VB.NET and C#:
C# / VB.NET comparison
As you go down this list, you will notice just how similar the two languages have become and with each new version, there may be less and less of a reason to switch. But, in the end, if you do make the switch, the Wikipedia article pretty much summarizes the advantages that C# has over VB.NET quite well:
Wikipedia article listing advantages of C# over VB and vice versa
VB.net 事件语法看起来比 C# 好得多；虽然类缺乏任何方法来取消订阅它所订阅的所有 WithEvents 处理程序，或者终止其他对象对其事件的所有订阅，这使得避免事件泄漏变得有点困难，但在这方面它并不比 C# 差。
另外，在 vb.net 中，Finally 处理程序可以知道其 Try 块中发生了什么异常（如果有），而不必实际捕获它。如果Finally 块中发生任何异常，则原始异常可以包含在CleanupFailedException 中（以及Finally 块中发生的其他异常）。这似乎是一个不错的优势。
The VB.net events syntax seems much nicer than C#; though the lack of any means for a class to either unsubscribe all WithEvents handlers to which it has subscribed, or kill all subscriptions other objects have to its events, makes it a little tough to avoid event leaks, it's no worse than C# in that regard.
Also, in vb.net, it's possible to have a Finally handler know what exception occurred (if any) in its Try block without having to actually catch it. If any exceptions occurs in the Finally block, the original exception can be included in the CleanupFailedException (along with the other exception(s) that occurred in the Finally block). That seems like a nice advantage.
“开发人员可能会陷入对 VB.NET 的错误熟悉感 - 像在 VB6 中那样对待资源，而不了解完整的概念。” （@Markle）
我以前没有用过这个来争论，但这是一个非常好的观点。当我拿起由一群刚接触 .net VB 程序员编写的 VB.NET 应用程序时，它充满了对旧 VisualBasic 命名空间的遗留兼容性调用。 CStr()、VbNewLine、Mid() 等...使用不支持遗留代码转换的语言工作会阻止使用这些遗留物。 （删除对旧命名空间的引用也是如此，仅供参考。）
我经常在 VB.NET 和 C# 之间切换。每当我从 VB 转到 C# 时，我都会想“这是不同的，我需要几分钟的时间来调整。”每当我从 C# 转到 VB 时，我都会想“这是一种低效的编程语言；需要输入太多内容，多么烦人。”
"Developers may be lulled into a false sense of familiarity with VB.NET - treating resources like they did in VB6 without understanding the full concepts." (@Markle)
I haven't used this for an argument before, but it's a very good point. When I picked up a VB.NET app written by a bunch of new-to-.net VB programmers, it was littered with legacy compatibility calls to the old VisualBasic namespace. CStr(), VbNewLine, Mid(), etc... Working in a language which isn't designed to support legacy code conversion prevents the use of those relics. (So does removing the reference to the legacy namespace, FYI.)
I switch between VB.NET and C# pretty regularly. Whenever I go from VB to C#, I think "This is different, it'll take me a few minutes to adjust." Whenever I go from C# to VB, I think "This is an inefficient programming language; there's way too much typing required, how annoying."
我认为其他答案已经很好地涵盖了技术要点。我还要向你们的 vb6 开发人员指出，不仅有更多针对 c# 的书籍和更多有关 c# 的问题，而且对他们来说更重要的是，还有更多的职位列表。
快速搜索 SO 职业：
I think the other answers have done a good job of covering the technical points. I would also point out to your vb6 developers that there are not only more books aimed at c# and more questions on SO on c#, but perhaps more importantly to them, more job listings as well.
A quick search on SO careers:
其他人已经给出了 C# 优于 VB.NET 的技术原因，但我认为您正在处理一个人员问题，因此我将提供我认为最引人注目的内容开发人员应该更喜欢它的原因：
。
Others have given technical reasons for C# over VB.NET, but I think you are dealing with a people issue, so I'll offer what I think is the most compelling reason why the developers should prefer it:
Also
除了技术/社会优势更多的是商业导向，
对 VB6 的主流支持已经结束，而扩展支持肯定会很昂贵，很快就会结束。
在这种情况下，迁移到新平台更具商业意义。
此外，微软不再支持 IDE，因此如果出现问题，您将是 SOL，并且将其安装在闪亮的新笔记本电脑上可能会带来不愉快的体验。
请注意，他们不需要移植每个应用程序，只需弃用需要用 com 公开的 .Net 程序集替换的部分。
另一方面，拥有将软件从过时平台移植到新平台的经验将使这些人变得富有，前提是他们愿意学习新平台。
Other than technical / social advantage is more business oriented,
Mainstream support for VB6 already ended and Extended support which is surely expensive would end soon.
Moving to a new platform in this case make more business sense.
Also the IDE is no more supported by microsoft so in case of issue you would be SOL, and installing it on shiny new laptop might provide an unenjoyable experience.
Note that they don't need to port every application, only deprecate the part that need to be replaced with com exposed .Net assemblies.
On the other hand having experience in porting software from obsolete platform to a new one will make these guys rich, providing they are willing to learn the new platform.