Omer van Kloeten's .NET Zen

Programming is life, the rest is mere details


Note: This blog has moved to

Omer van Kloeten's Facebook profile

Omer has been professionally developing applications over the past 8 years, both at the IDF’s IT corps and later at the Sela Technology Center, but has had the programming bug ever since he can remember himself.
As a senior developer at NuConomy, a leading web analytics and advertising startup, he leads a wide range of technologies for its flagship products.

Get Firefox

powered by Dapper 

.NET Resources

Articles :: CodeDom

Articles :: nGineer



April 2007 - Posts

Extension Methods and Trust

As much as I love the idea behind extension methods, I can't help but start to think about how it could be used for malicious purposes.

Take this scenario:

  1. You're a disgruntled employee of Evil Inc., the makers of the well known library VeryUsefulAssemblies.NET.
  2. I'm a developer at Good & co., using your Tree<T> class in an assembly called Evil.UsefulAssembly.
  3. Before quitting your job, you decide to add an extension method, System.String.Format(params object[] args), that sends sensitive information back to you and then calls System.String.Format(string format, params object[] args) so no one notices.
  4. I have now unwillingly compromised all of my clients and could never know it, unless I manually check my IL or use a sniffer.

But wait! There's more:

  1. A fellow developer in my company, Norman I. Huntington, decides to write his own Tree<T> and replace all of the references to your Tree<T>, but he forgets to remove the reference to your assembly.
  2. Now my application doesn't even use your assembly, but is still hijacked!

Problem? I think so.

Extending the Idea of Extension Methods

I've had my fair share of disappointments when I found that the closest common denominator between types I wanted to use was object, leading me to write code in a level I did not like, like:

class A; // A and B are both imported classes with no 
class B; // common denominator except for object.

class MyListClass
    List<object> list = new List<object>();

    public void Add(object o)

The above means that I have waved my compile-time (and if it stays like that, also my run-time) type safety in favor of being generic. There are solutions for this, but how about we take the new extension method syntax and play with it a bit? Now that you can add new features to types using extension methods, why not extend entire types by implementing interfaces?

this class MyClass : IFitsTheList
    // Extension methods here, if you like...

This way, we could revise MyListClass to:

class MyListClass
    List<IFitsTheList> list = new List<IFitsTheList>();

    public void Add(IFitsTheList o)

Taking a complete type hierarchy and adding an Implemetation by Extension to the base class could prove to be a powerful tool.

Two Notes About Anonymous Types
  1. The example of anonymous types from the C# 3.0 specification document is as follows:
    class __Anonymous1
    	private T1 f1 ;
    	private T2 f2 ;
    	// …
    	private Tn fn ;
    	public T1 p1 { get { return f1 ; } set { f1 = value ; } }
    	public T2 p2 { get { return f2 ; } set { f2 = value ; } }
    	// …
    	public Tn pn { get { return fn ; } set { fn = value ; } }

    But why would you need properties? Aren't public fields enough? It's not as if a person has written this type or that it would ever be manually mantained or even looked at.
    (For the record: Object initializers work just as well with fields)
  2. An interesting concept regarding anonymous types was raised by a fellow user-group member, whose name escapes me, about optimization:
    Should I have the following code:
    var myValue = new { A = 2, B = 3 };
    It might prove faster to simply declare the new anonymous type as a value type and place it on the containing method's stack.
    This raised more thoughts about where the anonymous type should be placed - my view is that an anonymous type contained in a method (as it probably would, unless you trick it) should be a nested type of the method's containing type. This, in turn, both removes clutter from the namespace and allows the anonymous type to more easily adapt to the parent's generic parameters:
    class A<T> where T : new()
        void B()
            var myValue = new { C = new T() };
    // Turns into:
    class A<T> where T : new()
    // Note the use of a value type for a small type struct __Anonymous1 { private T c; public T C { get { return c; } set { c = value; } } } void B() { __Anonymous1 myValue = new __Anonymous1(); myValue.C = new T(); } }
    The only caveat is when the type is to be nested in a generic type, but doesn't use the generic parameter/s, it will be doomed to get re-JITed every time a different type calls is for no reason.
Windows Forms' GenerateMember

A little known, as far as I can tell from asking around, yet extremely useful property in the Windows Forms designer's property grid is GenerateMember.

Defaulting to true, it decides whether a control/component gets declared as a field on the form (true) or as a local variable in the InitializeComponent method (false). Setting it to false helps you remove some of the 'clutter' from your form, like those labels you placed on it, that you know you're never going to reference from your code. Now you don't even have to give them meaningful names in case someone bumps into them.

Justin suggested it might have been a better idea to default this property to false, but after considering this, I tend to disagree - I find that most of the controls I place on a form are referenced from my code and I'd rather have too many controls available than wondering where they'd gone.

Special Israeli User Groups Meeting - The Aftermath

Even though I arrived late to the IVBUG/IVCUG meeting today, I can say it was great listening to the lectures and talking to both Inbar Gazit and Lisa Feigenbaum.

I've taken quite a few notes during the meeting and I'll be posting about them soon, so stay tuned.

Special Israeli User Groups Meeting

Jackie has published a special IVBUG / IVCUG meeting on April 12. It's special because two Microsoft PMs will be lecturing this month - Inbar Gazit, a CLR PM and Lisa Feigenbaum, a PM on the Visual Basic team. They will also be answering questions and it sounds like it will be a great learning experience.

Finding Out Why Control.Invoke Throws Undocumented Exceptions

A colleague was baffled by having Control.Invoke (when called from a different thread) throw an ArgumentException at him and asked if I knew what was happening. Opening the stack trace, I found that the exception originated from Control.MarshaledInvoke:

       at System.Windows.Forms.Control.MarshaledInvoke(Control caller, Delegate method, Object[] args, Boolean synchronous)
       at System.Windows.Forms.Control.Invoke(Delegate method, Object[] args)
       [ user code...]

This meant that the exception was either raised from an undocumented source or that the exception had been rethrown with the original stack trace deleted.

To debug this further, I changed Invoke to BeginInvoke. to see if it might make a difference. This raised, instead of an ArgumentException, a TargetInvocationException, which in turn contained the original exception with its original stack trace. The problem was found and fixed.

More Posts