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.

LINQ to SQL Expressions and WCF

I'm currently involved in an extensive migration of an existing .Net remoting architecture to WCF. The original architecture used Net Tiers in the data layer, which has been replaced by LINQ to SQL. We opted for LINQ to SQL over the Entity Framework, because EDM frankly offers little for a great deal of overhead additionally it just doesn't support functionality that it should.

One of the issues that we ran into during the migration was the migration of services methods that relied on client side criteria to filter the data, the original implementation used code that was heavily dependant on the Net Tiers metadata to write the queries on the client and pass them to the proxy. Initially  it looked as if Expression<Func<T,TResult>> would provide a perfect solution, it allowed us to create the expression and replace the current implementation with little impact. Unfortunately, it turns out that this solution won't work since Expressions can't be serialized. So we were left with the option of rolling a new dynamic query engine that could build the expression trees on the server, based on a string passed from the client. Initial discoveries lead us to believe it was feasible to create the expression in this way, but it would cost hours that we really didn't have.

  Then I ran across this article on ScottGu's blog regarding LINQ dynamic queries. After downloading the C# samples and looking at what it contained, it turned out that for the most part it contained most of the functionality we would need to create. So if you find yourself in need of the ability to pass queries across the wire to LINQ this is a great place to start.

Working around DataContract serialization with existing .Net classes

I'm working on moving some existing code to WCF. The code was originally passed via remoting so I thought it would be a pretty straight forward move. Turns out that's not the case. I ran into an issue with properties defined as System.Object and WCF. The error message that was returned was telling me that the connection was forcibly closed by the host, which I'm finding out can really be interpreted as "There was a problem with the object you want". After tracking the problem for the better part of the day it came down to an issue with the properties which looked like this:

[DataContract]
  public class ContractTest
  {
      [DataMember]
      public int PropOne { get; set; }

      [DataMember]
      public object PropTwo { get; set; }

      [DataMember]
      public string PropThree { get; set; }

      [DataMember]
      public object PropFour { get; set; }
  }

It turns out that the serialization of the data contract can be altered by using the XmlSerializer. This is really helpful when moving older code. So to fix the issue, I modified the class like this:

using System.ServiceModel;

   [DataContract]
   [XmlSerializerFormat]
   public class ContractTest
   {
       [DataMember]
       public int PropOne { get; set; }

      
       public object PropTwo { get; set; }

       [DataMember]
       public string PropThree { get; set; }

      
       public object PropFour { get; set; }
   }

The XmlSerializer will serialize the public properties and the end result is that you can now pass the class through the service noramlly.

ADO.Net Entity Data Framework

I've spent a great deal of time with the Entity framework over the past month trying to incorporate into an application solution. I had high hopes that the framework, but after a month it's left me with a bad taste. No matter how you slice it, this framework is not ready for prime time. Here are a few issues that I have with it so far.

1. The Conceptual Data model does not allow me to abstract from the data store, I thought this was the great promise of this model but it turns out to be the great impendence mismatch magnifier. The mappings are absolutely unforgiving in complex situations. Mapping is really an all or nothing scenario, if every key isn't matched you'll never be able to map the entities.

2. The EDM modeler has a real difficult time with poorly normalized data stores. Arguably this could be addressed by cleaning and normalizing the database, however, it's currently not an option in this project and I'm sure that this is not an uncommon enterprise scenario.   As a result it is nearly impossible to map the entities in the store, even though it can be accomplished with LINQ2SQL.

3. I've run into issues where the model generator will, for whatever reason, just arbitrarily change the namespaces. and the fact that you can view the conceptual model at all is just unbelievable given that the conceptual model is such a central part in the framework.

4. Now I have to learn a number of new query technologies in order to use the model effectively. And coincidentally none of these models provides any real benefit when you need strong typing and generic runtime support.  

So if I had a chance to start over, LIN2SQL would be my first choice, especially given the the DB lives on SQL Server. The LINQ2SQL programming and mapping models are more forgiving and easier to work with as well as being functional.  If these issues and the multitude of other issues addressed in other blogs and numerous forums aren't addressed, the Entity framework will be stillborn. My advise to anyone who is considering LINQ2SQL and EDM for a SQL server based project would be this, save yourself pain, time and productivity and go with LINQ2SQL.

In case you've been in a cellar (VS2008 SP1)

 

  Visual Studio 2008 SP1 and .Net 3.5 SP1 have been released, you can download them from the links below as well as a the service pack prep utility.

Visual Studio 2008 SP1 and .Net 3.5 SP1 download

Service Pack Preparation Utility

My installation on two machines went without a hitch. I completely uninstalled SQL server and Visual Studio , deleted the remaining directories and defragged before reinstalling. I installed in the following order on both machines.

1. SQL Server 2008 Developer
2. Visual Studio 2008
3. Visual Studio 2008 SP1

SQL server will install the .Net 3.5 service pack. 

