That's why MS wrote .Net in the first place.
Microsoft used to have it's own JVM (Java Virtual Machine), which would take compiled Java code and run it with "very good support" on Microsoft machines. Then, Sun C&D'd the project and MS couldn't continue to release it's own "distribution" of Java... So they built .Net!
.Net is, at it's core, a reimplementation of code Sun already wrote once. And Sun did a good job, and Microsoft did a hackish job copying them. Most of JVM's package conventions and class structure are still in place in .Net, and I hate the layout of both. I think it's OO-overkill when you should have to instantiate ten different classes just to read from a file as a stream, or open a socket.
IMO, both JVM and .Net focus too heavily on implementing the same design patterns over and over, to cater to the lowest common denominator/developer.
When your code reads like "FileStream filestream= FileStreamOpen(filename).ReadFileStream();", it forces newer developers to rely on fat IDEs as a crutch (because Intellisense will suggest long function and class names for you), and creates tie-in to platforms like Visual Studio or Eclipse. On the flip side, it makes your code more readable, and readable code positively influences the adoption rate of a language. Overall, I believe that while these managed frameworks help newer programmers get into programming, faster, they attempt to be far too comprehensive and all-in-one to ever be the "best" solution for a problem. Programmers that have been working in one or the other for any extended period are almost always vigilant fanboys (in both MS and Java camps), and IMHO, if you're attached to any one solution strong enough to earn "vigilant fanboy" status, you're probably ignoring ten better solutions.