Drawbacks of combining C#.NET and VB.NET

Question

I'm a long time VB.NET developer and has recently switched to C#. I found out that some of the built-in VB.NET functions (which predates .NET back to 6.0 and BASIC itself) such as the String.Left , or Right , or advanced functions like saving to the registry ( SaveSettings and GetSettings ) are noticeably absent.

What I did was create a new project in the same solution with VB.NET as its language and recreate basically all the functions I need that are available in VB.NET. And then I just call that to the C# code I'm writing.

Since compiling the code in .NET pretty much boils down to the same CIL, it shouldn't matter performance-wise what language I wrote the code in or whether I mix C# with VB.

Am I wrong or right?

Thanks

Answer 1

There is a namespace named Microsoft.VisualBasic , you can use it in C# projects also:

string test = Microsoft.VisualBasic.Strings.Left("abc", 2);

Don't forget to add Microsoft.VisualBasic into References of your project.

Answer 2

我建议构建它，然后使用reflector / ilspy / whatever反编译回C＃:)

Answer 3

In my experience, it's been almost entirely a matter of preference and experience one has with a language. You're right to guess that it doesn't matter performance-wise -- both languages are built with the purpose of generating IL and to target the CLR.

There are other debatable considerations to make when choosing a language as some features that are fully supported in one language are not supported by another. Also, some languages are just more expressive for certain purposes such as APL for mathematical calculations.

Answer 4

While using the Microsoft.VisualBasic namespace is a good solution, VB.NET has the equivalent functionality (although the string functions are zero-based rather than 1-based), eg

        string str = "abcdefg";

        string left  = str.Substring(0, 2);                // Left(str, 2)
        string right = str.Substring(str.Length - 2, 2);   // Right(str, 2)

BTW, the registry access methods are in the Microsoft.Win32 Namespace: see RegistryKey etc.