Drew's Blog

Jumpin' on the BlogShares.com Bandwagon

BlogShares looks like fun and is an interesting use of all the data flying back and forth between weblogs out there. Should be interesting to see who generates the most link value within the .NET community.

Great Article On Data-Binding To Custom Types

Here's a great MSDN article on data-binding to custom types and collections of those types. It covers topics such as:

• Property Change Notifications
• Implementing IBindingList on collections classes
• Implementing IEditableObject on bindable classes
• Implementing IDataErrorInfo on bindable classes

Overall I found the coverage of the features in this article to be excellent and a great extension to the SDK's basic documentation on the subject. I definitely recommend it to anyone who is writing their own business objects which they wish to use in data-binding scenarios.

McNealy says .NET is a joke

On a tour of Asia, the Sun Microsystems' CEO hits out at rival Microsoft, saying that viruses are a feature in .Net Microsoft and that Java is tops for developers. [CNET News.com]

Umm... yeah. Can you say FUD?

The only known .NET related virus is W32/Donut and it's so lame it's not even worth wasting bandwidth discussing any further. Get back to us when you can actually show us a managed .NET virus.

Update:

Phil Scott pointed out W32/Sharpei@MM in the comments . Thanks Phil, I had forgotten about this one. So that makes two, but technically it takes advantage of the same exploit: hijacking the executable bootstrap generated for .NET console/winforms application images. Again it's so lame that it's called a C# virus when really it has nothing to do with .NET (let alone the C# language). In fact the article even mentions that the user doesn't even need to have .NET installed. Hello?? Doesn't this set off a flag in intelligent peoples' minds? I remember a time when certain Java compilers/VMs offered the option to generate a bootstrapping .exe too. The same exploit could be leveraged on those as well.

Events: How They Work In C# and General Component Design Techniques

I just finished an MVC implementation for WinForms as a tutorial for whomever and as a walkthrough for myself to see if I could find a nice tidy way to organize my ever increasingly Forms classes. I noticed something I just can't figure out.

When publishing an event that noone subscribes to I get a nullreference exception. There are no way (as I can see) to instantiate the Event in and make sure it's not null so I had to go like this:

... code snipped for brevity ... (ed.)

Is this really the only way to do this? Have I missed out about something with publish/subscribe? It should be possible to scream although noone is actually listening..

[mads studentblog]

Yup. That's just the way C#'s event keyword works when used in it's abbreviated form. An event is really nothing more than a glorified multi-cast delegate. When defining an event in .NET you're essentially just specifying metadata on your type that says "Hey, I have an event called 'XXXX' and here are the two methods you can use to subscribe and unsubscribe.", much like a property is just metadata that points to a pair of get and set accessors. So when you define an event in C# using the abbreviate form the compiler is generating add and remove event handler methods for you behind the scenes. The implementation provided will defer instantiation of the event delegate until the first subscriber to the event invokes the add_XXXX event subscription method. Therefore, you must always test your event delegate for null before invoking it.

Now, something that a lot of people who are new to C# don't realize is that you can take full control of the event registration methods yourself by taking the event declaration a step further, like so:

public event EventHandler MyEvent
{
    add
    {
        ...
    }

    remove
    {
        ...
    }
}

You can more about the C# event keyword right here in the SDK.

The prime example of custom event subscription methods is the Windows Forms Control architecture which makes extensive use of this technique to reduce the potential overhead associated with the many of events on control instances that are likely to never even be subscribed to. The architecture accomplishes this by storing the delegate instances in an event hashtable on the control instance (see Component::EventHandlerList). The hashtable is keyed by a static object references representing each event. Should someone subscribe to a particular event, the delegate is created at that point and cached for the control instance. This can signifigantly reduce the size of each control instance by saving the memory of N delegate member variables weighing in at the cost of a reference variable each. When you consider the fact that the base Control class has 58 events itself and the cost of a reference variable in the Microsoft .NET runtime on the x86 platform has a native size of four bytes (32-bit pointer) that's 232 bytes saved per Control (or subclass) instance. This is a pattern that all component developers should take into consideration when they hit the optimizing stage of their product. This pattern and more details about events in .NET are discussed here in the SDK.

