Using the VB TextFieldParser in C#

Sometimes you run across some hidden gems in the framework. One of these is the TextFieldParser class in the Microsoft.VisualBasic namespace. The TextFieldParser allows you to read and parse delimited files by specifying the positions as an array or by specifying the delimiters.    I know that a lot of C# developers would cringe at the thought of referencing a library from that other language, but given the functionality and the fact that this method requires no RegEx or xslt makes it a great solution.

Here's a quick sample that parses a position delimited file:

   1: public void ParsePositionalFile(string path)

   2:         {

   3:           

   4:             using (TextFieldParser parser = new TextFieldParser(path))

   5:             {

   6:                 parser.TextFieldType = FieldType.FixedWidth;

   7:                 int[] fields = { 9, 18, 36, 2, 25, 1, 1, 1, 8 };

   8:                 parser.SetFieldWidths(fields);

   9:                 string[] currentRow = new string[8];

  10:                 while (!parser.EndOfData)

  11:                 {

  12:                     currentRow = parser.ReadFields();

  13:                     foreach (string s in currentRow)

  14:                     {

  15:                         Console.WriteLine(s +'\t');

  16:                     }

  17:                 }

  18:  

  19:             }

.Net Languages are becoming more alike

I was looking at the new feature of VB10 and C#4.0 in the VS2010 CTP and it appears that they are becoming more alike than they are diverging. VB10 gets the explicit line continuation, no more "_", not universally , but in a fair number of places. I also gets auto implemented properties (C# 3.0 already has this) and collection initializers among other features. C# on the other hand is getting optional parameters, which have existed in VB for quite some time.

So it seems as time goes by there is really less of a difference between the two languages that in Version 1 of the .Net framework and VS7. So at what point will they become so similar that it will not be cost effective or desirable to maintain to distinct languages with exactly the same feature set? Granted there are still some differences between the two languages, but as time goes on, there is less and less that separate them other than pure developer preference.

I suppose that there will always be the "My language is better" kinds of religious arguments but it is becoming harder for each camp to point out the differences.

The VB10 futures doc can be found here.

The C#4.0 futures doc can be found here

God save us from the Architects

I'm constantly reminded that bigger is not always better, especially when it comes to architecture. Enterprise architecture  in particular seems to suffer from an extreme application of "Gold Platting", because "we may need it some day" and my favorite is because it's part of the "Vision".

It is time to for enterprise architects to get back to the basics, which I define as

• Do the simplest thing that will work
• Do it well (if it's not worth doing right, it's not worth doing)
• Keep the customer happy
• Don't add complexity for complexity's sake
• Keep it simple to deploy and configure

These simple tenets will take you a long way in development and make your life and the life of your customers better. Many markets move and evolve at a rapid pace, if you over engineer, you'll get passed by opportunities or worse by the time you finish the market will have moved on to the next big thing.

C# 3.0 Cookbook

  Every once in a while you run into a reference that should be on every C# developers desk. The C# 3.0 Cookbook is just such a reference. It covers a ton of everyday how do I's for every thing from Exception handling to LINQ queries. Each chapter is broken down into a series of Problem, solution, discussion so you get a clear understanding of not only what problem is solved and how, but more importantly, why it was solved the way it was.

Some of the solutions have been around since .Net 1.0 and others are new to 3.0. If you are looking for a great reference, this is the one.

Changing Source Control

Up to this week I've used Source Safe for my Source control at home. Since Installing Visual Studio 2008 SP1 though, source safe has become a problem. It locks up and is unable to complete file operations more often than not and even after running the db analyze utility, the problem still exists. So after a couple of weeks of this, I decided to switch Source control.

My requirements are pretty straight forward

• It needs to be easy to install and maintain
• It needs to have the ability to migrate from source safe
• It needs to be free for a single user
• It needs to be smart enough to exclude "noise" from the repository
• It cannot add extra "noise" to the project working directory
• It must plug into Visual Studio at no extra cost

To clarify the term "noise", is additional files and folders added by either the source control system, visual studio or third party addin's such as Code Rush, which creates a cache folder for intellisense.

  At the office we use subversion. Personally I find subversion annoying.  First it has no plugin without purchasing a license of Visual Svn or some other third party plugin. It adds a ton of "noise" to the project directory in the form of .svn folders and you have to define exclude lists for the bin and obj folders as well as any other "noise" folders. Additionally it's not smart, if you change a file, say for example add a space, then undo the change, subversion still insists it modified. So based on those issues, subversion was out.

I know there are a number of other free and open source source control alternatives, but in the end I ended up with Source Gear's Vault. Vault uses SQL server as it's repository, so maintenance and backups are greatly simplified. And it installed on SQL 2008 with no issues. Vault has met or exceeded the requirements I listed above and for a single user it's free if you use the provided admin login to access it. Optionally you can purchase a single user license for $249, which is very reasonable given the features and functionality of Vault.

Overall I'm pleased with the switch from Source Safe to Vault, the conversion process to a little less than an hour including installation of the client and server and migration of projects from Source Safe.

Catching up

It's been a busy couple of months for me. I was recently promoted to Development Lead and that's consumed a large chunk of time. I've been busy juggling sprint schedules and new developers, but fortunately, I've still found time to code a fair amount, although I suspect that will change in the near term unless I change organizations, which is always something that could happen in IT given the current economic environment.

  We did for good or bad drop the Entity  Framework for the application refresh I talked about a couple of months ago. LINQ to SQL was just a better all around fit. I suppose we'll change that layer again at some point since Microsoft seems to be determined to ditch LINQ to SQL in favor of the Entity framework.

We also switched the communication layer to WCF from remoting. The transition was far more than expected because we had to implement an uber security context, which is not as straight forward as it would appear given the constraints imposed by the architect.

All in all though it was a good opportunity to roll up my sleeves and get into some of the new technologies. The only piece we could have leveraged and didn't was the workflow foundation.

You'll notice that I said communications layer as opposed to service layer. There seems to be a great deal of confusion around these terms and specifically what they mean. I define a service layer as providing some piece of functionality that provides business value via a service interface. And communications as a layer that sits between the business and presentation layer in a distributed application and provides access to the business and data layer. Of course I talked to people and work with people who think that if it's WCF and provides an interface, it's a service. I suppose that is the result of the "loose coupling" of terms that is currently so prevalent in our industry.