The .NET framework is massive. I've used it for years and I've still not used most of it.
I'd like to expand my knowledge of the Framework's backwaters but just reading thought it seems daunting. So I thought I'd tap up the Stack Overflow community first.
What part have you found to be the most surprisingly useful? What's your favourite obscure namespace? And conversely are there any shiny bits that are best avoided?
The degree of consistency across this huge framework.
Whenever I need to use a new part of the Framework, I'm able to pick it up quickly, because of the fact that it mostly all follows the same rules.
With .NET, it's not that the whole huge thing is right in your face, but rather that, when you need something, it's within reach.
Linq is truly amazing.
In general, I think Reflection is glazed over by a LOT of .NET developers. True, it is not usually the best tool for the job, but there are plenty of times it can help solve a really tricky issue.
The regular expression engine in .NET is far more powerful than most people think. It's one of the best and most robust regex implementations around.
Although some people misuse it, in specific situations it can save you lots of time and effort.
All of the encoding related stuff in
System.Text. I won't get into a rant about how most developers don't understand anything about encodings even though they really, really should, and just express my gratitude that so many encodings are implemented in .NET, along with quite obscure and specialist things like different Unicode normalization forms etc.
(And if you want an example of why you should know this stuff, have a think about how you'd strip non spacing marks (e.g.
ñ -> n,
é -> e) to make SEO and browser-friendly URLs. A huge lookup table? Nah.
Try 5 lines of code
For me, the first thing that comes to mind is Generics. Easy to understand, use, makes sense and most of all, improves performance.
One man's backwater is often another man's metropolis, but still --
System.Globalization gets my vote. The amount of work it saves me (especially with different calendar systems) makes it my favorite underrated namespace.
Mono  on Mac OS X, Linux, ... http://en.wikipedia.org/wiki/Mono%5F%28software%29
I'll add a second choice: the entire XML API in System.Xml.*
It took me a long time to get comfortable with it. XmlReader scared me away completely! I had to get my feet wet with XmlDocument, then slowly added a little XPath for selection (I needed to stop and learn about XML namespaces at that point). I learned a bit of XPathNavigator (which has some really underutilized features, like AppendChild()), XslCompiledTransform, all the XML Schema stuff, and then, finally, XmlReader and XmlWriter.
XmlReader and XmlWriter aren't that bad if you take your time, understand what the different kinds of node are, and allow four times as much time as you thought it would take you to debug!
But I've been able to do some fairly neat things with this stuff:
Process a 10GB XML document by
This was very helpful with SSIS, wihch otherwise wanted to read the entire 10GB into memory.
Create sample data based on a set of XML Schemas, using the System.Xml.Schema.XmlSchemaValidator class 
This class is a hidden gem. It really needs to be in a different namespace. Almost everything else in the System.Xml.Schema namespace  is named "XmlSchema*something* and represents part of the object model of an XML Schema. The one class that fits that naming pattern but is not part of the SOM is xmlschemavalidator:
The XmlSchemaValidator class provides an efficient, high-performance mechanism to validate XML data against XML schemas in a push-based manner.
Long story short, this thing will tell you, at any point in the logical processing of an XML document, what is valid at the current point. You then tell it which of the valid choices you made, and it will tell you what's valid at that point, etc. So, if you write one of the valid choices when it says they've valid, you'll wind up producing a valid output document.
Enough's been said about LINQ to XML, so I won't say more. I will finally just mention the System.Runtime.Serialization.XmlDictionaryReader and XmlDictionaryWriter classes, just so I can say "binary XML" in a sentence. http://msdn.microsoft.com/en-us/library/system.xml.schema.xmlschemavalidator.aspx
The Delegate. Hard to really call it under-appreciated since it is the underpinnings for LINQ, Lambda, Anonymous Delegates, and Events. But the code is often written in such a way that you don't even know you are using a Delegate. Many developers use them every day without even knowing what they are.
Memory management and underlying CLI design
The bump pointer memory allocator combined with user-defined value types and a fallback ability to use unsafe code. A great step forward where the JIT is the only thing keeping us from passing C++ performance nearly across the board. That and the fact that it's already improved to the point that it's not far off. This is undervalued because there remain a large group of people who do not see the current state of things or the potential that lies before us in this respect.
Phenomenal inter-language coding support. Every system should be designed for such - allows comfort now and flexibility in the future.
General thought on the framework
There are "tricks" everywhere. Since I've been working on implementing a test CLI VM, I've picked up a great number of them and I try to answer them wherever I see them asked in specific questions. In general, if something seems awkwardly verbose, there's an easier way that you just haven't identified yet. And when you do, you'll think "yeah, that does make sense. :)"
Ever since the introduction of System.Web.Mvc namespace I am a happier man.
The System.Linq.Expressions namespace. The ability to treat code as data so that you can manipulate it is a very powerful thing. You can also use it to dynamically build up simple methods.
I really like the System.Diagnostics namespace. There is a lot of cool stuff in there. Have you ever used the Stopwatch, PerformanceCounter or StackTrace classes?
The all powerful Windows WorkFlow Foundation.
The fact that it follows a public spec and is JITTED so that:
With any luck you'll have one program that will be able to run in any machine, programmed in any language you like, running on any operating system there is.
My favorite underutilized features are probably Attributes and Reflection. Of course, those two go together a lot of the time.
I must say the same code running on 32 and 64 bit platforms is very nice.
All kinds of gotchas with unmanaged code.
I found reading about the Common Intermediate Language  to be very interesting, if you want to see how things work under the hood in .Net. Here is a useful tutorial  if you want to learn how to write it. http://en.wikipedia.org/wiki/Common%5FIntermediate%5FLanguage
The .NET Framework... I have seen many people not take the time to see if the framework has built-in support for something they want to do and they just go ahead and and roll their own. There is also a large group of people that think their custom code is faster than the classes that Microsoft (or Mono) has in the framework only to complain and having problems with performance and maintenance later. (And of course this is Microsoft’s fault because the bug would never be in custom code.)
.NET 2.0+ XSLT implementation (
XslCompiledTransform). Not many people realize this, but it's a full-featured solution with complete VS integration - you also get debugging with step-through and breakpoints, the complete functionality of Watch window with XPath expressions, and so on. Combined with the ability to create custom functions in C#/VB with
<msxsl:script> blocks (not many people know that when you precompile your XSLT, this does not require FullTrust - MSDN omits this important piece of information), it is a very powerful tool for many XML processing tasks, and overall one of the fastest and most convenient XSLT 1.0 implementations out there.
Oh, and don't forget to turn on the hidden XSLT IntelliSense feature ! http://www.tkachenko.com/blog/archives/000740.html
Attributes, along with the ability to define your own (there are a couple of oddities in the BCL for things that should be interfaces though). When I've used them, they've been invaluable, and solve problems that would be very difficult or hacky to solve any other way.
I have to give my highest props to the CLR (Common Language Runtime). .NET simply couldn't be .NET without it.
It single-handedly allowed resurrection of the very broken, prior implementations of Visual Basic, continuously showers new life into custom SQL library development, and continually / automatically enhances cross-language execution-time efficiency.
An enterprising, dual-platform developeer buddy of mine is already researching how to get appropriate dev-tooling into VS2k8 so he can code iPhone apps using the Studio tool-set.
Closures with LAMBDA expressions, saves a lot of headache...but can be just as evil if used in the wrong hands.
I guess the whole component model is heavily under utilized. This provides a great tool to write plugins into the OS and other huge products. Yet I find it little understood (at least by me) and little documented...
I can't believe nobody commented on GDI+! Talk about doing anything you ever wanted with graphics. Before .NET I just avoided graphics unless I needd to because it was such a pain. I knew what I treasure it was when I noticed on the computer I bought 2 years ago, I have not had to install ImageMajick.
If you want to use spot-generated graphics in a website, put cool animation in your thickclient splashscreen, or print just about anything, any way, do yourself a favor. Visit Bob Powell's GDI Plus FAQ and learn GDI+ today!!!
If you don't think you'll ever use it... you're probably wrong >:-}
The element of least surprise.
Pretty much inline with what John Saunders said.
The CLR Hosting model and strong assembly naming. A couple of those important things that you generally don't think about but when you need them you thank god for their existence.
Delegates. By far the coolest thing i've encountered in any programming language. The ability to throw around methods like variables without pointer issues or massive anonymous classes (sorry Java) always makes me feel warm inside. And yet I never see anyone talking about how awesome they are... they just use em and forget about em.
I don't think I could manage without .NET, my best dream is that .NET's main language would become python; or it should at least be fully supported out-the-box. http://blogs.msdn.com/jimoneil/archive/2009/06/15/x-is-for-xml-literal.aspx