So far everything runs fine, one disappointment thought was the missing WPF controls promised during the beta. The Office ribbon bar is nowhere to be found but the new grid control is available separately on Codeplex  as part of the WPF Toolkit.

Vs 2008 SP1

I posted earlier that SQL 2008 RTM is available to MSDN and Tech Net subscribers which is great, but it appears the Visual Studio 2008 SP 1 will not be available for download until the 11th of August.  These timing issues are annoying to say the least. Both of these pieces are needed in a development environment, in fact without SP1, you can't program against SQL 2008. Let's hope that they release prior to the 11th, but if not at least we have a known date.

SQL 2008 has been released to manufacturing

SQL Server 2008 has been released to manufacturing (RTM). I posted earlier that I thought it would happen by the end of this month, so I was pretty close. It's already available for MSDN and Tech Net subscribers.  Now how about the VS 2008 SP1 RTM?

Visual Studio 2008 SP1 and SQL 2008 close to release?

Just ran across a set of slides for the Visual Studio 2008 SP1 launch here. So is it possible that we may finally see RTM of the Service Pack and SQL 2008 in the next couple of weeks? I suspect that it may be pretty close, maybe by the end of August. This would be great because we've been using the beta and SQL 2008 RC internally to ramp up vNext of our application.

New look for MSDN subscriber downloads

Microsoft has changed the MSDN subscribers download layout again. This time around it is actually useable. The last version used a SilverLight application to browse and download products and keys. There were big problems with mouse interaction in the menus in that you would have to select and hold an item for several seconds or else the selection wouldn't work. This was especially annoying when you were several levels deep in the menu, since when it lost focus the whole menu would collapse and you'd have to start at the root again.

The new layout is web based and ajax enabled, no more SilverLight!, the menu hierarchy layout is very similar to the pre SilverLight site, which makes navigation easy and familiar.   Overall as an MSDN subscriber I like the new layout and I think it was the right move, kudos to the MSDN team.

Foundation of Programming eBook

  I saw this free eBook title on Channel 9 while browsing the Webcasts. It certainly isn't anything ground breaking or  revolutionary, but it is well put together and provides a refresher in a down to earth manner.

Sometimes in this field it's good to step back and look at what's going on from a different perspective. This eBook does exactly that by discussing Domain Driven Development in comparison with the Data Driven Development we've become accustomed to with .Net. The author doesn't dismiss the data driven approach, but in fact shows that in some cases it may be the right choice. At the same time he does a great job introducing Domain Driven Development in  practical way by example. 

Sometimes it doesn't pay to help

  I recently found out that a former employer is shutting down development operations locally. The developers that worked there are hard working talented and I'd work with any of them or so I though.

My currently employer is looking to fill a couple of positions  so I passed the information on to my former co-workers since I knew they'd be looking for jobs soon. One individual, a younger mid-level programmer requested a job description and salary range which I sent along.

Now to be honest the position requires some legacy application maintenance, to be specific, some classic ASP maintenance as well as .Net development. We are in the process of moving the systems to a new architecture, but reality is we just can't "turn off" the old systems. At any rate I received a very pompous response from this developer as to how it would never work on "legacy" applications and if he didn't get to work on only new stuff we could take a hike, he wasn't interested. Ok fair enough, but for the record almost any position will require some legacy maintenance, that's just the way it is.

The response was something I'd expect from a junior developer, no actually it's a response I wouldn't tolerate from any candidate. So I'm making sure he's removed from the candidate list. It's important, especially when you are building a team, to find team players who are willing to participate in the good and the bad.  This developer is good as young developers go, but no one is worth that.

Next time this situation arises, I'll  spend more time evaluating my choices before making a recommendation.

Follow up to Web 2.0 Portal book

Admittedly I haven't gotten very far with this title this weekend, but I've made a few observations to share. The book has a corresponding web site, Dropthings.com that you can browse to and check out. One of the key areas so far is the "widget" framework. This framework provides the ability to add custom widgets (user controls) to the portal. After perusing the site and checking I see the follow issues.

• All widgets use the same  header template which includes an edit link. When there is nothing to edit and the link is clicked, in some cases the widget says there's nothing to edit, in others nothing happens. This leads to a very inconsistent user experience.
• You can drag widgets to different columns. The main area is laid out into three columns for widget display and while you can move them up and down within a container, it doesn't seem you can move them to other columns. The UI cues indicate that you can but nothing seems to happen.

Arguably these are small issues but if you're selling a book and the site is a reference, that site better be correct and provide a good user experience.

As for the book, I've noted a few typo's and some discrepancies between the text and images. This is the first O'Rielly book I've purchased and so far it appears to be the last. When I purchase a professional development book, I expect the quality to be good.

Building a Web 2.0 Portal with ASP.Net 3.5

