Today I learned how to retrieve the default value of a parameterized type T in a generic type definition in C#. The issue is that one does not know in advanced if T is a reference type or value type. And if it is a value type if it is a struct or not. So when you need to get the default value of T use the following construct:

T someVar = default(T);

You can find more detailed info about the default keyword here.

Today I want to talk to you about the boolean conversions to different types. Why do I want to do this? Because I heard a discussion about the BooleanConverter on DotNetRocks. In the Better-Know-A-Framework section of show #254 Carl Franklin talked about it. He could get it to work as he expected it to work. I think this is because the BooleanConverter, like all converters like it, is not meant to work with in the way he proposed: converting types to and from booleans. But the BooleanConverter only converts booleans to strings and strings to booleans. The BooleanConverter is meant to be used by the designer property window.

The Convert class, in the System namespace, can be used to convert a value to a boolean and a boolean to a value of another type. For the purpose of converting values to booleans the Convert class exposes the ‘ToBoolean’ method. This method has an overload for the every type that implements the IConvertable interface and Object type. If a value is put into the Object overload that instance must implement the IConvertible interface. To convert a boolean to another type the Convert class has type specific methods like ToByte, ToString, ToInt32, etc..

Can it be done? Yes, it can. At first it seems that you cannot. There is no Clone method on SqlParameter. Or is there? Yes, there is. SqlParameter implements IClonable explicitly (look at this blog for more information on explicit and implicit interface implementation) and that is why you cannot see or use it directly. But casting the SqlParameter object to IClonable let’s you use the clone method.

Not only SqlParameter implements IClonable. All parameter classes implement it.

I want to talk with you about the performance difference between string concatenation and doing the same with a stringbuilder. I can tell you already that the bottomline is that using a stringbuilder to concatenate string is much faster.

Why? That is because strings are immutable which means that once strings are created they cannot be changed. But I can change a string you say. Oh right, that is right. What I mean is that a string buffer is not reused when a new value is assigned to a string variable. A new buffer is created to hold the new value. The old one is left behind to be recycled by the garbage collector. Not so very efficient memory use or is it? The creation of new buffers for new values for strings impacts the performance of an application if alot of strings are changed because the garbage collector has to free memory many more times than normal.

A stringbuilder does not have this problem because it works internally with flexible memory buffer that is extended dynamically. This is a fast and memory efficient model.

Look at this picture. It tells more than a 1.000 words.

String Test Result

So it is clear that when you want to concatenate alot of strings it is better to use a stringbuilder.

The test code I used is this:

   10         static void Main(string[] args)
   11         {
   12             Console.WriteLine("Start String vs. StringBuilder performance test.");
   13             Console.WriteLine();
   14             Console.WriteLine("Started string performance test.");
   15             Console.WriteLine();
   16 
   17             // Create a stopwatch to time the tests
   18             Stopwatch stopwatch = new Stopwatch();
   19 
   20             // Test the performance of strings allocation
   21             stopwatch.Start();
   22             string testString = string.Empty;
   23             for (int i = 0; i < 100000; i++)
   24             {
   25                 testString += i.ToString();
   26             }
   27             stopwatch.Stop();
   28 
   29             Console.WriteLine("Ended string performance test.");
   30             Console.WriteLine();
   31 
   32             // Write the elapsed time
   33             Console.WriteLine("100,000 string allocations time elapsed : {0} ms", 
				    stopwatch.ElapsedMilliseconds);
   34 
   35             stopwatch.Reset();
   36 
   37             Console.WriteLine("Started StringBuilder performance test.");
   38             Console.WriteLine();
   39 
   40             // Test the performance of stringbuilder allocation
   41             stopwatch.Start();
   42             StringBuilder sb = new StringBuilder();
   43             for (int i = 0; i < 100000; i++)
   44             {
   45                 sb.Append(i);
   46             }
   47             stopwatch.Stop();
   48 
   49             Console.WriteLine("Ended StringBuilder performance test.");
   50             Console.WriteLine();
   51 
   52             // Write the elapsed time
   53             Console.WriteLine("100,000 stringbuilder allocations time elapsed : {0} ms", 
                                    stopwatch.ElapsedMilliseconds);
   54 
   55             stopwatch.Reset();
   56 
   57             // Keep window open 
   58             Console.ReadKey();
   59         }

I have installed VS.Net 2005 Pro on a very slow laptop. Why? I need to. Anyway I tried to install sp1 on it recently. My laptop worked for one and a half day and got a heart attack. So I searched for an alternative to install sp1. And I have found it at Heath Stewart’s blog in this article on Slipstreaming Visual Studio 2005 Service Pack 1.

So I slipstreamed VS.Net 2005 and started to reinstall it on my laptop. Everything went well. The .Net 2.0 Framework and the document explorer installed fine but VS.Net 2005 would not reinstall. It complainted about an invalid install package. It turned out that it had to do with the installer cache. You can get more information at Heath Stewart’s blog in this article on Resolving prompts for Source and at Alex Thissen’s blog in his article about Fixing problems with VS.NET 2003, VS2005 and building MSI files. What I had to do was clear the cache. You can do that this way:

For VS.Net 2005 Pro: msiexec /fvomus {437AB8E0-FB69-4222-B280-A64F3DE22591} /l*v vs8_repair.log

For VS.Net 2005 Team System: msiexec /fvomus {1862162E-3BBC-448F-AA63-49F33152D54A} /l*v vs8_repair.log

I hope this will help you solve your problems reinstalling VS.Net 2005