 03, 2008 06:32 AM
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.
NEW: ANTS Memory Profiler 5 now out!
Give-away eBook – Confessions of an IT Manager
Give-away eBook – Confessions of an IT Manager
Ensuring Code Quality in Multi-threaded Applications
NEW: ANTS Memory Profiler 5 just released!
This is a great question! I would argue that clearly these kinds of cross cutting concerns belong in the core. There is nothing language specific about any of these at all. Can we add the My library to this list? I've never been able to use it, since it's a VB.Net technology, and I am a C# guy. But it has always seemed really useful to me.
It would be better in the code but - Just reference the .dll from your C# project and then use as usual. For more info see my blog. 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.
It's simply silly that these aren't in the core runtime, especially the zip libraries. I personally see no real reason for ANY functionality that is not totally language specific to be found in a language dll.
Some are really language agnostic and should always be there: for example the zip libraries. I know that to some extent, the restriction on the zip stuff is -partly- because of super complex licensing agreements with patented stuff in the background, so it may not be that simple, but still, the default compression API should be much better than it is now (stream only? ugh!)
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,