.NET Framework weaknesses to be avoided

views:

255

answers:

.NET Framework weaknesses to be avoided

Dupe: http://stackoverflow.com/questions/411906/c-net-design-flaws#411919

When I learnt the .NET Framework, I was pleased with the direction Microsoft was/is taking with their application development vision. There was a great sense of enjoyment and excitement developing on the .NET platform, with some areas delivering truly impressive concepts (like ASP.NET). On a whole, I am very happy to be a .NET developer, but I believe to possess an impartial opinion, I should learn to identify weaknesses in the design of the CLR and BCL models.

What are some weaknesses you have encountered, be it in the CLR or BCL classes or the language compilers, and have formulated workarounds to avoid having to use the commonly-practiced methods? These are not mistakes committed by end-developers, but what you consider "mistakes" by the Microsoft designers/developers.

Some examples include

Avoid passing DataReaders to the UI/page layer, and instead taking in delegates at the data layer to carry out data-binding.

+6 A:

You might be interested in a recent blog post I made about how I'd have designed System.Object differently. (Or rather, how I would now design System.Object differently - we only learn with hindsight, and most of my "insights" are really just recycled from other people anyway.)

Other points:

(Touched on in the blog post) If .NET had waited to get generics before v1.0, many things would have been cleaner
The date/time handling is much better in v3.5 than v1.0. It's been quite a gradual process though
There's no reason for the MulticastDelegate type to exist other than historical accident
Ditto the Nullable class (as opposed to the Nullable<T> struct). Pretty much everything from Nullable would be at least as well placed elsewhere, and you'd avoid having "overload by type parameter number" in the System namespace.

Jon Skeet 2009-01-09 13:09:45

Re `Nullable` - yes, it only has one especially useful method; presumably a static method on `Type` would have done.

Marc Gravell 2009-01-09 13:14:06

Yes, i am looking for these type of commentary, thanks. Do you have workarounds to make them work the way you want, though?

icelava 2009-01-09 13:19:33

None of the things I pointed out particularly needs a workaround - they're just areas where I'd have preferred a different design. It's more awkward to do things the way they're currently set up, that's all.

Jon Skeet 2009-01-09 13:22:11

+1 for MulticastDelegate! Fortunately, we don't have to use Delegate and MulticastDelegate directly that much.

Mehrdad Afshari 2009-01-09 13:27:36

I covered a range of these here - a bit of a mix of .NET and C# flaws, but there we are.

Marc Gravell 2009-01-09 13:12:30

From my very recent experience I'm discovering Thread.Abort is bit toxic

annakata 2009-01-09 13:24:44

Don't blame the code, blame the developer. Otherwise you could also blame throw ex; for stupid developers erasing the stack trace.

Geoffrey Chetwood 2009-01-09 13:37:30

Can you explain abit more where Thread.Abort is dangerous or unhelpful, and what are your workarounds?

icelava 2009-01-09 14:41:03

Ah nvm, i see your link is actually two links.

icelava 2009-01-09 14:44:23

@Rich B - the links explicitly say that Thread.Abort is inherently dangerous

annakata 2009-01-09 20:48:18

@icelava - can't help you with workarounds myself, I'm only just working through Thread.Abort issues myself.

annakata 2009-01-09 20:53:39

ansaurus

tags:

views:

answers:

.NET Framework weaknesses to be avoided

related questions