Houston, we have a TechFest!

The Houston .NET Users Group (HDNUG) is organizing a day of technological banter at the University of Houston next month. The event has been coined the Houston TechFest and it is going to be held on August 25th (a Saturday).

This knowledge sharing experience is of particular interest to me because it will be my first true technology speaking experience. I’ll be presenting a session on Continuous Integration focusing on the open source tools that have been created to help .NET projects be more efficient. Here is the abstract of the presentation.

So if you are a seasoned technical speaker and have some pointers I am happy to mooch off of you if you want to leave a comment or email me.

Missing ConfigurationManager in WinForms

For anyone who switches back and forth between developing ASP.NET WebForms and WinForms, this tip may come in handy.

If you are developing in a C# WinForms project, you will find that attempting to use a ConfigurationManager to get at your app.config settings will result in the following error:

The name 'ConfigurationManager' does not exist in the current context

Since this is included by default in ASP.NET projects, this may come as a surprise. Just simply right-click on the References node in your project and look on the .NET tab. Scroll down and you should find System.Configuration. Add this to your project and you should be up and running.

Adding a Reference to System.Configuration

Provided you have already added System.Configuration to the using section at the top of your code, you should now be able to use config settings (such as connection strings) with code such as the following:

con.ConnectionString = ConfigurationManager.ConnectionStrings[sConnection].ConnectionString;

Do Not Use the StringBuilder

I know there are plenty of people out there that will disagree with me, but I urge you to not use the .NET StringBuilder class in 99% of the cases you would be tempted or recommended to do so.  Here is why:

 The StringBuilder class does perform better than basic string concatenation.  However, it is really only noticable with ridiculous string lengths.  For example, if you are concatenating a SQL statement together for a statement that has less than 100 columns, the difference will be negligible.  Slamming 10,000 strings puts StringBuilder as the clear winner in time as it will shave about 2 tenths of a second off of your processing time.

Testing In Progress

I ran some tests, and comparing a basic concatenation to using a string builder to slam together 100 “A” characters is a wash.  Sometimes the StringBuilder even took longer.  At 1000 characters, StringBuilder was a slight winner.  Of course this amounted to about 20 milliseconds on average.  Unless you are doing a lot of concatenation, this won’t really be a noticable difference… and we are already talking about 1000 operations!

Below are the results of my test (click on thumbnail) that were not posted on my original rant, but have since been added to this post.  You can see the strings of varying lengths I used as well as the number of concatenation operations that were performed on each.  The “Total String Length” column represents the overall lentgh of the resulting string after all operations are complete.

The Results of My Tests

As you can see, nothing short of  millions of resulting characters or tens of thousands of concatenation operations ends up in response time that is over 1 second.  Looking at a typical operation in my world such as concatenating a SQL statement together, we would be dealing with something like rows 9 and 10 of the above table.  These tests took the string “AND COLUMN1 = ‘VALUE’” and concatenated it together 1,000 times.  Although this would still be a ridiculously long SQL statement (and probably perform horribly :)), the difference between using a StringBuilder (193 ms) and simple concatenation (214 ms) is only 41 milliseconds difference.  Yes, I realize that is about 20%, but again, if you are doing this concatenation many times, you may need to write your own custom object to meet your true needs.  Another interesting find is that the # of operations seems to have a much bigger impact than the overall length of the string itself.

Yes, it is terrific that somebody at Microsoft realized working with a collection (string) of hundreds of thousands of members (characters) will not perform will if it is not indexed.  No kidding!  But who in their right mind will be dealing with strings of 500,000+ characters?  If you are doing that, then you probably need to rethink your approach to solving the problem at hand.

 Because of the added complexity, additional lines of code, developer ramp-up possibility (for those not exposed to the class or .NET) and risk of change in future versions of .NET, I say you should not use the StringBuilder class… unless, of course, you find yourself needing to deal with that all to common million character string 🙂