I've never been a big fan of the O'Reilly series, but I thought this title might be an interesting read. The book takes a look at building portals with a mix of the latest .Net 3.5 offerings including AJAX, Workflow Foundation and LINQ. One thing that seems to missing from the list though is Windows Communication Foundation. The book is fairly light weighing in at around 290 pages including index. By the standards of the other books I've read lately that's pretty light, maybe I can finish it in a couple of days. I'll post additional thoughts once I complete it.

SQL 2008 in August

Just saw that SQL 2008 will ship in August at the ISV Developer Evangelism Team Blog. That is really good news given the new geo spatial features, no ISS reporting services and all the other new and enhanced features in this release. I would expect then that we may see the final release of  VS2008 SP1 around the same time. I hope that they can iron out the installations issues that have been experienced by many, including myself.

I'm also looking forward to the new WPF controls, specifically the ribbon toolbar and data grid that where supposed to be available shortly after the release of SP1 beta 1, but have yet to materialize.

Read RSS with LINQ to XML

 

I'm sure this has been posted somewhere before, but all a quick google turned up was how to read RSS into a data set. So here is a simple way to read RSS using LINQ

 

First an object to hold the results:

 

using System;
   
    [Serializable()]
    public class RssItem
    {
        public string Title { get; set; }

        public string Link { get; set; }

        public string Description { get; set; }

    }

This is really just a simple object no smoke and mirrors, probably could be a simple struct as well.

And the code to read the RSS and populate or object

public static List<RssItem> ImportRSS(string source)
{
    XDocument doc = XDocument.Load(source,LoadOptions.None);

    return (from i in doc.Descendants("channel").Elements("item")
            select new RssItem()
            {
               Title = i.Element("title").Value,
               Link = i.Element("link").Value,
               Description = i.Element("description").Value
             }).ToList();
  }

This just loads the RSS into an XDocument object and then we query the descendants to find the items. We place those into the RssItem and return them as a list by using the ToList extension.

And there you have it no more data set.

The eternal debate continues

If you program on the Microsoft stack and unless you live in a cave or just woke from a coma you've surely heard of or even been part of the VB vs C# debate. Visual Studio Magazine has recently rekindled the arguments again. So I thought I'd take a few lines to reiterate my comments to the editor.

I started in development with C++ and MFC which I worked with for a bit over two years, I changed jobs and found myself doing classic asp and VB6. At the time this was pretty much the norm. When .Net was announced I was eager to learn and get onboard with all this new framework had to offer. It looked like things were going to get a lot better for VB in the .Net world and the language would evolve into a first class object oriented language. But even from the earliest days of .Net there was the rumbling of those who didn't want change or evolution. Their mantra was "the same but different". As these things go the squeaky wheel got the grease and VB retained a lot of the baggage it had been carrying around since version 1.

This to me was a sign to look elsewhere in the stack to find the evolution that would make me more productive. The search was to lead me to C#, coming from a, by this time distant C++ background, it was a fairly easy choice. It has been a choice that I have not regretted once. I will no debate the choice of language, because whether it's Java, C++, C# or VB, for many developers it's a near religious choice.

I believe the choice is black and white, evolve or wither, but as long as the "back in version 1" crowd is still making noise, VB will always remain a "could have been" contender.

TSQL Debugging in SQL 2008

TSQL Debugging is back in SQL Server 2008, along with intellisense  and code outlining, it's a great productivity enhancement. There at least one major difference between the debugging support in SQL 2000 and SQL 2008 that you should probably be aware of, stored procedure debugging. There is no direct way to step into a stored procedure either from the toolbar or the context menu. Debugging then becomes a two step process for stored procedures

1. Select the procedure and script as execute
2. Set a breakpoint on the EXEC statement
3. Select debug from the menu
4. When the breakpoint is hit, F11 to step into the stored procedure
5. You can now step through the TSQL in the stored procedure

This is different then the VS 2008 stored procedure debugging support where you can select step into from the context menu. I would have though they would be pretty close in functionality since it appears that they are using much of the VS debugging functionality in SSIS.

SQL 2008 RC0 BIDS fails to install

 

I ran smack into this when installing RC0 with VS 2008 SP1 (beta). It appears that the SQL installer is looking for a product ID that is changed in SP1. There is a work around on the connect web site  in a nut shell though the solution is

1. Go to Add/Remove Programs
2. Select Show updates
3. Remove VS Shell update KB945140
4. Install SQL BIDS

The only problem I had with this approach is that the uninstall wants a path to the vs_shell.msi from the service pack install. This is typically under Local Settings\Temp\Microsoft Visual Studio 2008 SP1 (Beta) if you're asked during the uninstall.

The other way around this issue is

1. Install VS 2008
2. Install .Net 3.5 SP1 (beta)
3. Install SQL 2008 RC0
4. Install VS 2008 SP1 (beta)

This works a lot better than uninstalling the KB after the fact, given how well the uninstall's clean up after themselves. Hopefully this issue appears to be marked as fixed on the connect site and RTM should be soon since Q3 is upon us.