Do Language Specific Libraries Belong in .NET?

Posted by Jonathan Allen on Jun 03, 2008

Sections

Development,

Architecture & Design

Topics

.NET Framework ,

.NET ,

Language Design

Tags

IronPython ,

IronRuby ,

J# ,

Visual Basic.NET ,

C#

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.

1. Back to top

   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.

   Reply

2. Back to top

   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.

   Reply

3. Back to top

   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.

   Reply

4. Back to top

   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.

   Reply

• Older >