Oww, my brain hurts. Extension methods *will* cause me grief.

As a consultant, a task that I’m commonly asked to perform is to troubleshoot applications in need of repair.  The underlying source code and architecture for many applications in need of repair has, let’s say, “problems”.  One of the issues I run into with circumstances like this is the source code was not well organized, not well thought out, or not well managed as it evolved.  This type of code has poor style, poor coding habits, and often the programmers have code stepping all over other code through lack of cohesion and excessive coupling. 

Believe me, as Visual Studio codenamed “Orcas” is released and proceeds into production development environments, I fully expect my life to get worse with increased fragility of code bases.  I ran into a lovely compile error today with the most recent .NET Framework 3.5 that confirms my fears. Essentially, the code has two extension methods with the same name and the same number of arguments in two different namespaces.  The first argument is the same in each, but the second is different; and, in fact, one is a reference type while the other is a value type.  In code that uses one extension method (the one with the second argument of reference type), simply by adding a using statement for the other namespace, caused the following error to occur:

test.cs(14,26): error CS1928: ‘string’ does not contain a definition for
        ‘IsPlural’ and the best extension method overload
        ‘Peter.Extensions.IsPlural(string, int)’ has some invalid arguments
test.cs(14,40): error CS1503: Argument ‘2’: cannot convert from ‘<null>’ to

Hmm, this error confirms that there is more than one IsPlural extension method and goes on to tell me that the “best” override has invalid arguments.  Huh?  How is it the best if it has invalid arguments?  Why would it consider passing null where a value type is expected the “best” override?  I really hope this doesn’t make it into RTM.

Oww, by brain hurts.

"Invalid menu handle" Opening Downloaded .ZIP Files (IE6, XPSP2)

I’m working on a new, least-privileges, computer and I ran into a very strange problem yesterday.  If I click on links to .ZIP files in IE and select Open,the file downloads but I’m presented with an “Invalid menu handle” message box.

I’m not the person who configured this computer; so, I wasn’t entirely sure what the problem could be.  I had surmised that it had something to do with least-privileges and compressed (zipped) folders’ ability to operate in that type of environment.  I tried Save, instead of Open, when clicking the link but had no problems double-clicking the zip file in Windows Explorer.

The computer is configured so some of the user files are stored on a network drive, so I then thought it had something to do with permissions on non-local drives (really least-privileges I guess); but the temporary Internet files are indeed stored on the local drive.

At this point, I was wandering around in the temporary Internet files directory and double-clicked the zip file, and this time it informed me that “This page has an unspecified potential security flaw.”  With not much to go on, and the fact that I was having problems with *many* .ZIP files, I pressed Yes to continue.  Windows Explorer then asked me how to open the file–as if it hadn’t associated compressed (zipped) folders with .ZIP files.  I was a bit dumbfounded, as that was my first course of action (to try double-clicking a .ZIP file in Windows Explorer and had no problems).  At this point I simply clicked compressed (zipped) folders and ensured “Always use the selected program…” was checked and pressed OK.  After that, I could then Open .ZIP files after clicking links to them in IE.

I’m not sure how the computer got into that state, or whether it was simply that directory (or the hierarchy it was in); but the problem is fixed.

If you run into the same problem, now you know what to do.

.NET Framework 2.0 Service Pack 1

I noticed mention of .NET Framework 2.0 Service Pack 1 on a Microsoft site today.

The BCL Team’s latest blog entry http://blogs.msdn.com/bclteam/archive/2007/05/21/the-regexoptions-compiled-flag-and-slow-performance-on-64-bit-net-framework-2-0-josh-free.aspx mentions a fix that will make it into the .NET Framework 2.0 SP 1.  Seems an inevitable release of SP1 for .NET Framework 2.0 is pretty official.

Accumulative Construction

A while back someone asked for guidance on what order should polymorphic construction occur in C# classes.  I guess I had never really put much thought into it before and have never seen other guidance on the topic; but, I can see where this can become a valid design consideration.

 Polymorphic construction is when a class has more than one constructor.  If one constructor reuses the services of another constructor, I’ve coined the term Accumulative Construction, i.e. through successive calls to potentially many constructors.

Here’s some guidance that serves me well:

Polymorphic constructors should be called from most specific to least specific.

For example; you may want to write class with several parts to its invariant, where one or many of those parts may have defaults or are optional.  In this case you may provide several constructors allowing the user to construct your object in different combinations of required and optional information.  In cases like this, the most specific constructors should call least specific constructors.

    internal class Person


        int age;

        String firstName;

        String middleName;

        String lastName;


        public Person ( String firstName, int age )


            this.firstName = firstName;

            this.age = age;



        public Person ( String firstName, String lastName, int age )

            :this(firstName, age)


            this.lastName = lastName;



        public Person ( String firstName, String middleName, String lastName, int age )

            :this(firstName, lastName, age)


            this.middleName = middleName;



        // properties and methods follow…


This nicely matches generally accepted exception handling: order catch blocks from most to least derived class (which is detected automatically by the C# compiler).