Does C# have extension properties?

For example, can I add an extension property to DateTimeFormatInfo called ShortDateLongTimeFormat which would return ShortDatePattern + " " + LongTimePattern?

Adrian Thompson Phillips
  • 6,893
  • 6
  • 38
  • 69
  • 152,914
  • 173
  • 462
  • 620
  • 21
    I wanted to add an extension method called IsNull on Nullable which would just return ! HasValue. .IsNull() is definately less pretty than .IsNull – Ken Aug 03 '11 at 19:02
  • 1
    I find this useful for trinary operator `?` – PedroC88 Aug 24 '12 at 17:59
  • 2
    I wanted this to mimic Java's `enum`s which can have properties and methods. C#'s `enum`s can't have properties or methods, but you *can* create extension methods on them. This question was useful to me, and shouldn't be closed. – Ian McLaird Sep 25 '14 at 13:51
  • Although, as many people have said, there are no plans currently in place to add this to the language, there's no reason it couldn't be done. The fact that F# has not only extension properties but static extensions as well to me proves that it is at least a good idea. – Richiban Oct 21 '14 at 09:36
  • 2
    There should be made one – Rootel Aug 06 '16 at 08:21
  • I’m voting to close this question because the question and answer are just more slowly updated versions of what you can find by typing "csharp extension properties" in the Google search box, the effort of keeping this up to date is reasonably too much to ask of answerers, and all it's really doing is adding an extra "back" button press to research by stealing the top Google result and providing outdated info. If it's closed I will then vote to delete so as to improve the internet. – Jason C Nov 09 '22 at 21:08

6 Answers6


For the moment it is still not supported out of the box by Roslyn compiler ...

Until now, the extension properties were not seen as valuable enough to be included in the previous versions of C# standard. Various C# versions (maybe all of them?) have seen this as proposal champion but it wasn't released yet, most of all because even if there is already an implementation, they want to make it right.

But it will maybe... one day ...

Update 2022:

The features seems to be still in discussion here.

Moreover you can use a workaround

As specified in this article, you can use the TypeDescriptor capability to attach an attribute to an object instance at runtime. However, it is not using the syntax of the standard properties.
It's a little bit different from just syntactic sugar adding a possibility to define an extended property like
string Data(this MyClass instance) as an alias for extension method
string GetData(this MyClass instance) as it stores data into the class.

I hope that C# will soon provide a full featured extension everything (properties and fields), however on that point, only time will tell.

And feel free to contribute as the software of tomorrow will come from the community.

Post processing approach

If you are allowed to do so, you could also add dynamically a property on a class in your assembly after compilation with tools like PostSharp, Mono.Cecil (or similar code/IL rewrite tool).

However, as a developer explained in the above discussion, rewriting code won't let the compiler knows your intent and thus it will probably fail at optimizing your resulting code. As a language feature, the result is expected to be better.

A bit of history

There was an extension members item in the C# 7 work list so I thought it might be supported in the near future. The current status of extension property can be found on Github under the related item.

However, there is an even more promising topic which is the "extend everything" with a focus on especially properties and static classes or even fields.

Update: August 2016

As dotnet team published what's new in C# 7.0 and from a comment of Mads Torgensen:

Extension properties: we had a (brilliant!) intern implement them over the summer as an experiment, along with other kinds of extension members. We remain interested in this, but it’s a big change and we need to feel confident that it’s worth it.

It seems that extension properties and other members, are still good candidates to be included in a future release of Roslyn, but maybe not the 7.0 one.

Update: May 2017

The extension members has been closed as duplicate of extension everything issue which is closed too. The main discussion was in fact about Type extensibility in a broad sense. The feature is now tracked here as a proposal and has been removed from 7.0 milestone.

Update: August, 2017 - C# 8.0 proposed feature

While it still remains only a proposed feature, we have now a clearer view of what would be its syntax. Keep in mind that this will be the new syntax for extension methods as well:

public interface IEmployee 
    public decimal Salary { get; set; }

public class Employee
    public decimal Salary { get; set; }

