Click here to Skip to main content
15,114,922 members
Articles / Programming Languages / C# 4.0
Posted 18 May 2012

Tagged as


103 bookmarked

C# Easy Extension Properties

Rate me:
Please Sign up or sign in to vote.
4.97/5 (36 votes)
30 May 2012CPOL10 min read
(v2) How to convince your C# objects to carry extended properties, in real time, and with no modifications in their code. V2 includes a collector for disposable properties.


As it is well known, C# 4.0 does provide support for what are called "Extension Methods". They are basically a syntactic sugar supported by the compiler so that it helps you believe, syntactically, that you have "extended" the type of the instance with more methods, without inherit from it, and even if the type itself is sealed.

But as it is today, there is no support for "Extension Properties". There are many scenarios where having such capability would be extremely useful, basically any situation where you need some objects to carry with them some information that you generate at run time - regardless of their types, or if they are sealed or not, or even if you have access to its source code or not.

Till now, those situations were solved creating some sort of wrapping that inherits from the object’s type, using proxy factories (á la AOP/IoC), mixins, reflection and emit, dynamics, and the like. Those are extremely powerful alternatives, and the Internet has plenty of information that permits you to build your own library, or use any of the available ones. But also those are typically complex and heavy weighted, and they tend to have a substantial impact on performance. And when you have to deal with an unknown number of different types, potentially big, then there would be a problem trying to generate those wrappers using reflection and emit at run time…

Now, I have always had the conviction that there was already a mechanism for adding properties to instances on the fly, without having to create a wrapper to extend the type and instantiating a proxy: you only need to use a visual designer to see that, almost for any control it is using, it shows more "properties" than the ones the original control had.

Indeed it exists: it is based on the TypeDescriptor class. Among many other nice things, it will permit us to attach an attribute to any class instance at run time – and note that it does not mean it would modify the type’s structure in any way: it just add this new attribute to an internal list of attributes the instance is carrying with it.

Using this fact, we will use a custom attribute to store the information we need. Unlike the standard properties, which are fixed in the type’s metadata when it is written (or dynamically created), we are going to define this extended properties as key/value pairs that you can attach to any given object at run time, so that they can be accessed later to set or retrieve the value they store, as we do with the standard properties of any object. The pairs will be stored in the instance of the custom attribute we will attach on-demand to the object instance. Then we will build some methods that will permit us access to those contents in an easy way. Note that the solution is just emulation, as it cannot mimic completely the syntax of native properties - and this is why I prefer to call them "meta properties".

Using the Solution

Before digging deeper into the details of the solution, let’s take a look at how to use it. Let’s suppose we have an object instance we want to extend with a new meta-property called "MyNewProperty", and we want to set it with a string value, and later retrieve it. All the magic is as easy as just doing the following:

using MB.Tools;
  // Instance is of whatever type, as far it is a class, and not a struct or enum
  instance.SetMetaProperty( "MyNewProperty", "James Bond" );
  var value = instance.GetMetaProperty( "MyNewProperty" );
  Console.WriteLine( "Value: {0}", value );
  • The extension method SetMetaProperty(name, value) is used to create a meta-property attaching it to the host instance it is called upon, using a name and a value to store in it. If the meta-property already exists, its former value is substituted with the new one, and this former value is disposed if possible (more on this later).
  • The second main extension method is GetMetaProperty(name). It returns the value stored in the meta-property whose name is given, or throws an exception if such meta-property does not exist.

Note that the property names are just mere strings, and the only restrictions I chose to intercept are that they cannot be null or empty. But unlike the standard properties, they accept any string as its name - internally, these strings are used as the keys to locate the meta-property. Also note that, in any case, they are considered case sensitive.

More Useful Methods

There are some more extension methods (that as happens with the methods above also extend the type System.Object):

  • bool TryGetMetaProperty(name, out value): is used as expected to return true only if the meta-property exists, and setting its value in the out parameter. If the meta-property does not exist, it just returns false without throwing an exception.
  • bool HasMetaProperty(name): returns true if the object it is invoked upon carries a meta-property with the name given, or false otherwise.
  • IMetaProperty RemoveMetaProperty(name): is used to remove the meta-property from the object it is invoked upon, returning null if it is not found, or an IMetaProperty instance that can be used to access its contents and status. Its own properties are AutoDispose, PropertyName and PropertyValue.
  • void ClearMetaProperties(): is used to remove all the meta-properties the object it is invoked upon may carry, and potentially disposing them.
  • List<string> ListMetaProperties()</string>: returns a list, potentially empty, with the names of the meta-properties the object it is invoked upon may carry.

