Michael,

The toolssets from the big vendors (Infragistics, Telerik, ComponentOne, etc) are used primarily in an Intranet multi-developer environment.  The features of their controls (we use Infragistics) allow for building the UI significantly faster that rolling your own and in most cases this is beyond even the best developer.  The list of controls is a developers dream... Infragistics NetAdvantage for ASP.NET .  New controls and updated features every 4 months.

You must, howerver, make a commitment to a specific vendor for cost and learning curve reasons.

I would caution 3rd party developers to be sure their customers understand that different versions of these vendors controls do not mix.

mikez

Dynamic compilation will not help in this case, and it is not really an answer in any case.  
Even if you compiled the 3rd party source into your own component it would still use the same namespace and in that case you would get ambiguous namespace collisions.
I guess if you spent enough money for full source including re-distribution rights and then changed the 3rd party's Namespaces to your own, you may be able to get around this issue, but that is far from a viable work-around.

There is not a good work-around for this type of DLL Hell that still exists in any application that uses shared components.  
The best you can do is hope that the 3rd Party control vendor maintains backwards compatability, and in that case the end user may still have to insure that they install the latest version last.

Another work-around is strong naming and placing the different versions in the GAC, but that is not really viable either. http://msdn.microsoft.com/msdnmag/issues/01/03/buildapps2/default.aspx

IWeb  is an module that is basically a shared component. Because it is a dynamic module when it it updated the existing files are overwritten. There is no .dll hell.