Arthur C. Clarke once said "Any sufficiently advanced technology is indistinguishable from magic"
A few times recently, I've been in a situation where I just wanted to hold my head in my hands and groan "Noooo not again!! make it stop!!". Why? Well, because even after seven years of .NET people still don't get the idea of what advantages there are in fully embracing the framework's philosophies to create really great applications or components.
Imagine dumping a medieval man into the middle of London. Aside from the obvious initial shock, he'd become used to the idea that cars travelled about without horses attached to them, he could even learn to drive a car. He would become used to the idea of lighting without flames and he'd eventually become a consumer of fish and chips or MacDonald's burgers without necessarily understanding how it all happened or what made it all tick. After his short period of adjustment that went from screaming fits and soiling himself with fear, we would eventually get someone who can function just fine in the environment. Whether he could design a car or grasp the concepts of electricity would be however, a different subject entirely.
This is the sort of thing that happens when someone who is "expert" in 1990's technology gets hold of the concepts of third millennium .NET framework. They become a perfectly adequate programmer, able to apply their concepts of programming to C# or VB.NET and as long as their efforts are contained within a single sealed up application all is well and you can't tell the difference from the outside.
What happens however when that person, however innately intelligent they may be, applies 1990's ideas to .NET architectures and has the responsibility for creating, say, a huge data management framework of industrial proportions? You guessed it. A complete and total disaster that does nothing but make people groan with disbelief.
For me, the best aspects of .NET architecture are the ones that don't fall readily to mind, even if you're a world-renowned C++ guru and have 20 years of experience in your field. For example, the idea that your objects may take part in a design time environment. This was not even a possibility in the old world of C++ but now you should seriously consider whether your objects should at least carry the attributes such as Browsable, Description, Category etc. Furthermore, you should ensure that your object has a type-conversion strategy, should implement ToString correctly, provides a design-time editor, possibly a graphic editor, certainly a smart-tag, some designer verbs and so-on.
When designing an architecture today, we also need to look to current trends in data-binding. It used to be that tying an object to a GUI was a laborious process that required either brute-force, the preferred C++ method, or implementation of some pattern such as Model View Controller (MVC). Any remotely skilled Windows Forms engineer will immediately use data binding which neatly sidesteps these issues. However, the objects in question need to either provide changed events for properties or implement INotifyPropertyChanged. So, I hear everyone reading this beginning to say "Well, if the object is some deep part of a framework and not exposed to the GUI, why bother?" The answer here of course is that data-binding is no longer a GUI only issue. .NET 3.0 and 3.5 already has data binding that can take place between any two properties so that otherwise invisible objects can be bound. This is not only interesting for WPF maniacs but for anyone who has an object that receives input from another.
Finally, meta data and reflection coupled with new type description systems are so powerful that it adds vast new aspects to object orientation that are so outside the realms of the classic Encapsulation, Inheritance, Polymorphism triad that classes have ceased to become immutable definitions and have entered the realms of chimeric virtual objects that appear to be one thing when they are, in reality, something totally different.
If you're an architect and expecting to create a framework for your flagship product by all means pick .NET. Just don't go blundering about like a medieval peasant when you could be using magic instead.