The following are not extension methods, but static ones of the static class MetaPropertyExtender:

  • IMetaPropertiesHolder GetMetaPropertiesHolder( obj, bool create): returns the attribute instance attached to the host object, in the form of an object that implements the IMetaPropertiesHolder interface. This interfaces provides the IEnumerable<IMetaProperty> MetaProperties property which permits you iterate though the meta-properties the host object may carry with it.

How It Works (The Basics)

As mentioned in the introduction, we will use a custom attribute that will be attached to the host object as needed using the TypeDescriptor mechanism. This custom attribute is an internal class that implements the IMetaPropertiesHolder interface, and note that, as mentioned before, the GetMetaPropertiesHolder() method permits you to obtain the one carried with your host instance, in case you need it. This custom attribute will provide the capability to host the key/value pairs we will need to support the meta-properties. Your can access them directly using its MetaProperties property.

When needed, typically because you are setting a meta-property using SetMetaProperty(), an instance of the custom attribute class is created and attached to the host object using the AddAttributes() method of TypeDescriptor. In this case, a first meta-property is always created, named "TypeDescriptionProvider", to store the descriptor provider returned when adding the custom attribute. It has no use in this solution, but it might have in the future.

When retrieving the value stored in the meta-property, typically by using GetMetaProperty() or TryGetMetaProperty(), the list of extended attributes of the host instance is obtained using the GetAttributes() method of TypeDescriptor, and locating the first attribute who is an instance of the custom attribute class. If there is none, the first Get() method will throw an exception, whereas the second TryGet() method just merely returns false.

Once you have retrieved this holder, it is just a matter of manipulating its internal key/value pairs store, to provide the extension methods that creates the illusion of having extended meta-properties.

The real code is, obviously, more complex, as it intercepts a number of errors throwing the exceptions needed, and a number of methods have been refactored for simplicity. Also, in this V2, the code has been modified to take into account what is explained in the next section.

A Note of Caution

It has been mentioned before, but I would like to emphasize that this solution can only extend instances of classes. It does not work with structs and enums.

On the good side, it works with any instance of any class without requiring you to do any special thing. Once a reference to the namespace is set, it is just a matter of using the extension methods.

Using the Examples Provided

Please uncomment the "#undef DEBUG" directive if you don’t want to see the traces and debug information.

What's New in Version 2: Disposable Scenarios

When the host instance is finalized, its metadata is finalized as well. But without using proxies or interceptors, there is no way to guarantee we will be informed when a given instance is disposed. In this case, the standard, simplest and safest rule is not to store objects that need to be disposed in the extended meta-properties.

Is this a strong limitation? Well, it really depends on your scenario. For instance, instead of storing a Connection object, why not just try to store its ConnectionString property, which is not an unmanaged resource we need to dispose when it is no longer needed? If this is your case, you can go with the solution as it is today without using the optional mechanism described below.

So, now, what if you have no other choice but to store in the meta-properties objects that will need to be disposed later? Typically, when its host object is disposed.

Version 2 of MetaPropertyExtender implements an optional mechanism to help you achieve something similar. Basically, it consist in:

  1. a list of WeakReferences that tracks those objects that have been extended, and that at the same time implement IDisposable, and
  2. a timer that raises an event that validates what of those objects are still alive or not. If they are not alive, then its meta-properties are processed to dispose those values that implements IDisposable, and whose AutoDispose property is set to True.

Note: This AutoDispose property is set as the third and optional parameter of the SetMetaProperty() method, which is True by default. If you don't want your value to be disposed automatically, even if it implements IDisposable, then set this AutoDispose property to false.

It is an optional mechanism. It only starts to keep track when you use the StartCollector() method of MetaPropertyExtender. It accepts an optional parameter that lets you tweak the interval (in milliseconds) at which the event is raised to accommodate to your particular needs, performance restrictions, or your particular taste. You can call this method several times, with the effect of modifying the interval of the timer.

You can also stop the collector with the StopCollector() method – note that in this case any object that may remain in the internal list of tracked objects is not processed... but is not removed from this list. So, if you start the collector again, they will be present and ready to be processed.

Yes, I agree, it is not as deterministic as calling Dispose() on those values stored in the meta-properties (*), but if you decide not to check manually for the existence of meta-properties on your host instances, or maybe you cannot because you cannot alter them, this is a fallback mechanism that may help.