Taking Custom Configuration Sections A Step Further

Something I've found infinitely useful is custom configuration sections By using custom configuration sections, you are allowed to store a richer amount of information in the application config file, than when you simply add values to the <appSettings>section.

To add a custom config section, you must do 2 things: 1) declare the section group and section in the<configSections> portion of the app.config file, and 2) add the new sections to the config file.

[.NET Brain Droppings]

Yup, it's cool, but it gets even cooler when you start writing your own configuration section handler implementations. The beauty of the configuration architecture is that it's completely extensible. To hook into the deserialization process all you need to do is implement a custom IConfigurationSectionHandler. The first time someone requests your named section via ConfigSettings::GetConfig, your implementation of IConfigurationSectionHandler::Create will be called and handed an XmlNode which you can then parse and turn into your own typed configuration object. This just opens infinite possibilities and builds upon the power of XML when it comes to embedding documents.

The prime example of a custom section handler that a lot of people seem to be into lately is the all purpose XmlSerializer based configuration section reader which deserializes sections into .NET types using the power of the XmlSerializer.

The final thing to remember about the configuration system is that it's heirarchical. Enterprise settings, Machine settings and Application specific settings are all unioned together to present a unified configuration to each application when it runs. ASP.NET takes this a step further allowing another N steps in the heirarchy according to virtual application directory structure.

Solid Advice On Preferring Overriding To Base Class Event Registration

I can't remember the last time I've been handed source code for a Form- or UserControl-derived class that didn't include a handler for its own Load event. Why is this? Sadly, I know the reason... [Shawn A. Van Ness's Blog]

Some solid advice from Shawn. He explains the common WinForms scenario, but it really applies in any component inheritance scenario. For example with ASP.NET, it's mainly the Control::Init and Control::Load events that people end up doing this with. I've tried to explain it on DOTNET mailing lists on a couple of occasions, but I still see people doing it from time to time. As Shawn points out, it's not really a serious problem, but it's just not the best practice. With .NET, we're living in an OO world, we should take advantage of it and prefer method overriding in these scenarios.

Oh... and on the flip side of the coin, whenever you're designing a component, make sure and follow the recommended design guideline of defining a protected virtual On<EventName> method that inheriting classes can override.

Understanding SOAP

There's a new article up over on MSDN under the XML Web Services section entitled Understanding SOAP. The author is none other than DevelopMentor XML guru Aarron Skonnard. In the article, Aarron covers SOAP from a pure XML protocol perspective; no specific client/server implementation is discussed. Next to only the specification itself, this is the best piece of reading anyone looking to learn the protocol should check out.

WSE SDK SP1 Released

The first update for the Web Service Enhancements for .NET is now available. You can get in details about what has changed from the release notes.

I haven't personally built any production code with WSE yet, so I can't really speak to how important any of these improvements/fixes are. It looks like they've done some major performance tuning, but most of the fixes seem related to the XML Signature implementation.

Two New .NET Articles Up On O'Reilly

There's a couple of new articles up on The O'Reilly Network today. The first is about one of the coolest and frankly the most powerful data binding controls in ASP.NET: The Repeater. The author does a great job breaking down the different templates and how they are used. He also gives a breif example of how to add a button to the item template. IMHO, the beauty of the Repeater lies in it's ability for an data item to be represented by basically any form of content the developer chooses. An HTML table is the obvious choice, but it could be any possible text format that you need to emit.

The second article is Sam's second on MC++. In this part, he covers the mixing of managed and unmanaged code. He covers topics such as IJW, pinning pointers and using managed code from unmanaged code. He promises a more in depth look at IJW in his next part.