Just curious - why does .NETMF only support development in the C# language?
Is it because the device does not execute language-independent CIL?
I haven’t used it myself, but I am pretty sure that it also supports Visual Basic. Most people seem to be using C#, which I must admit I prefer over the use of VB even for desktop development. 
I saw some documents created by MS on this, posted somewhere in the forum.
Supports VB and the VB version of this book is out before the C# version ‘Learning to Program in Visual Basic and.NET Gadgeteer’:
NOTE this book is free and downloadable from the site
History - C# has been the only language option for many years, and with 4.2 VB was introduced, so that’s why you’ll probably see the most content for C# and not much mention of VB.
Ok, but why has C# been the only option for years, and only recently VB support was added? What is it about NETMF that is language specific, given the all .NET languages emit language-neutral IL code?
Not all language features are supported on NETMF, so the language supported has to be “adopted” for NETMF. Small team, not enough resources - the usual.
@ dthorpe - The VB.NET compiler relies on specific library functions which help achieve functional equivalence with original VB6. For example functions like Chr, Str etc. in some cases the compiler generates code that calls the library functions without you explicitly calling into them, I will have to double check, but I think string comparisons would be a good example of this.
So at the very least all these library functions would need to be available for the generated IL to make sense. These and what ever else was required to support VB.NET was adde to the 4.2 release of .NETMF.
From memory I believe a lot of these functions are in the Microsoft.VisualBasic namespace, I will check when I am at a PC.
This uses Gadgeteer as well but it’s all VB.net
https://www.ghielectronics.com/community/codeshare/entry/648
Jas
@ taylorza - Ok, thanks.
So the NETMF runtime initially only implemented support for the CLR functions used by the IL generated by the C# compiler. Later, they added a few more functions to NETMF runtime which are used by the IL generated by the VB compiler.
Whether IL code produced by other language compilers will work on NETMF depends entirely upon whether they use core CLR functions that have not been implemented by the NETMF runtime - that is, CLR functions which are not used by C# or VB.
Is this a fair summary?
And the support issue is only about CLR functions, not IL instructions, right? Does NETMF support the complete IL instruction set, circa .NET 1.0 (pre generics)?
Thanks,
-Danny
Why?
It supports what you can use in C# and VB apps from within VS, when you have the correct SDK’s installed.
Is there any value in knowing what you’re asking?
Think of netmf as it’s own ecosystem. It’s history is not that of the big .Net, it’s focus is different, it’s implementations of common functions are even different.
Sounds like you’re asking if you can implement another language in addition to VB/C#, but are being a bit circumspect about it 
In theory, yes, you could port another language over if the language uses no more than the C# or VB NETMF specs use. I’m not aware of anyone having done this, however.
No, the tinyCLR doesn’t necessarily implement everything you might expect from .NET, and then implements some things beyond that. It’s also interpreted in a way that’s a bit different from the desktop, so there may be differences there. This is well beyond my depth of knowledge, though.
For example, I have no idea what additional work (if any) you may need to do to support the debugger or jitter.
site: http://netmf.codeplex.com/
Pete
@ dthorpe - I have obviously not gone into the details of what IL instructions the .NETMF CLR implements, but it is safe to say that it covers a sufficient subset to satisfy the C# compiler, excluding as you say generics. Keep in mind that not everything possible in IL is surfaced through C#, I am aware of an edge case in VB.NET which generates IL that is not correctly handled by .NETMF (This might have changed, I will need to check as I do not actively use VB.NET).
So as long as the compiler generates the supported subset of IL and provides all the required library infrastructure that the compilers assume then it has a reasonable chance of working.
@ Brett - I’m a compiler writer. I have experience writing compilers and IL manipulation tools.
I’m trying to figure out how deep the water is in the NETMF pool before diving off this 100ft tower.
@ Pete Brown - I’m actually more interested in performing post-compile IL transforms for interesting effect, but I’ve built a few compilers before as well.
I’m not aware of anyone having done this, however.<<
That’s what worries me a little. Is it merely for lack of interest, or is it because of technical limitations in the platform? I guess I’ll find out soon enough. Gotta dig out my steel toed boots. There will be a lot of bumping around in the dark!
-Danny
@ taylorza - K. I’m digging around in the PK docs now.
The .NETMF SDK data sheet (http://download.codeplex.com/Download?ProjectName=netmf&DownloadId=327278) states that the platform supports the full ECMA CLI v1.1 spec.
This is good news.
Almost certainly lack of interest. People come to NETMF precisely because it DOES run C# and VB. There’s very little market for other languages on the platform, unless those languages provided some new ability (like compiling directly to the metal with no interpreter).
Pete
I agree with Pete, but please don’t be discouraged. ;D
I am very curious to see what you came up with.
I was referring to a lack of interest in (or awareness of) the .NETMF platform.
Adoption of a new (or splinter) platform is a catch-22: you need a critical mass of consumer/developers to attract tools vendors, and you need tools vendors to attract developers.
That’s great for C# and VB developers, but it’s a huge turn-off for developers who prefer Delphi or IronPython or Ruby or F# or Lisp or Haskel or any number of other languages that target .NET.
Wouldn’t you agree that having more languages and tools supporting the .NETMF platform would be a good thing for the health of the .NETMF platform and community?
-Danny