Posts Tagged ‘Type Aliases’

C# Using Alias Directive, Namespace Alias Qualifier and a sad story

Following up on my last post:

I’m copying from a mental note I added to:

As shown at:


you can do:

using gen = System.Collections.Generic;

using GenList = System.Collections.Generic.List<int>;

and then use

gen::List<int> x = new gen::List<int>;


GenList x = new GenList();


you have to replicate those using definitions at every file where you use them, so if you make some changes to them in the future and forget to update at every file, things will break badly.

I hope C# in the future will treat aliases like the do with extension methods and let you define many of them in a file that you use elsewhere, then maintain them at one place and hide the internal unnecessary type mapping details from the type consumers.


BTW, another issue that makes me very sad to see reoccuring. Somebody (probably a moderator) replied at that StackOverflow page above that this was an old (some year and a half ago) discussion. My reply there (I’m glad that made him remove that remark, hope I proved the point):

I do know this is old discussion, but I just had the same issue and search engine took me here – why should I care if this is old discussion? Are we doing the news?

I get even worse behaviour in Microsoft Forums (or was it Microsoft Answers?) Silverlight Forums – moderators just delete any new posts at older discussion threads (they hadn’t even bothered to lock those discussions first). The just send you a lousy e-mail about the delection of your reply without sending you the deleted content (so the time you spent posting a sometimes detailed mental note as a reply there is totally wasted if you didn’t record that reply / mental note elsewhere). You can’t even reply to their e-mail with a counter argument.

They don’t really get it that people come across these matters again and again and they get to discussions that have partial information cause nobody bothered to add some mental notes after they found the answer to the issue.

The Silverlight Forums admin reply says:

The thread to which you have attempted to reply is a very old thread, and there is no value in reviving it. As a consequence, the above post has not been approved. Replying to very old threads (aka Necro-Posting) is discouraged on the forums as it moves those old threads ahead of the sites more recent threads. We ask all members who are offerring answers to please stick to the site’s more recent threads.

If only I could reply back (you can’t):

This is nonsense, search engines don’t care of the order you show them. People go there from search engine results and find poor, non-updated replies. Think for example some issue discussed and workarrounds posted. A visitor thinks it still occurs since nobody cared to note that some newer version of Silverlight fixed it / implemented it! Or imagine that there is now a better answer to a recurring old question (that search engines keep guiding people too) due to newer developments. Just fix your forum system to not bring very old-started threads to top unless admins decide to sticks them to top. Don’t waste our time please.

Those guys haven’t even bothered to update their e-mail templates and still have references to dead URLs like:

Your post was submitted as a reply to the following thread:

Since I couldn’t reply to the post delection e-mail (reply gets rejected), I opened up the issue at their forums, so please raise your voice there too if you agree with the above concerns:

(wonder why that forum post doesn’t show up there currently – some people don’t like to hear the truth when it doesn’t suit them?)

How to compile code that uses WPF Decorator type in Silverlight

At ClipFlair I’m using a modified version of FloatingWindow control, where I try to make the WPF and Silverlight flavours of the original control share as much code as possible (this is work in progress currently, hoping to eventually have the WPF and Silverlight projects both link to the same source files [this is currently true for most of those files]).

With the ControlExtensions.cs file there (which has some useful extension methods for WPF and Silverlight controls), I had an issue, since they were very similar, apart from the fact that the WPF version had 2 methods that were using Decorator type in their implementation, whereas the Silverlight ones were identical apart from using the Border  type.

WPF’s Border class extends WPF Decorator, whereas Silverlight’s Border doesn’t since Silerlight doesn’t have a Decorator class at all (to keep the size small for quick web installation they cut-off needless parts of WPF, that’s why they call Silverlight a small sibling of WPF [used to all call WPF/E if I remember well]).

Seems there’s a quick trick one can pull out to overcome this, based on C# support for “Type Aliases” with the using directive. You can add to the problematic source code file (either outside or inside any namespace declaration you have there), the following:

using Decorator = System.Windows.Controls.Border;

Then in that source code file you just use Decorator instead of Border for both WPF and Silverlight. Of course this works in method bodies, if you want to have that type in method parameters else well, you have to put the above type alias definition (called Using Alias Directive) in every source code file that uses this class. I’d prefer to put this in my WPF_Compatibility layer at ClipFlair codebase, but C# support for type aliases is very limited unfortunately, so I put a dummy WPF_Delegate.cs file there with the above usage info.

Isn’t it sad that you can place extension methods in existing namespaces, but can’t place type aliases similarly? In fact you can’t place say some of them in a file and refer to them alltogether, you have each user of your types replicate those using definitions to all code units where they use them. If you change somethine in the future in those definitions, things will break since some files will have outdated definitions (apart from having consumers of your types see unnecessary implementation details). I guess we need Alias Types, not Type Aliases (sic).

To see this in action, you can try opening in Visual Studio the FloatingWindow solution under Client folder of source code base. You’ll notice the file Extensions/ControlExtensions.cs has a small arrow icon on it at both the Silverlight and the WPF projects, since it’s a link (added to both the projects using Add Existing File and clicking the dropdown menu next to the Add button to select “Add as Link”).

Speaking of file links in Visual Studio 2010, there seems to be a bug there. If you remove (not delete) a file from a project, then move that source file to another location (say one folder higher and into a Common subfolder), you can’t add the file to the project anymore till you Close the project (or right-click and Unload it) and Open it again (or reload it into the current Solution).

%d bloggers like this: