Do Language Specific Libraries Belong in .NET?

by Jonathan Allen on Jun 03, 2008 |

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.

Related Editorial

Speed Matters: See why Nike, Groupon, and Comcast are using New Relic

APM Survival Guide from a Veteran Performance Geek

Application Performance Management Buyer's Guide

A Unified Mobile Architecture for the Modern Data Center

Infographic: Just How Big is the Nerd Economy

Related Sponsor

Get code level visibility into your web apps. All for free.

Try New Relic Today.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Community comments

Add Them To The Core! by John DeHope Posted

Re: Add Them To The Core! by Neil Robbins Posted

YES by Jim Leonardo Posted

Re: YES by Francois Ward Posted

Add Them To The Core! by John DeHope

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.

Re: Add Them To The Core! by Neil Robbins

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 neildoesdotnet.blogspot.com.

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.

YES by Jim Leonardo

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.

Re: YES by Francois Ward

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, etc.