".NOT" Components

Dr. Dobbs has an interesting article by Frank Wu called .NET Versus .NOT… Frank talks how to spot a great .NET Component.  Customers can clearly tell if a component was designed for the .NET Framework or not.  Component vendors, both inside and outside of your company, should understand what makes a good .NET Component to make developers as productive as possible…


As Frank says, there is a time for both kinds of components, but users should understand which they are using.  I’d generalize Frank’s list of what makes a good .NET Component and just say a good component follows the .NET Framework Design guidelines (more). Is anything else needed?   😉


I’d love to hear some examples on good and bad .NET Components you have had the joy or misfortune to use.


Comments (20)
  1. I’ve been resisting any and all third party sever controls (Infragistics, etc). I have a strong impression that their developers are in disconnect with reality of what’s "kool" and what’s appripriate on the web. My question still remains, "Does anyone REALLY use a triple nested data grid control which produces a ton of messy markup?"

    I don’t know why it escapes control vendors: to make their controls truly usable, you need to make them LIGHT, not heavy.

  2. Ben says:

    I just recently used the pdf control from ceTe (http://www.cete.com) to programmatically fill pdf forms, and its great! The apis are all .net styled, strongly typed (not just passing objects everywhere) and it comes with the xml documentation file.

  3. MonkeyKoder says:

    dotnetCHARTING … an easy to use charting control that creates beautiful images right out of the box. the classes are so well designed that 90% of the time I can just guess at where something should be, and with a little intellisense goodness I never even have to refer to the docs. I’ve used this on three projects now and absolutely love it. and, it even has dotnet in it’s name!

  4. Jeff Parker says:

    Really I also have avoided 3rd party components. I do not see much need for them. The .net framework makes it very easy to create your own and as long as you follow the design guidlines set by Microsoft you should have no trouble.

    Some of the asp.net controls in the framework I do not use, or really I end up overriding some of the methods, bad html markup, and such, when the asp.net controls work pass the w3c validator there is a problem. I know I do not have to and I know the browser will render it even if the tags are in caps or not or not properly quoted. However I read an article this morning that I think describes why it drives me nuts having the bad markup in there and why I avoid several 3rd party controls.


    Are programmers artists. Yes I think we are. We are moody, broke, misunderstood, passionate about our craft, and if done well most people don’t see/get the hours that underly the elegant end result. While most users would never notice bad html markup, I would know it is there.

  5. Kevin Dente says:

    Bad 3rd party component APIs? I’d say just about all of them. Particularly bad are the ComponentOne controls – they have always had totally whacked APIs, even back in the ActiveX days, and they continue the trend in their .NET stuff. GraphicsServer.NET is also goofy (WebControls configured though an escaped XML string on the page – shudder).

    On the other hand, these controls are quite powerful, and we use them to great effect (especially since MS refuses to give us a hierarchical grid control :P). But sometimes their APIs make me want to claw my eyeballs out – I wish they’d invest the effort to write more .NET-ty code.

  6. heaths says:

    In a previous company we evaluated a control that was a thin .NET wrapper around many native and VB DLLs. Definitely not intended for ClickOnce or the older internet deployment models.

    I do see a lot of controls, however, both from third party companies and individuals that do not following naming conventions, ex. using Java-style conventions. Such vendors should realize that they’re only hurting their prospective users by not following the same conventions as the Framework upon which they’re built, and that other vendors do. Just look at the BCL class and member names for examples at the very least.

  7. I would say not only should a good .net component follow the design guidelines, it should be designed with an eye toward usability, as defined by Steven Clarke in his excellent blog.

    The BCL members are not always the best examples. Some of the classes defined early on are not so usable.

  8. I have had the displeasure of working with the Infragistics components. Powerful, yes. But if you need to do something that *should* be simple (eg. change a colour) then you’ll need to set aside half an hour to do so.

    I think part of the problem is that the libraries are developed over a long period of time by the same devs. The devs are so intimate with their own library that they lose sight of its growing complexity.


  9. Working myself for a component vendor (Xceed), I find that very interesting to read those comments. I think Kent really hit the nail by saying component developers get too intimate with their product and loose sight of its "on-the-field" actual usage, cons and pros, and where developers loose time using it.

    I know my products better than anybody else, so I cannot anymore objectively judge of their ease of use. I could more easily at their beginning. That’s why we constantly need your feedback, and we’re listening.

    But I think the ratio complexity versus ease of use is a trade off you must accept to a certain degree, because component vendors have one big constraint others don’t have when they make a component only for their apps: while they only need to expose the features necessary for that application, 3rd party components must expose all possible features (or at least target that), else they won’t meet enough requirements .

    Our challenge is to package full-featured components designed as simple as possible. I’ve always considered the "public interface design" phase the most important for a component.

    One thing’s for sure, if a component has a big learning curve, it’s missing the target.

  10. Cheong says:


    I’ll agree there is trade-off, but the learning curve didn’t necessary be too steep. I always wonder why component developer don’t try to build component of different level of ease of use – A lightweight version with most settings set to the most common ones so it’s most easy to use but not that flexible, an advanced version which those common settings are customizable, and a professional one which may expose features that only the "experts" who demands the microscropic control of the component will use.

    That’s ideal, and sure development companies won’t mind to pay a little more to push the overall RAD performance.

  11. HakonB says:

    Is it just me or is the examples that Frank W. Wu presents rather poor?

    Look at this:

    Base d = new Derived();

    if(d is Base)


    Base b = d as Base;


    How can ‘d is Base’ ever be false? Also, as far as I remember the ‘is’ and ‘as’ is almost the same operation – the ‘is’ just returns a boolean by comparing the ‘as’ result to null. The result is two "slow" casts where only one is needed.

    A much better example would be:

    Base d = new Derived();

    if(d is Derived)


    Base b = (Derived) b;


    Here only one slow cast is used and when verified that d can be assigned to b then b will be assigned.

  12. I would definitely say that IBM’s MQ-Series 5.3 .NET Client is a .NOT-component along with the MSMQ implementation in .NET. Although the MQ-S client is worse MSMQ. It feels like both are just simple wrappers around the C++ API’s.


    1. Using constants for options instead of enumerations. Since the method parameter for options is defined as integer, you do not have a clue on what options are available for the method without having to look in the documentation.

    2. Not implementing IDisposable! You cannot use the using statement to make sure that queues and channels are closed if an exception is thrown.

    3. There is only one exception class for all exceptions! You have to check an error code in the exception object to find out what kind of error was thrown.

  13. Rocky Moore says:

    The only component I have actually purchased for .NET was an ASP.NET grid control from DevExpress. While the control does what I required, digging through the code seemed more like a port from Java than one built for .NET. Even when controls say the are 100% .NET, that really does not mean much, while they may be all .NET code, it does not mean that it is code focused on .NET.

    I would imagine many other controls are pushed out the door the same way. When I came to .NET in the betas, I found many of my program designs changed greatly. Probably many controls focus on getting it out the door "translated" to .NET, but not really "designed" for .NET.

  14. I don’t like the Dr. Dobbs article. The author promotes violation of license agreements — most commercial one explicitly forbid decompiliation. And the authors "test" for "true" .net components is naive — poor components could pass, good components could fail. A better test is for usability and adherence to design guidelines.

  15. I just got through reading Blink : The Power of Thinking Without Thinking … well, ok I actually listened…

  16. I just got through reading Blink : The Power of Thinking Without Thinking … well, ok I actually listened…

  17. I just got through reading Blink : The Power of Thinking Without Thinking … well, ok I actually listened…

Comments are closed.

Skip to main content