{"id":103,"date":"2008-01-15T11:53:39","date_gmt":"2008-01-15T18:53:39","guid":{"rendered":"http:\/\/jameskovacs.com\/2008\/01\/15\/Syntactic+Sugar+Compiler+Candy+And+Other+Sweets"},"modified":"2008-01-15T11:53:39","modified_gmt":"2008-01-15T18:53:39","slug":"syntactic-sugar-compiler-candy-and-other-sweets","status":"publish","type":"post","link":"https:\/\/www.jameskovacs.com\/index.php\/2008\/01\/15\/syntactic-sugar-compiler-candy-and-other-sweets\/","title":{"rendered":"Syntactic Sugar, Compiler Candy, and Other Sweets"},"content":{"rendered":"

A great new feature of Visual Studio 2008 is multi-targeting, which allows VS 2008 to compile for .NET 2.0, 3.0, or 3.5 simply by changing a project property.<\/p>\n

\"ApplicationDesignerWindowPaneControl\"<\/a> <\/p>\n

You might be thinking, now I don’t have to keep Visual Studio 2005 and 2008 installed. I can just use Visual Studio 2008 for all my projects! Well, yes, but with one big proviso. Code targeting .NET 2.0 and written in VS2008 may only compile in VS2008! The reality is that multi-targeting changes Intellisense, the project templates, and the assemblies that you’re offered, but your code is still compiled using the C# 3.0 or VB9 compilers regardless of which .NET Framework version you target. Compiling a project targeting .NET 2.0 using VS2008 results in this output:<\/p>\n

—— Build started: Project: Multitargetting, Configuration: Debug Any CPU ——
C:\\Windows\\Microsoft.NET\\Framework\\v3.5\\Csc.exe \/noconfig \/nowarn:1701,1702 \/errorreport:prompt \/warn:4 \/define:DEBUG;TRACE \/reference:C:\\Windows\\Microsoft.NET\\Framework\\v2.0.50727\\System.Data.dll \/reference:C:\\Windows\\Microsoft.NET\\Framework\\v2.0.50727\\System.dll \/reference:C:\\Windows\\Microsoft.NET\\Framework\\v2.0.50727\\System.Xml.dll \/debug+ \/debug:full \/filealign:512 \/optimize- \/out:obj\\Debug\\Multitargetting.exe \/target:exe Program.cs Properties\\AssemblyInfo.cs <\/font><\/p>\n

Compile complete — 0 errors, 0 warnings
Multitargetting -> c:\\dev\\Examples\\Multitargetting\\Multitargetting\\bin\\Debug\\Multitargetting.exe
========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========<\/font><\/p>\n

Note the path to csc.exe – C:\\Windows\\Microsoft.NET\\Framework\\v3.5. We’re using the C# 3.0 compiler that ships with .NET 3.5. (Don’t get me started about the renaming of WinFX to .NET 3.0 again. My friends at Microsoft already know how I feel about that one.) Generally this doesn’t matter because .NET 3.0 and .NET 3.5 are additive libraries to .NET 2.0. .NET 2.0, 3.0, and 3.5 all run on the CLR that shipped with .NET 2.0. (I originally read about this in Dustin Campbell’s C#2.5 post<\/a>.)<\/p>\n

So how do we get all the crazy goodness of lambda expressions, anonymous types, LINQ, extension methods, and more? In .NET 3.0, WCF, WPF, WF, and CardSpace were all just additive libraries on top of .NET 2.0. In .NET 3.5, the new features can be divided into two categories – additive libraries and compiler enhancements.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n
Feature<\/u><\/strong><\/td>\nLibrary<\/u><\/strong><\/td>\nCompiler<\/u><\/strong><\/td>\n<\/tr>\n
implicitly-typed locals (var)<\/td>\n <\/td>\nX<\/td>\n<\/tr>\n
lambda expressions<\/td>\n <\/td>\nX<\/td>\n<\/tr>\n
automatic properties<\/td>\n <\/td>\nX<\/td>\n<\/tr>\n
anonymous types<\/td>\n <\/td>\nX<\/td>\n<\/tr>\n
object and collection initializers<\/td>\n <\/td>\nX<\/td>\n<\/tr>\n
LINQ<\/td>\nX<\/td>\nX<\/td>\n<\/tr>\n
Expression Trees<\/td>\nX<\/td>\nX<\/td>\n<\/tr>\n
Extension Methods<\/td>\nX*<\/td>\nX<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

* See below<\/p>\n

Any feature not requiring library support is just syntactic sugar provided by our compilers. If you look under the covers using Lutz Roeder’s Reflector<\/a>, you’ll see that the compilers are generating the same old CLR 2.0-compatible MSIL as they always were.<\/p>\n

Implicitly-Typed Locals<\/h3>\n

Let’s take a look at implicitly-typed locals using the “var” keyword:<\/p>\n

\n
var<\/span> foo = \"Hello, World!\"<\/span>;<\/pre>\n
 <\/pre>\n<\/div>\n
Reflector says! (Harkening back to Family Feud and Richard Dawson.)<\/div>\n
 <\/div>\n
\n
string<\/span> foo = \"Hello, World!\"<\/span>;<\/pre>\n
 <\/pre>\n<\/div>\n
The compiler was able to infer the type of “foo” based on its usage. No magic MSIL instruction to infer type. It’s all in the compilers.<\/div>\n
Lambdas<\/h3>\n
Let’s take a look at our new swanky lambda expressions:<\/div>\n
 <\/div>\n
\n
Action<\/span><string<\/span>> display = msg => Console<\/span>.WriteLine(msg);<\/pre>\n<\/div>\n
 <\/div>\n
Reflector says!<\/div>\n
 <\/div>\n
\n
Action<\/span><string<\/span>> display = delegate<\/span>(string<\/span> msg) { Console<\/span>.WriteLine(msg); }<\/pre>\n<\/div>\n
 <\/div>\n
Once again, it’s just compiler magic turning the terse lambda expression (that funky “params => body” syntax) into the anonymous delegate syntax that we’ve known and loved since .NET 2.0. (To be honest, that’s not quite what Reflector says. The C# compiler actually caches the anonymous delegate in a static field for performance reasons, but the code above is close enough for purposes of this discussion.)<\/div>\n
Automatic Properties<\/h3>\n
What about automatic properties?<\/p>\n
\n
public<\/span> string<\/span> Hello { get<\/span>; set<\/span>; }<\/pre>\n<\/div>\n
Reflector says!<\/p>\n
[CompilerGenerated]\nprivate string <Hello>k__BackingField<\/b>;<\/pre>\n
[CompilerGenerated]\npublic string get_Hello<\/b>()\n{\n    return this.<Hello>k__BackingField;\n}<\/pre>\n
[CompilerGenerated]\npublic void set_Hello<\/b>(string value)\n{\n    this.<Hello>k__BackingField = value<\/a>;\n}<\/pre>\n
Once again, more compiler magic.<\/div>\n
Anonymous Types<\/h3>\n
\n
var<\/span> position = new<\/span> { Lat=42, Long=42 };<\/pre>\n<\/div>\n
Reflector says!<\/p>\n
[CompilerGenerated, DebuggerDisplay(@\"\\{ Lat = {Lat}, Long = {Long} }\", Type=\"<Anonymous Type>\")]\ninternal sealed class <>f__AnonymousType0<<Lat>j__TPar, <Long>j__TPar> {\n  \/\/ Compiler generated goo omitted for clarity\n}\n<\/pre>\n
Compiler magic.<\/p>\n
Object\/Collection Initializers<\/h3>\n
Object and collection initializers allow us to create and initialize objects\/collections in a single line. They only require that the object have a parameterless constructor.<\/p>\n
\n
Program<\/span> program = new<\/span> Program<\/span> { Hello=\"World\"<\/span> };<\/pre>\n<\/div>\n
 <\/div>\n
Reflector says!<\/div>\n
Program <>g__initLocal0 = new Program();\n<>g__initLocal0.Hello = \"World\";\nProgram program = <>g__initLocal0;\n<\/pre>\n
 <\/div>\n
The C# 3.0 compiler is changing our object initializer into a plain old object instantiation via the parameterless constructor followed by a bunch of property sets. Nothing else to see here. Move it along…<\/div>\n
LINQ, Expression Trees, and Extension Methods<\/h3>\n
Each of these features requires library support from System.Core, a new assembly that ships with .NET 3.5. Without System.Core installed in the GAC, your code isn’t going to run. So you can’t use these features without .NET 3.5 installed on the client.<\/p>\n
The one exception is extension methods. If you try to compile an extension method while targeting .NET 2.0, you will receive the following compile error:<\/p>\n
Cannot define a new extension method because the compiler required type ‘System.Runtime.CompilerServices.ExtensionAttribute’ cannot be found. Are you missing a reference to System.Core.dll?<\/p>\n
As noted by Jared Parsons here<\/a>, you can simply define the attribute yourself:<\/p>\n
\n
namespace<\/span> System.Runtime.CompilerServices {<\/pre>\n
    [AttributeUsage<\/span>(AttributeTargets<\/span>.Method)]<\/pre>\n
    public<\/span> class<\/span> ExtensionAttribute<\/span> : Attribute<\/span> {<\/pre>\n
    }<\/pre>\n
}<\/pre>\n<\/div>\n
Extension methods now compile while targeting .NET 2.0.<\/p>\n
N.B. If you target .NET 3.5 as well as .NET 2.0 with this code, you’ll end up with a duplicate definition warning under .NET 3.5 as noted by Dustin Campbell here<\/a>. If you’re really going to use this trick, you should probably wrap the class in some conditional directives that omit the definition when compiled under .NET 3.5.<\/p>\n
Multi-targeting Proviso<\/h3>\n
What about that proviso I mentioned at the beginning of this post? If everyone on your project is using VS 2008 and targeting .NET 2.0, then all is good. You can use all the new syntactic sugary goodness that the C# 3.0 compiler (and VB9 compiler – if you swing that way) provides for you. If some team members are still using VS 2005, you need to be careful to not introduce C# 3.0 language constructs as VS2008 will not provide feedback that you are using them even if you target .NET 2.0. The new constructs are sufficiently different enough that it’s unlikely that you’ll mistakenly use a lambda expression or automatic property, but it’s something to keep in mind. Besides your CruiseControl.NET server is using a NAnt script that compiles with the C# 2.0 compiler to keep everyone honest, right? If not, this is yet another reason you should set up a CI server for your project today…<\/p>\n","protected":false},"excerpt":{"rendered":"
A great new feature of Visual Studio 2008 is multi-targeting, which allows VS 2008 to compile for .NET 2.0, 3.0, or 3.5 simply by changing a project property. You might be thinking, now I don’t have to keep Visual Studio 2005 and 2008 installed. I can just use Visual Studio 2008 for all my projects! […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-103","post","type-post","status-publish","format-standard","hentry","category-dotnetgeneral"],"_links":{"self":[{"href":"https:\/\/www.jameskovacs.com\/index.php\/wp-json\/wp\/v2\/posts\/103","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.jameskovacs.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.jameskovacs.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.jameskovacs.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.jameskovacs.com\/index.php\/wp-json\/wp\/v2\/comments?post=103"}],"version-history":[{"count":0,"href":"https:\/\/www.jameskovacs.com\/index.php\/wp-json\/wp\/v2\/posts\/103\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.jameskovacs.com\/index.php\/wp-json\/wp\/v2\/media?parent=103"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.jameskovacs.com\/index.php\/wp-json\/wp\/v2\/categories?post=103"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.jameskovacs.com\/index.php\/wp-json\/wp\/v2\/tags?post=103"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}