Do Language Specific Libraries Belong in .NET?
Though people have been asking for it for years, developers still need write recursive directory copying routines themselves, and every one is nearly identical. So why doesn't this simple and useful function exist in the .NET framework? Actually it does, if you reference the Microsoft.VisualBasic assembly.
Reading and writing to ZIP files is another common task for programmers. A bit more complex than copying directories, developers often turn to third-party libraries or command line tools. Needlessly in fact because ZIP libraries have been in the .NET Framework since the beginning. You just have to dig them out of the J# runtime (and hope the libraries are not decommissioned).
Moving on to our third example, developers often have to read flat files in comma-separated (CSV) and fixed-width formats. While seemingly straightforward, minor points like escaping quoted strings are easily overlooked. Slipped into .NET 2.0 is VB's TextFieldParser, a general-purpose flat file parser suitable these and other similar file types.
So should these little gems remain "language specific", or should they be migrated to the core namespaces of the .NET Framework? A minor question now, but one that is sure to become more pressing as the new languages F#, IronRuby, and IronPython come online.
Add Them To The Core!
Re: Add Them To The Core!
Reflect on the Me library and most of it is found elsewhere in the framework but is brought together for convenience. For those bits that aren't the code is pretty simple recreate using Reflector.
For other stuff, its a matter of best practice and backward compatibility. Certain features, especially in VB.NET and J#, are only there for backward compatibility, and do not represent the official best practice for certain tasks in other languages, or have a philosophy that is language specific in design (The My deal and half of what is in the VisualBasic assembly, Eval in JScript.Net, etc). Those shouldn't be there.
If the functionality is that useful however, it should be part of the core, in a flexible enough way that follows the .NET framework guideline and best practices, while being careful not to bloat the framework more than it already is, and the language specific stuff can simply be wrappers around it to give each language their distinctive feel (again: the My stuff in VB.NET does exactly that).
Otherwise, languages that are supported, but have to be compatible with something else through their API, not just the language semantics (IronRuby, F#, etc) would bloat the framework with every new one, features would start getting duplicated, etc.