(Re-written question, please see history for original).
The question is right there in the title.
Why is there no managed MD5 implementation in the .NET framework?
I'm specifically talking about a purely managed code implementation of the MD5 algorithm, which does not exist within the .NET framework.
Within the System.Security.Cryptography namespace, I am aware of the MD5 abstract base class (which has to be inherited and can't be used as is), and I'm also aware of MD5CryptoServiceProvider and MD5CNG which both provide implementations from the OS's underlying CSP (Crypto Service Provider) and CNG (Cryptography Next Generation) providers respectively, however, both of these implementations are unmanaged code.
UPDATE ON ANSWERS:
I appreciate that, whilst there should be "one true answer" to this question, we (the SO community) may not know it unless a Microsoft framework designer (or someone who knows one directly) is part of this community, however, many people have offered very reasonable "educated guesses" as to the thinking that went into omitting a managed MD5 implementation from the framework, however, I'm still curious to know if anyone does know the "real" answer to this question.
Since I didn't design the framework, I can't say for sure, but I believe they probably didn't bother in order to discourage its use for security reasons.
I had originally believed that the unmanaged implementation would be faster, but we now know that is not the case, see: https://stackoverflow.com/a/14850676/58391
My next best guess aligns with what Pavel says in the comments above. As with most features in .NET and C#, there probably just wasn't enough benefit over cost to implement, test, and ship the feature when the underlying unmanaged one was already good enough.
It would be interesting to see a real answer though from someone who designed the language.
MD5CryptoServiceProvider has been in the .NET Framework from day one, actually:
Note that all .NET BCL classes which encapsulate hashing algorithms inherit from HashAlgorithm class, so these can be used polymorphically ...
...and different implementations can be Dependency-Injected into your code:
EDIT
Aha, I see. The thing with MD5 (this is pure speculation) is that it's one of the most widely used hashing algorithms, and being such, its implementation is required to conform to certain standards -- more specifically, FIPS 140-1. See this for more info.
What are you talking about?
System.Security.Cryptography.MD5
System.Security.Cryptography.MD5CryptoServiceProvider
MD5 is not suitable for any cryptographic or file verifying purpose except for possibly error detecting transmission errors. This is probably an effort to get people to move to better hashes like SHA-1 or preferable SHA-256.
http://www.mscs.dal.ca/~selinger/md5collision/
It's been there since the begining
In .NET anything that ends in CryptoServiceProvider wraps the unmanaged Windows Crypto API. Anything that ends in Managed is written entirely in a managed language. link text
As other people stated you shouldn't use MD5 anymore. You should use SHA-256 which in .NET has a Managed implementation. You're good to go and trading up to a better algorithm. (EDIT) As MD5 is no longer kosher, there's little chance of this being updated in a later version of .NET to be entirely managed as you shouldn't be using it anymore anyways.