Update: as Daniel Moth has pointed out in the comments, it is possible to use extension methods in Orcas projects targeting .NET 2.0 by introducing your own System.Runtime.CompilerServices.ExtensionAttribute class. See Daniel’s blog post for more details.
One of the neat things about Visual Studio 2008 is that you can target .NET 2.0, 3.0 and 3.5. I’m hoping to start using it professionally shortly after it’s released – assuming stability and performance aren’t an issue, of course. The great thing is that some of the C# 3 features don’t require any framework support at all (and none of them require CLR support, as far as I’m aware). So, I’ll be able to use anonymous types, local variable type inference, object initializers, collection initializers and automatic properties. Sure, there’s no LINQ, but I can take that hit.
But what about extension methods? As far as I can figure out, they only require one feature from the framework: an attribute to decorate a method to say that it’s an extension method. If we could provide that as a compile-time option, we could use extension methods in .NET 2.0 projects, assuming I haven’t forgotten something important.
Now, I know there’s a lot of controversy about whether extension methods are really a good idea in the first place – but I for one would welcome the opportunity to use them in .NET 2.0 projects. My wild guess is that I won’t be able to use .NET 3.5 until mid-2009, and that a lot of other developers will be in the same boat. I’m sure the transition from 2.0 to 3.5 will be faster than 1.1 to 2.0 – and I doubt that many people will target 3.0 at all – but it’ll still be far from instantaneous.
The obvious downside of this would be everyone creating their own attributes and using them throughout their projects. However, it wouldn’t take long to remove them when the project moved on to .NET 3.5 – delete the attribute and remove the compiler option, then fix the compilation errors.
It’s too late to suggest this for the Orcas timeframe, really, which is a shame. I wish I’d thought of it earlier – although I suspect it’s been suggested before, so it probably wouldn’t make any odds. Anyway, what do you all think?
I’d love to be able to use extension methods in 2.0.
You are correct, all language features can be used with .NET 2.0 projects in VS2008 – no dependencies on the framework or the CLR.
Extension methods is the only exception as you point out, but with a small hack, you can use that too. See my blog for the details.
Cheers
Daniel
PS No, the C# team will not be including this out of the box, at least not for the Orcas timeframe. The only downside with my approach is the possible warnings from the compiler if multiple projects define their own, but those can easily be suppressed. HTH.
Jon, I assume you’re talking about creating extension methods in C# 2005 projects, targeting .NET 2.0 in Orcas doesn’t stop you from using/creating extension methods…
Daniel, I came to the same conclusion as you, just create a System.Runtime.CompilerServices.ExtensionAttribute class and throw it on a method to be able to generate an extension method in a C# 2005 project. Unfortunately when you compile that same thing in Orcas Beta 2, this generates a compiler error “CS1112: Do not use ‘System.Runtime.CompilerServices.ExtensionAttribute’. Use the ‘this’ keyword instead”. And when you try to reference that C# 2005 class library in an Orcas 2.0-targeted project, it doesn’t fully recognize it as an extension method (Intellisense does, when you access it as a static method; but the compiler does not).
Folks at Microsoft seem to have gone to great lengths to make sure you can’t create something that can appear to be an extension method outside of the 3.5 compiler….
PeterRichie, I don’t see the issue.
The compiler will warn about using the “this” keyword instead of the attribute explicitly even in v3.5 projects – a bit like the finalizer/destructor syntax. That’s irrelevant to the overall point discussed here, IMO.
And yes, you must redeclare the attribute in each project (and then suppress the warning as I suggested above).
Cheers
Daniel
Peter: No, I’m talking about using Orcas and .NET 2.0 projects.
With Beta 2, if you try to define an extension method in a .NET 2.0 project, you are told to add a reference to System.Core – which doesn’t exist in .NET 2.0, so it’s greyed out in the Add Reference box. So, a hack of some kind is required.
Using Daniel’s technique of introducing ExtensionAttribute into a .NET 2.0 (but Orcas) project works fine for me. I haven’t tried mixing and matching 2008 and 2005 projects, but within Orcas it seems fine.
All of this is using Beta 2.
Jon
Consider the following scenario: I write an extension method for a class in somelib1.0
In a future release the guys from somelib have decided to add a method with the same signature on their class.. (But their implementation does something completely different than the extension method i wrote)
Does that mean i’m in trouble now?
Well, it means that the new method will be called instead of the extension method, and there’s currently no warning of that (IIRC). It would be much better if the compiler warned you if you try to create an extension method which will be masked by another method.
I expect FXCop will have a rule about this.
Jon