(*) Firstly, there is the delay at which the timer ticks. But also note that even if you call Dispose() on an object, for whatever reason it appears as alive for a long time before in the weak reference it is identified as disposed (alive being false). Seems to be related to the cadence at which the GC runs, but I cannot assure it completely. So, as it is now, there is no way to be immediately informed that Dispose() has been called in the host object. At least, no way that I know (or wanted to implement).


  • [v1, May 2012]: Initial version
  • [v1, May 2012]: Version 2 - Including an optional collector to dispose values stored in the meta-properties, if needed


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Spain Spain
mbarbac has worked in start-ups, multinational tech companies, and consulting ones, serving as CIO, CTO, SW Development Director, and Consulting Director, among many other roles.

Solving complex puzzles and getting out of them business value has ever been among his main interests - and that's why he has spent his latest 25 years trying to combine his degree in Theoretical Physics with his MBA... and he is still trying to figure out how all these things can fit together.

Even if flying a lot across many countries, along with the long working days that are customary in IT management and Consultancy, he can say that, after all, he lives in Spain (at least the weekends).

Comments and Discussions

PraiseGet Attributes Issue Pin
Member 1356749819-Oct-19 19:24
MemberMember 1356749819-Oct-19 19:24 
Question'This host does not carry a meta-properties holder.' occurs in Remoting Pin
M J Pavan Kumar22-Mar-16 19:44
MemberM J Pavan Kumar22-Mar-16 19:44 
AnswerRe: 'This host does not carry a meta-properties holder.' occurs in Remoting Pin
mbarbac23-Mar-16 0:10
Membermbarbac23-Mar-16 0:10 
QuestionWould a static Dictionary do the same thing? Pin
aodennison5-Mar-15 18:31
Memberaodennison5-Mar-15 18:31 
AnswerRe: Would a static Dictionary do the same thing? Pin
Member 1115066229-Sep-15 8:44
MemberMember 1115066229-Sep-15 8:44 
GeneralRe: Would a static Dictionary do the same thing? Pin
mbarbac29-Sep-15 14:58
Membermbarbac29-Sep-15 14:58 
QuestionMix DependencyProperty and extensions methods Pin
Member 44327731-Jan-14 8:27
MemberMember 44327731-Jan-14 8:27 
AnswerRe: Mix DependencyProperty and extensions methods Pin
mbarbac3-Feb-14 2:01
Membermbarbac3-Feb-14 2:01 
QuestionA small oddity Pin
AllenRogerMarshall8-Nov-13 9:43
MemberAllenRogerMarshall8-Nov-13 9:43 
AnswerRe: A small oddity Pin
mbarbac8-Nov-13 11:32
Membermbarbac8-Nov-13 11:32 
GeneralThoughts Pin
PIEBALDconsult21-Sep-13 7:28
professionalPIEBALDconsult21-Sep-13 7:28 
GeneralRe: Thoughts Pin
mbarbac21-Sep-13 11:11
Membermbarbac21-Sep-13 11:11 
GeneralRe: Thoughts Pin
stixoffire11-Jan-17 19:58
Memberstixoffire11-Jan-17 19:58 
GeneralRe: Thoughts Pin
PIEBALDconsult12-Jan-17 3:33
professionalPIEBALDconsult12-Jan-17 3:33 
QuestionA useful extension method Pin
zolitamasi21-Sep-13 6:44
Memberzolitamasi21-Sep-13 6:44 
AnswerRe: A useful extension method Pin
mbarbac21-Sep-13 11:13
Membermbarbac21-Sep-13 11:13 
QuestionA question about extension methods Pin
hinst18-Jan-13 8:45
Memberhinst18-Jan-13 8:45 
AnswerRe: A question about extension methods Pin
mbarbac20-Mar-13 15:03
Membermbarbac20-Mar-13 15:03 
QuestionThanks Pin
Praveen Kumar Prajapati19-Nov-12 1:42
professionalPraveen Kumar Prajapati19-Nov-12 1:42 
Nice Article. Thanks.
AnswerRe: Thanks Pin
mbarbac19-Nov-12 2:13
Membermbarbac19-Nov-12 2:13 
QuestionMinor correction about GC and Dispose() Pin
DaveBlack20-Jun-12 8:09
MemberDaveBlack20-Jun-12 8:09 
AnswerRe: Minor correction about GC and Dispose() Pin
mbarbac21-Jun-12 1:44
Membermbarbac21-Jun-12 1:44 
GeneralRe: Minor correction about GC and Dispose() Pin
DaveBlack21-Jun-12 4:34
MemberDaveBlack21-Jun-12 4:34 
GeneralMy vote of 5 Pin
Ștefan-Mihai MOGA16-Jun-12 21:15
professionalȘtefan-Mihai MOGA16-Jun-12 21:15 
GeneralRe: My vote of 5 Pin
mbarbac18-Jun-12 1:20
Membermbarbac18-Jun-12 1:20 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.