Write .NET portable code or take advantage of language specifics?

Question

Sometimes I need to convert a piece of code or an entire project from VB.NET to C# or viceversa. Unfortunately the code conversion sometimes cannot be automatically done because of the intrisic language differences. I am referring for example to keywords like yield available in C# and not in VB.NET or viceversa XML Literals available in VB.NET and not in C#.

My question is then if you ever consider the portability of source code when you write a .NET project or do you take full advantage of the language-specifics?

Answer 1

I always code in C#, I hate the VB syntax and verbosity. I find C# more precise and concise, maybe because I came from the C/C++ world.

But, I was never faced to such issue as needed to convert a project from language to another one. Don't forget that a compiled .NET assembly, written either in C# or VB.NET (or anything else) will be usable on every .NET project.

Answer 2

I would never consider to restrict my use of a language only because someday I could want to port it to another language. It would lessen my productivity and mean an investment in a future that is not very likely.

I would especially not do so for .NET languages, because .NET assemblies are interchangable.

If I know beforehand that I will have to port my code, I would write it directly in the language that I would need to port it to.

Answer 3

Why do you want to convert languages? Consider that are are far more than two .NET languages, and some are very different, e.g. F#.

Use the right language for the right job. In .NET a lot of the time that will be either C# or VB, but there are plenty of things that are easier in others (including C++/CLI and F#).

And of course multiple languages can be used in a single project, and even in the same assembly (albeit not supported directly by VS).

Answer 4

Full advantage every time. I try and ensure that the public types in the assembly remain CLS-compliant, but that's as far as it goes. I tend to stay in the C# area, but VB has (or had) better support for late-bound COM, and C++/CLI is essential when interop-ing with really awkward c++ libraries.

If you select your language based on its capabilities, rather than its syntax, I think your less likely to change anyway.

Answer 5

I don't see a point writing portable .NET code since you can just link it, therefore 99% of the time porting to another .NET language is pointless. Just extract the code, make it a DLL and link it.

Answer 6

I try to take full advantage of language-specifics. All other things would be stupid (in my book). My work is to use my tools in the best way to get the work done. And I havent had any need to convert any of my programs to another language in my 20 years as programmer (Only upgrade from different version of same language).

Now when C# and VB.Net are so easy to port to each other, maybe it will change. I know I often convert C#-examples/project to VB.net because there are more interresting examples in C# out there.

Answer 7

I take full advantage of language specific features. I don't really find the ability to port between languages very important when it's so easy to just call vb assemblies from c# , f# or other clr languages.

I don't really understand why you would even bother using different languages when you're not going to use the features they give you. If you only use features available in VB.Net why would you switch to C#?

Answer 8

In large projects usually there's no need to support source code portability because of components encapsulating functionality (reuse). Everything you need is CLSCompliant attribite on assemblies.

If you need to convert a piece of code from one language to another, you can use scheme "Language1 => IL => Language2". Reflector is great tool to do this.