.Net does have two major downsides that kill it for me entirely (as someone who has used it for 15 years now): schizophrenic roadmap and deprecation, immature libraries. The deprecation means you can't rely on the longevity of the vendor's whims to build your product on. The library issue is a biggie - there are just so much more higher quality libraries in Java. The language matters considerably less than the libraries do when you want to get from A to B.
It also doesn't help that almost 100% of the time, when I'm Googling for docs, I get sent to a page for something deprecated that may or may not still exist in the version of .NET I'm using. It seems like more often than not, I have to really hunt for up-to-date information, and even then I'm never really sure. MS direly needs to do some SEO work on MSDN.
That and the alarming amount of mixed information you get on whether or not using X is a better idea than Y, for ill-defined (from all angles, including MS), deprecation-related reasons. At least that was my experience a couple weeks ago when I got placed on a one-off .NET project.
I'll admit that I'm not terribly experienced with .NET's standard library. But I am very familiar with C# as a language and I'm comfortable using it. It was rather frustrating for the stumbling block to be what it was.
On the library front we've used IKVM a few times where there was a java lib that did what we wanted with no equal in .NET land, e.g. Saxon XPath2 would be a primary example. However, with the developer of IKVM stepping down this has created a possible future risk.
