views:

181

answers:

4
+1  Q: 

Common Runtime ?

Hi

Something I'm not to clear about, I understand there are differences between C# and VB.NET (mainly in the use of pointers) but why if both have a Common CLR, does XNA (for example) only work with C# and not VB.NET, or is it that the add ins to visual studio have been aimed at C# rather than VB.Net, and infact the language extensions work in both

Sorry if it's a obvious question, thought I'd ask

+4  A: 

It's the tool set that defines the language support. XNA, for example, simply did all their work with C# and only shipped support for it. You could still write an app in VB.NET and manually compile it from the command line. As long as your app didn't compile down to any illegal IL (opcodes that XNA doesn't support) it will still run. The primary issue is resources - they don't have the manpower to do full development and testing of all of the languages, so they picked one.

ctacke
+1  A: 

From all accounts VB.NET and C# are 99.9999 equivalent when it comes to the CLR. But there are some slight differences that may bite you. In addtion I remember reading on some microsoft blog that there are some things the CLR can do that are not (yet) programmable by either VB.NET or C# and have to be done by IL. Interesting indeed.

Conrad
A: 

The reason used to be that XNA Game Studio 1.0 was tied into Visual C# Express, so features like Content Pipeline, ... were only simple to use from within the IDE. (For a longer explanation, read this article)

However, a couple of months ago, XNA Game Studio 3.0 was released, with full support for Visual Studio 2008, so I suspect (I only use C#) that other languages should also be supported with the new release.

bmotmans
I wouldn't make that assumption. For example the Micro Framework plugs into full-blown Studio and supports only C#. The Compact Framework similarly only support C# and VB (not managed C++ or any other managed language).
ctacke
+2  A: 

The CLR has been ported to various platforms, not all of which are equal. The XBox 360 CLR, for instance, does not have Reflection.Emit or even all of the IL ops that the full CLR does. Hence, a different compiler may emit IL codes that are legal on the full CLR, but illegal on the Compact CLR.

The other issue is the availability of class libraries. The full BCL includes the Microsoft.VisualBasic namespace, which is automatically referenced by the VB.NET compiler. This contains VB6 compatibility functions, the My namespace features, as well as some compiler helper functions, and is commonly referred to as the VB.NET runtime.

Whenever the CLR is ported, certain assemblies are ported - and others are not. For the XBox, Microsoft.VisualBasic was not ported. This means that you cannot reference anything from that namespace. While it's fairly easy to not reference the compatibility or My namespaces, the compiler services can be inserted into the compiled IL without you explicitly calling them.

In VB.NET 8, you could pass an undocumented and unsupported -novbruntimeref switch to vbc.exe to keep it from referencing Microsoft.VisualBasic.dll. Unfortunately, this would sometimes cause odd compiler errors. In VB.NET 9, it's become documented and supported and renamed to /vbruntime.

The 3rd case is addins and Visual Studio support. This is up to the individual packages, as to whether they support templates, code gen, etc. for each language. I believe some 3rd parties have released VB.NET templates for XNA, though it's not officially supported.

Bottom line, I guess, is that it's a mix of technical concerns (CLR ports, BCL availability, compiler IL output) and support (testing, funding, and addins for other languages).

Mark Brackett