public extension MyPersonExtension extends Person : IEmployee
    private static readonly ConditionalWeakTable<Person, Employee> _employees = 
        new ConditionalWeakTable<Person, Employee>();

    public decimal Salary
            // `this` is the instance of Person
            return _employees.GetOrCreate(this).Salary; 
            Employee employee = null;
            if (!_employees.TryGetValue(this, out employee)
                employee = _employees.GetOrCreate(this);
            employee.Salary = value;

IEmployee person = new Person();
var salary = person.Salary;

Similar to partial classes, but compiled as a separate class/type in a different assembly. Note you will also be able to add static members and operators this way. As mentioned in Mads Torgensen podcast, the extension won't have any state (so it cannot add private instance members to the class) which means you won't be able to add private instance data linked to the instance. The reason invoked for that is it would imply to manage internally dictionaries and it could be difficult (memory management, etc...). For this, you can still use the TypeDescriptor/ConditionalWeakTable technique described earlier and with the property extension, hides it under a nice property.

Syntax is still subject to change as implies this issue. For example, extends could be replaced by for which some may feel more natural and less java related.

Update December 2018 - Roles, Extensions and static interface members

Extension everything didn't make it to C# 8.0, because of some of drawbacks explained as the end of this GitHub ticket. So, there was an exploration to improve the design. Here, Mads Torgensen explains what are roles and extensions and how they differs:

Roles allow interfaces to be implemented on specific values of a given type. Extensions allow interfaces to be implemented on all values of a given type, within a specific region of code.

It can be seen at a split of previous proposal in two use cases. The new syntax for extension would be like this:

public extension ULongEnumerable of ulong
    public IEnumerator<byte> GetEnumerator()
        for (int i = sizeof(ulong); i > 0; i--)
            yield return unchecked((byte)(this >> (i-1)*8));

then you would be able to do this:

foreach (byte b in 0x_3A_9E_F1_C5_DA_F7_30_16ul)

And for a static interface:

public interface IMonoid<T> where T : IMonoid<T>
    static T operator +(T t1, T t2);
    static T Zero { get; }

Add an extension property on int and treat the int as IMonoid<int>:

public extension IntMonoid of int : IMonoid<int>
    public static int Zero => 0;
  • 14,327
  • 5
  • 49
  • 68
  • 162
    This is one of the most useful answers I've ever followed on StackExchange. Constantly updating with the status and keeping everyone informed that comes back to this, providing solid links to discussion and history. – bdrelling Jan 31 '19 at 05:07
  • 47
    It's terrific that you are keeping this up to date - thank you – David Thielen Feb 13 '19 at 16:20
  • 9
    Unfortunately as of this comment, roles, extensions and static interface members are only flagged for C# 11 :( – Ian Kemp May 11 '20 at 09:43
  • 6
    It appears the "extension everything" proposal has been closed, and the continuation appears to be in this ticket: https://github.com/dotnet/csharplang/issues/192 – lightw8 Aug 24 '20 at 18:49
  • 5
    any update for 2022? – cikatomo May 12 '22 at 01:48
  • 1
    @EdwardOlamisan https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-11 extension properties are not in that list. It's easier to just find updates by searching Google; this Q&A is pretty much just a more slowly updated duplicate of a Google result page. – Jason C Nov 09 '22 at 21:05

No they do not exist in C# 3.0 and will not be added in 4.0. It's on the list of feature wants for C# so it may be added at a future date.

At this point the best you can do is GetXXX style extension methods.

  • 733,204
  • 149
  • 1,241
  • 1,454

No, they don't exist.

I know that the C# team was considering them at one point (or at least Eric Lippert was) - along with extension constructors and operators (those may take a while to get your head around, but are cool...) However, I haven't seen any evidence that they'll be part of C# 4.

EDIT: They didn't appear in C# 5, and as of July 2014 it doesn't look like it's going to be in C# 6 either.

Eric Lippert, the Principal Developer on the C# compiler team at Microsoft thru November 2012, blogged about this in October of 2009:

Arsen Khachaturyan
  • 7,904
  • 4
  • 42
  • 42
Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • 1
    IMO they wont add anything of value. How would you handle the setter? The purpose of properties is to 'hide the field'. – leppie Mar 06 '09 at 14:36
  • 2
    Yes, and they could still hide the field - setting a single property might set two properties underneath, or vice versa. (Imagine something with a normal Size property, and Width/Height extension properties, or vice versa.) They'd be more useful as read-only ones though, I suspect. – Jon Skeet Mar 06 '09 at 14:46
  • 23
    You can't bind to extension methods... being able to add your own properties for databinding could be helpful in many situations. – Nick Mar 06 '09 at 14:46
  • 1
    Nick, that's where you use TypeCpnverter and PropertyDescriptors :) – leppie Mar 06 '09 at 14:48
  • @Jon: Hooray for double side-effects! :) I'd rather not. – leppie Mar 06 '09 at 14:49
  • @leppie: I agree that most of the time that's not what you want. I wouldn't be surprised to find some useful situations though. And as I say, most of the time I'd want them as read-only properties. – Jon Skeet Mar 06 '09 at 15:04
  • 3
    @leppie - The value of property extensions would benefit bool and string properties the most I think. Getting rid of the `()` at the end is _much_ more readable. I know for me personally, at least 90% of the extensions I write are of those 2 types. – Code Maverick Oct 31 '13 at 16:54
  • 5
    To give an example of why this would be useful, I have an EFCF model. In some of the classes I have read-only properties that I use to return formatted information: `FullName` = `FirstName + LastName`, `ShortName` = `FirstName + LastName[0]`. I would like to add more of these properties, but I don't want to "dirty" the actual classes. In this case an extension property, that's read-only, is perfect because I can add the functionality, keep the main class clean, and still expose the information I want to expose in the UI. – Gup3rSuR4c Feb 20 '14 at 04:54
  • @JonSkeet I'd be amazed if something quite big like this was introduced now, but yeah, it could happen. – Joe Jul 02 '14 at 18:21
  • 2
    Another example is extending a sealed class, I'd like to use FileInfo for example, but I want to keep some extra information about each file. I can't inherit from FileInfo, so I'm stuck doing composition which involves an awful lot of method wrapping if I want to expose much of the FileInfo functionality. – Steve L Oct 01 '14 at 19:54
  • @SteveL: I'm not sure what you're saying that's an example of... extension properties wouldn't help you there, assuming they would be like extension methods. – Jon Skeet Oct 01 '14 at 20:03
  • 4
    @JonSkeet : You're right, I ended up doing what I wanted by creating my own class, then wrapping all the relevant sealed class methods and properties, then providing `static implicit operator FileInfo(FileInfoEx fex)` which returns my contained FileInfo object. This effectively lets me treat the FileInfoEx as if it inherits from FileInfo, even though that class is sealed. – Steve L Oct 02 '14 at 21:28
  • Another example, using the `DBContext` classes generated by Entity Framework, I'd like to be able to add a couple more properties to hold some extra information I can read with a `IDbCommandInterceptor`, but I have to inherit from each context separately and reimplement the same interface to add the properties on each one, which is kind of tedious. – Matt Burland Nov 05 '14 at 19:25

