当我注意到下面有一条奇怪的评论时,我正在阅读这个问题:
不确定问题是什么:您可以在一个解决方案中使用 VB.NET 和 C# 项目(尽管我不建议这样做)。
我经常这样做,因为我们有旧版 VB.Net 代码,而新代码是用 C# 编写的。这真的不推荐吗?为什么不?
当我注意到下面有一条奇怪的评论时,我正在阅读这个问题:
不确定问题是什么:您可以在一个解决方案中使用 VB.NET 和 C# 项目(尽管我不建议这样做)。
我经常这样做,因为我们有旧版 VB.Net 代码,而新代码是用 C# 编写的。这真的不推荐吗?为什么不?
除了在一个“解决方案”中使用两种语言增加复杂性之外,没有真正的理由避免这种情况。
在我看来,您的场景(使用旧产品,但添加新功能)是在一个解决方案中使用两种语言的正当理由。
不推荐它的唯一原因是一致性。大多数开发人员在开发应用程序时更喜欢使用单一语言。拥有一种语言还意味着您的开发人员只需要了解一种语言,而不需要同时了解 VB.NET 和 C#(即使两者非常相似)。
如果您需要混合使用旧版 VB.NET 和 C#,没有理由不这样做。
这是一个“为你正在构建的东西使用最好的工具”的问题。不建议在项目中混合 C# 和 VB (出于明显的“它不会编译”的原因),但是如果您觉得您的开发团队可以更快地运行并且更易于维护,那么继续在 VB 中编写旧代码是没有意义的时尚使用 C#。
过去几个月我们一直在我的办公室做这件事(在类似的遗留代码情况下)并且还没有遇到任何重大问题(除了由于上下文切换而可能损失的开发时间),我们从使用我们都觉得更舒服的语言工作。
更多关于任务切换的信息在这里。我真的觉得我们每天从我们对 C# 的舒适程度中看到的好处超过了偶尔不得不回到遗留池中的成本。
这只是个人选择的问题。如果您对这两种语言都感到满意,那么您肯定可以在相同的解决方案中使用它们。
在解决方案中使用单一语言似乎很容易维护。因此它是首选。
在解决方案中混合代码可能会很快变得非常混乱,它永远不会清楚你从哪里调用什么方法,以保持它的良好。在单独的解决方案中开发,这将使您的项目更易于跟踪,并确保您不会混淆项目中的语言
你为什么想这么做?如果您有想要使用的遗留代码,则将该代码保留在其自己的组件中,不要将其与新代码混合。不推荐,因为它不提倡“清洁代码”。它可能会导致您有一个难以阅读和维护的解决方案。