我的开发团队正准备开始一个新项目.自VB3时代以来,该商店一直是一个"VB商店",但现在流行的观点是我们是一个".NET商店",因为C#是专为.NET创建的,而VB.NET是一个改造,我们我决定继续前进写C#.争议围绕的问题是Microsoft.VisualBasic命名空间是否在新开发中具有合法位置,或者它是否仅用于VB6(及更旧)代码的向后兼容性.另一个更有趣的问题是,Microsoft.VisualBasic命名空间下的代码是否是.NET代码,如果它真的是在.NET包装器中精心打包的旧VB运行时,使其实际上是一个COM互操作控件(类似于WinForms如何包装非.NET Win32窗口API但仅暴露.
为了使这更令人困惑,我们的开发团队有一位Microsoft咨询服务顾问告诉我们Microsoft不再支持Visual Basic,包括Microsoft.VisualBasic命名空间下的VB运行时.
我正在寻找的是链接 - 最好是无懈可击的微软来源 - 链接到最终以这种或那种方式回答这个问题的文档.我已经在Google上尝试了几种搜索排列,并且没有更接近这个问题的底部.
编辑:显然我没有说清楚我的问题.我不是在问VB.NET是否是真正的.NET代码.我正在尝试确定Microsoft.VisualBasic命名空间 "下" 是否为.NET代码,或者它是否是旧的VB6运行时,它是经过精心打包并作为.NET代码公开的.有人已经说过9/10的命名空间只是从.NET的其他地方包装代码; 那个1/10怎么样？
甚至在20年前,也可以调用用一种语言编写的代码来调用另一种语言编写的代码; 在学校,我们从Ada代码中调用汇编图形例程进行一个类赋值.值得注意的例外是从脚本中运行编译代码或从编译代码中执行系统命令; 但很少我们用C++编写库以在我们的Java应用程序中使用.当Java第一次出现并且它仍然很慢时,可以选择用Java编写主应用程序并将瓶颈代码移动到使用JNI调用的某些C/C++ DLL中.
那么,经过这么多年,是什么阻止我们编写多语言应用程序？我想到的主要场景是,当一种语言被认为是一个很好的选择时,如果它不是因为某些性能瓶颈(比如在早期的Java时代),所以它完全用C语言编写,而不是使用两种语言的混合.
我从架构角度和语言设计中对此感兴趣.你有什么好的例子,成功的故事或报价吗？
[编辑]最好的例子之一是对Java的反对,因为它在早期的性能很慢.尽管JIT编译器已经解决了这个问题,但我的问题始终是用一种语言编写软件,使其更易于编写,读取和维护.如果存在瓶颈,请在程序集或C中编写例程以解决瓶颈问题.这样你至少在理论上应该得到两全其美.