tags:

views:

368

answers:

4

It looks like the run-time compiler doesn't support the same language as the command-line compiler so if you want to use lambda expressions, extensions methods or LINQ, well, you're stuck.

There's more detail here:

http://metadatalabs.com/blog/

Is this correct or is there a work-around? (Short of spawning the command-line compiler, of course.)

A: 

I haven´t tried that, but it sounds crazy..

In the future that wont be a problem, since the .NET team are going to have the C# compiler available as a service, which means you can work with the real C# compiler in your code. Take a look at this video:

http://channel9.msdn.com/pdc2008/TL16/

vimpyboy
+1  A: 

This guy's blog seems to have the answer

CodeDomProviders

Looks like the factory defaults the instance it returns to 2.0.

This seems like a pretty crazy technique. Somewhere Paul Graham is crying.

Tim Merrifield
+2  A: 

I've been using this, and it seems to work when compiling using .Net 3.5

CodeDomProvider provider = new CSharpCodeProvider(new Dictionary<string, string> { { "CompilerVersion", "v3.5" } });
Jamie Penney
+2  A: 

Take a look at the documentation of the CSharpCodeProvider constructor:

The value for providerOptions is obtained from the element in the configuration file. You can identify the version of the CSharpCodeProvider you want to use by specifying the element, supplying "CompilerVersion" as the option name, and supplying the version number (for example, "v3.5") as the option value. You must precede the version number with a lower case "v".

VVS