Update (thanks to @chaost for pointing this update out):

Mads Torgersen: "Extension everything didn’t make it into C# 8.0. It got “caught up”, if you will, in a very exciting debate about the further future of the language, and now we want to make sure we don’t add it in a way that inhibits those future possibilities. Sometimes language design is a very long game!"

Source: comments section in https://blogs.msdn.microsoft.com/dotnet/2018/11/12/building-c-8-0/

I stopped counting how many times over the years I opened this question with hopes to have seen this implemented.

Well, finally we can all rejoice! Microsoft is going to introduce this in their upcoming C# 8 release.

So instead of doing this...

public static class IntExtensions
   public static bool Even(this int value)
        return value % 2 == 0;

We'll be finally able to do it like so...

public extension IntExtension extends int
    public bool Even => this % 2 == 0;

Source: https://blog.ndepend.com/c-8-0-features-glimpse-future/

  • 12,108
  • 5
  • 69
  • 56
  • 3
    This week [C# 8.0 features](https://blogs.msdn.microsoft.com/dotnet/2018/11/12/building-c-8-0/) were announced and I didn't see any of this unfortunately. – Mateo Torres-Ruiz Nov 15 '18 at 21:56
  • 1
    @MateoTorres-Ruiz A comment from 'Mads Torgersen' (C# dev), replying to someone asking about it (3 days ago): "Extension everything didn’t make it into C# 8.0. It got “caught up”, if you will, in a very exciting debate about the further future of the language, and now we want to make sure we don’t add it in a way that inhibits those future possibilities. Sometimes language design is a very long game!" Feels bad.. (Read this on Korayems link, in the comment section) – Chaost Nov 16 '18 at 09:58

As @Psyonity mentioned, you can use the conditionalWeakTable to add properties to existing objects. Combined with the dynamic ExpandoObject, you could implement dynamic extension properties in a few lines:

using System.Dynamic;
using System.Runtime.CompilerServices;

namespace ExtensionProperties
    /// <summary>
    /// Dynamically associates properies to a random object instance
    /// </summary>
    /// <example>
    /// var jan = new Person("Jan");
    /// jan.Age = 24; // regular property of the person object;
    /// jan.DynamicProperties().NumberOfDrinkingBuddies = 27; // not originally scoped to the person object;
    /// if (jan.Age &lt; jan.DynamicProperties().NumberOfDrinkingBuddies)
    /// Console.WriteLine("Jan drinks too much");
    /// </example>
    /// <remarks>
    /// If you get 'Microsoft.CSharp.RuntimeBinder.CSharpArgumentInfo.Create' you should reference Microsoft.CSharp
    /// </remarks>
    public static class ObjectExtensions
        ///<summary>Stores extended data for objects</summary>
        private static ConditionalWeakTable<object, object> extendedData = new ConditionalWeakTable<object, object>();

        /// <summary>
        /// Gets a dynamic collection of properties associated with an object instance,
        /// with a lifetime scoped to the lifetime of the object
        /// </summary>
        /// <param name="obj">The object the properties are associated with</param>
        /// <returns>A dynamic collection of properties associated with an object instance.</returns>
        public static dynamic DynamicProperties(this object obj) => extendedData.GetValue(obj, _ => new ExpandoObject());

A usage example is in the xml comments:

var jan = new Person("Jan");

jan.Age = 24; // regular property of the person object;
jan.DynamicProperties().NumberOfDrinkingBuddies = 27; // not originally scoped to the person object;

if (jan.Age < jan.DynamicProperties().NumberOfDrinkingBuddies)
    Console.WriteLine("Jan drinks too much");

jan = null; // NumberOfDrinkingBuddies will also be erased during garbage collection
  • 3,497
  • 1
  • 25
  • 37
  • 1
    The best answer – N73k Jun 21 '19 at 04:16
  • 1
    @N73k No, not the best answer at all. Do you have the slightest clue as to what the performance overhead of dynamic properties is? We use languages like C# because they are strongly typed and because they compile to native code, for performance. dynamic properties invalidate all of that. – Mike Nakis Jun 08 '22 at 15:18
  • 1
    The question is whether it is possible, not whether you should :-) However, I'm convinced there's valid use cases for the ConditionalWeakTable, despite its performance implications. – realbart Jun 10 '22 at 08:10

Because I recently needed this, I looked at the source of the answer in:

c# extend class by adding properties

and created a more dynamic version:

public static class ObjectExtenders
    static readonly ConditionalWeakTable<object, List<stringObject>> Flags = new ConditionalWeakTable<object, List<stringObject>>();

    public static string GetFlags(this object objectItem, string key)
        return Flags.GetOrCreateValue(objectItem).Single(x => x.Key == key).Value;

    public static void SetFlags(this object objectItem, string key, string value)
        if (Flags.GetOrCreateValue(objectItem).Any(x => x.Key == key))
            Flags.GetOrCreateValue(objectItem).Single(x => x.Key == key).Value = value;
            Flags.GetOrCreateValue(objectItem).Add(new stringObject()
                Key = key,
                Value = value

    class stringObject
        public string Key;
        public string Value;

It can probably be improved a lot (naming, dynamic instead of string), I currently use this in CF 3.5 together with a hacky ConditionalWeakTable (https://gist.github.com/Jan-WillemdeBruyn/db79dd6fdef7b9845e217958db98c4d4)

  • 1
  • 1
  • 54
  • 2
  • Sorry, but although this looks very thorough, it has nothing to do with extension properties, but only shows extension methods. – Viking Mar 12 '18 at 09:39