.NET (C#)

Sams Teach Yourself Visual C# 2010 in 24 Hours

Scott Dorman — Fri, 06 Nov 2009 04:01:43 GMT

I have previously mentioned that I’m working on the upcoming Sams Teach Yourself Visual C# 2010 in 24 Hours book.

Things are progressing nicely, if a bit slower than I’d prefer. I have the draft for the cover art, which looks really good.

I’m also very pleased to announce my technical editors – Claudio Lasaala and Eric Lippert.

Claudio is a Senior Developer at EPS Software Corp. He has presented several lectures at Microsoft events such as PDC and various other Microsoft seminars, as well as several conferences and user groups across North America and Brazil. He is a multiple winner of the Microsoft MVP Award and also holds the MCSD for .NET certification. He has articles published on several magazines, such as MSDN Brazil Magazine, CoDe Magazine, UTMag, Developers Magazine, and FoxPro Advisor.

Eric is a senior software design engineer at Microsoft has been working full time in the developer division since 1996, where he assisted with the design and implementation of VBScript, JScript, JScript.NET, Windows Script Host, Visual Studio Tools for Office and C#.

I am looking forward to working with both Claudio and Eric through the technical editing process and getting this book completed and available, which should happen sometime early in 2010.

Technorati Tags: Books,Sams Teach Yourself C# 2010

Visual Studio 2010 Beta 2

Scott Dorman — Mon, 19 Oct 2009 18:09:29 GMT

Visual Studio 2010 Beta 2 is now available for MSDN subscribers, and generally available on October 21. I haven’t had a chance yet to play around with it, but some of the CLR changes that are very exciting to hear about are:

The new String.IsNullOrWhiteSpace method indicates whether a string is null, empty, or consists only of white-space characters.
New overloads have been added to the String.Concat and String.Join methods that concatenate members of an IEnumerable<T> collections.
The String.Concat<T> method lets you concatenate each element in an enumerable collection without first converting the elements to strings.
The new Enum.HasFlag method determines whether one or more bit fields or flags are set in an enumeration value.
The Enum.TryParse<TEnum> method returns a Boolean value that indicates whether a string or integer value could be successfully parsed.
You can now easily copy one stream into another with the CopyTo method in classes that inherit from the System.IO.Stream class.
New Path.Combine method overloads enable you to combine file paths.
You can now parse System.Guid structures.
The new Microsoft.Win32.RegistryOptions enumeration lets you specify a volatile registry key that does not persist after the computer restarts.
Registry keys no longer are restricted to a maximum length of 255 characters.

I’m really looking forward to these improvements, particularly Enum.HasFlags, Enum.TryParse, String.IsNullOrWhiteSpace, Guid.TryParse, and Path.Combine(string[]). Of course, since some of these weren’t in Beta 1 (at least as far as I saw), it means revising some of the chapters for my book.

Technorati Tags: Visual Studio 2010,Beta 2,.NET 4.0

Premature optimization is the root of all evil

Scott Dorman — Sat, 29 Aug 2009 03:24:41 GMT

I’ve lost count how many times I’ve heard that quote. It’s a great quote said by one of the leading minds in computer programming and formal mathematics, Donald Knuth. The problem with this quote is that, like so many other things, people have only remembered (or only quote) a small portion of the entire thing.

To read the full quote, you need to look at a paper published in December 1974 titled Structured Programming with go to Statements in Computing Surveys.

The full quote is this (in reference to a loop optimization technique that provides a 12% performance improvement):

The conventional wisdom shared by many of today's software engineers calls for ignoring efficiency in the small; but I believe this is simply an overreaction to the abuses they see being practiced by pennywise-
and-pound-foolish programmers, who can't debug or maintain their "optimized" programs. In established engineering disciplines a 12% improvement, easily obtained, is never considered marginal; and I believe the same viewpoint should prevail in software engineering. Of course I wouldn't bother making such optimizations on a oneshot job, but when it's a question of preparing quality programs, I don't want to restrict myself to tools that deny me such efficiencies.

There is no doubt that the grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.

Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code
has been identified. It is often a mistake to make a priori judgments about what parts of a program are really critical, since the universal experience of programmers who have been using measurement tools has been
that their intuitive guesses fail. (Computing Surveys, Vol. 6, No. 4, December 1974, p. 268 [p. 8 of the PDF])

While the overall sentiment could be summed up simply as “premature optimization is the root of all evil”, I think the point being made here is that well-known optimizations can and should be applied otherwise time spent on optimizing code should be focused on that small percent of critical code and should be performed with quantitative means.

What are well-known optimizations? That partly depends on your programming language and partly on your problem domain. Optimizations specific to a problem domain are very domain specific and not easily communicated outside of that domain. However, language specific well-known optimizations are a different story.

Take string concatenation inside a loop, particularly for languages like C# where strings are immutable objects. Why is that important? Since strings are immutable, they cannot be changed once created. When concatenating two strings you incur overhead from the creation of temporary strings. For example, consider the following code:

     string s = "this is " + "a test.";

While this is an arbitrary example, in order for this line to execute it would be necessary to create 3 strings. (Yes, I know the compiler (and if not the compiler, the JIT) would optimize this to remove the concatenation, but pretend for a moment that it didn’t.) Now, imagine this line running inside a loop 10 times. That loop has just created approximately 30 temporary string objects to perform that concatenation. In such a situation, it should be intuitive that the use of a StringBuilder to perform the string concatenation is preferable as you no longer have the intermediate string object creation and result in one allocation to create the StringBuilder and one allocation to convert the StringBuilder to an actual string object. There is always the possibility that while iterating through the loop the StringBuilder may need to perform a few additional buffer reallocations, but that still results in less overhead than creating immutable string objects.

The point here is that while it is true that premature optimization is the root of all evil, optimization should be a measured undertaking and well-known optimizations applied early are not premature.

Getting a custom attribute

Scott Dorman — Mon, 08 Jun 2009 18:31:58 GMT

Attribute programming has a lot of benefits and, when done correctly, can greatly simplify the amount of code that you need to write. One drawback to using attributes is that the code required to retrieve a custom attribute from a type is a bit cumbersome and is very repetitious.

Given a type, the simplest way to retrieve a custom attribute is code like

CustomAttribute attribute = Attribute.GetCustomAttribute(customType.GetType(), typeof(CustomAttribute), true) as CustomAttribute;

While this is simple code, it doesn’t handle any error conditions and requires that you always remember to perform the cast. A more complete method would look like

public static CustomAttribute GetAttribute(MemberInfo element)
{
    CustomAttribute attribute = null;

    try
    {
        attribute = Attribute.GetCustomAttribute(element, typeof(CustomAttribute), true) as CustomAttribute;
    }
    catch
    {
        // We aren't really interested in the exceptions here, but if we do get an exception
        // just return null;
        attribute = null;
    }

    return attribute;
}

This nicely encapsulates the error handling and casting, but introduces another drawback. In order to make use of this method you would need to include it on every custom attribute you create, being sure to change the types appropriately.

We can make this more practical by changing to a generic extension method with very little effort

public static T GetAttribute<T>(this MemberInfo element) where T: Attribute
{
    T attribute = null;

    if (element != null)
    {
        try
        {
            attribute = Attribute.GetCustomAttribute(element, typeof(T), true) as T;
        }
        catch
        {
            // We aren't really interested in the exceptions here, but if we do get an exception
            // just return null;
            attribute = null;
        }
    }

    return attribute;
}

The benefit here is that, because this is implemented as an extension method it is available as if it were a real method call on any class derived from MemberInfo, which happens to be the base class for all of the Type classes.

Now, we can define our custom attributes without any special consideration to providing a strongly typed GetAttribute method and when we want to retrieve a custom attribute, we can use code that now looks like

CustomAttribute attribute = customType.GetType().GetAttribute<CustomAttribute>();

It might not look like a major change in the calling site, but we are now able to quickly and easily get a strongly typed attribute given an instance type.

Technorati Tags: C#,Attributes

Code Contracts in .NET

Scott Dorman — Tue, 03 Mar 2009 00:44:15 GMT

I have previously talked about code contracts in .NET 4.0, and while .NET 4.0 isn’t out yet you can work with them now in Visual Studio 2008 through MSDN DevLabs.

In case you aren’t familiar with code contracts in .NET, this is a feature that was actually built by the .NET CLR team to provide a language-agnostic way to express code assumptions in the form of pre-conditions, post-conditions, and object invariants.

There are currently two tools provided:

Runtime Checking, which uses a binary rewriter to modify a program by injecting the contracts, which are checked as part of program execution.
Static Checking can decide if there are any contract violations without even running the program. It checks for implicit contracts, such as null dereferences and array bounds, as well as the explicit contracts.

This is definitely something to take a look at and start getting familiar with in order to simplify your code and testing.

Technorati Tags: Code Contracts,.NET

MVP Summit 2009 Twitters

Scott Dorman — Sun, 01 Mar 2009 23:45:00 GMT

If you’re at MVP Summit 2009 (or not at Summit) and trying to find people to follow I’ve started putting together a list of MVPs and Microsoft employees that I know who are here.

Everyone should be using the #mvp09 hashtag for their tweets, so you can follow the conversations using #hashtags, Twitter Search, Twopular, TweetScan, or any other twitter search sites.

If you want to be included in this list (or have updates to your information), leave a comment or message me on Twitter.

Microsoft MVPs

Name	Twitter	Blog	Location
Scott Dorman	http://twitter.com/sdorman	http://geekswithblogs.net/sdorman	Tampa, FL
Nikita Polyakov	http://twitter.com/NikitaP	http://geekswithblogs.net/campuskoder/Default.aspx	Tampa, FL
Bill Reiss	http://twitter.com/billreiss	http://www.bluerosegames.com/silverlightbrasstacks/	Tampa, FL
Rob Zelt	http://twitter.com/robzelt	http://www.robzelt.com/blog/	NC
Keith Elder	http://twitter.com/keithelder	http://keithelder.net/blog/	Hattiesburg, MS
Todd Miranda	http://twitter.com/tmiranda	http://www.xperimentality.com/	Alabama
Alan Stevens	http://twitter.com/alanstevens	http://netcave.org/	Knoxville, TN
Jeff Barnes	http://twitter.com/jeff_barnes	http://jeffbarnes.net/blog/	Birmingham, AL
Dennis Bottjer	http://twitter.com/dbottjer	http://drowningintechnicaldebt.com/blogs/dennisbottjer/default.aspx	Tulsa, OK
Shervin Shakibi	http://twitter.com/ShervSherv	http://www.geekswithblogs.com/shervin/Default.aspx	Boca Raton, FL
Simone Chiaretta	http://twitter.com/simonech	http://codeclimber.net.nz/	Milan, Italy
Stephen Foskett	http://twitter.com/sfoskett	http://blog.fosketts.net/	Wooster, OH
Dave Noderer	http://twitter.com/davenoderer	http://geekswithblogs.net/dnoderer/Default.aspx	Deerfield Beach, FL
David Silverlight	http://twitter.com/HeadGeek		Miami, FL
Bill Pytlovany	http://twitter.com/BillP	http://bitsfrombill.com/	Scotia, NY
Joseph Guadagno	http://twitter.com/jguadagno	http://www.josephguadagno.net/default.aspx?AspxAutoDetectCookieSupport=1	Chandler, AZ
Tony Ramos	http://twitter.com/tonyramos	http://tonyramos.com/	Cleveland, OH
Marques Lyons	http://www.twitter.com/tromboneforhire	http://www.insidethecircle.net/	Anaheim, CA

Microsoft Employees

Name	Twitter	Blog	Focus Area/Position
Kevin Pilch-Bisson	http://twitter.com/Pilchie	http://blogs.msdn.com/kevinpilchbisson	Dev Lead – C#
Jake Grey	http://twitter.com/jake_grey		MVP Lead - C# & Security, Community and Online Support
P.J. Forgione	http://twitter.com/pj_forgione		MVP Lead – Visual Basic
Joe Healy	http://twitter.com/devfish	http://devfish.net	Developer Evangelist – Florida
Scott Hanselman	http://twitter.com/shanselman/	http://www.hanselman.com/blog	Principal Program Manager
Luis Daniel	http://twitter.com/luisdans	http://blogs.msdn.com/luisdans/	Developer Platform Evangelism Area Lead – Latin America

Technorati Tags: MVP09,Twitter

Visual Studio 2008 Debugging Tricks – Multi-Threaded Debugging

Scott Dorman — Sat, 14 Feb 2009 22:16:53 GMT

We previously talked about the Location, Condition and Hit Count modifiers for advanced breakpoints. These are great for a lot of different debugging scenarios, but what about tricks specifically for debugging multi-threaded applications. If you have ever tried to debug a multi-threaded application you know that it isn’t always the easiest experience.

Hopefully everyone is already familiar with the Treads window. If you aren’t, it is accessed through the Debug|Windows|Threads menu or the Ctrl+D, T keyboard shortcut. The threads window is only available when you are actively in a debug session.

The Threads window provides a few useful tricks of it’s own that you might not be aware of. The first three tricks are available from the context menu.

You can freeze threads to avoid bouncing around when single stepping and you can switch to a specific thread.

Giving threads meaningful names is very helpful in helping to identify your threads and not all threads have a meaningful name (or in some cases, they don’t have a name at all). Fortunately, you can rename threads directly from the Threads window as well. You can do this using either the Rename context menu or simply clicking in the Name column and typing.

The Threads window also makes it easier to identify the main and worker threads by using the green and yellow color squares. Perhaps the most interesting new feature is the ability to flag threads. Once a thread is flagged, you can use use the Debug Location toolbar to only display those flagged threads. This is a great simplifying option for applications that have a lot of threads.

One other benefit of the Threads window is that by hovering the mouse over the Location column (or the current thread indicator, which is the yellow arrow) you can see the call stack for that thread. This is really useful if you just need to check the call stack quickly and don’t actually want to switch to that thread.

One last trick to mention is the Show Threads in Source option. This is available from the Threads window context menu and also the Debug toolbar.

When this option is turned on you get some very nice visual indicators to show information about your threads. If you look carefully, you will see that the breakpoint symbol actually has a red and blue squiggly line through it and, just below that you see a similar marker. If you hover the mouse over the threads marker you will see a debug tool tip that shows you all of the threads that are executing at that location. If you notice there are also some source code lines shaded in grey, which indicates that another thread is executing at the same location.

One word of caution with the Show Threads In Source option: You must have this option enabled before your debug session begins in order for it to behave correctly.

Now, let’s take a look now at the Filter modifier. This is used to restrict the breakpoint to only being set in certain processes and/or threads. When you choose the filter modifier, the Breakpoint Filter dialog is displayed

which allows you to specify the machine name, process id (or name), and/or the thread id (or name). Using the threads shown earlier, if we wanted to restrict a breakpoint to only being set in Thread 3 we could set the filter to either of these expressions:

ThreadId = 2020
ThreadName = "Thread 3"

Two important things to be aware of here are that the machine/process/thread keywords are case insensitive and that the “==” operator is supported.

Technorati Tags: Visual Studio, Advanced, Debugging

Adding custom assertions to MSTest

Scott Dorman — Sun, 01 Feb 2009 03:10:45 GMT

In my last post I talked about migrating from NUnit to MSTest and mentioned that there were some Assert methods that NUnit provided which did not have corresponding methods in MSTest. For reference, those unavailable Asserts are:

Assert.IsNaN
Assert.IsEmpty
Assert.IsNotEmpty
Assert.Greater
Assert.GreaterOrEqual
Assert.Less
Assert.LessOrEqual
Assert.IsAssignableFrom
Assert.IsNotAssignableFrom
CollectionAssert.IsEmpty
CollectionAssert.IsNotEmpty
StringAssert.AreEqualIgnoringCase
StringAssert.IsMatch
FileAssert.AreEqual
FileAssert.AreNotEqual

Even though MSTest does not provide the same extensibility capabilities as NUnit, it is still possible to add these missing Assert methods by creating your own class library to reference in your unit test project.

In order to help ease any potential issues in migrating from NUnit to MSTest caused by the lack of these Assert methods, I have created a class library that includes all of them except the FileAssert methods and StringAssert.IsMatch. These methods should behave exactly like they do in NUnit. (In fact, the unit tests are the same ones used in NUnit, with only a few minor differences.)

The following table shows the changes you will need to make in order to use the new asserts. As you can see, the changes can be easily made using search and replace.

NUnit		MSTest Extension Library
Assert.IsNaN		ConditionAssert.IsNaN
Assert.IsEmpty		CustomAssert.IsEmpty
Assert.IsNotEmpty		CustomAssert.IsNotEmpty
Assert.Greater		ConditionAssert.Greater
Assert.GreaterOrEqual		ConditionAssert.GreaterOrEqual
Assert.Less		ConditionAssert.Less
Assert.LessOrEqual		ConditionAssert.LessOrEqual
Assert.IsAssignableFrom		TypeAssert.IsAssignableFrom
Assert.IsNotAssignableFrom		TypeAssert.IsNotAssignableFrom
CollectionAssert.IsEmpty		CustomAssert.IsEmpty
CollectionAssert.IsNotEmpty		CustomAssert.IsNotEmpty
StringAssert.AreEqualIgnoringCase		CustomAssert.IsNotEmpty

I also added the ExceptionAssert class from my post talking about the dangers of using the ExpectedException attribute.

You can download the class from my SkyDrive public folder.

Technorati Tags: Unit Tests, MSTest, NUnit

Migrating from NUnit to MSTest

Scott Dorman — Sat, 31 Jan 2009 18:39:15 GMT

I have been writing a lot of unit tests over the past month using the Microsoft Test (MSTest) unit testing framework that is now part of Visual Studio 2008 Professional Edition (and higher SKUs). Currently I have about 223 unit tests covering 39 classes (about 18K lines of code, 325 methods and 176 properties) with a code coverage percent of 97%.

The classes that I’m testing previously had NUnit tests (although not as many as I currently have) and used NCover and NCover Explorer for my code coverage analysis. I had looked at MSTest when it first came out and decided against using it because it was only available in the Visual Studio Team System SKUs, which meant it wasn’t generally available to the development community at large, and required Visual Studio to be installed in order to use it.

Since then, Microsoft has addressed both of those issues and I decided it was time to give MSTest another look. In doing so, I decided to see if it would be possible to leverage the existing NUnit tests rather than starting completely from scratch. One word of caution…if you use the newer constraint model in NUnit, your unit tests will not easily migrate to MSTest and you are probably better off starting fresh using MSTest.

It turned out to be a relatively painless process that can be broken down to the following steps:

Replace the reference to the Nunit.Framework assembly with a reference to the Microsoft.VisualStudio.QualityTools.UnitTestFramework assembly.
Replace the “using Nunit.Framework” line with “using Microsoft.VisualStudio.TestTools.UnitTesting”
For each file containing unit tests, replace the following attributes (you can use global search and replace for this):

NUnit Attribute	MSTest Attribute
TestFixture	TestClass
Test	TestMethod
SetUp	TestInitialize
TearDown	TestCleanup
TestFixtureSetup	ClassInitialize
TestFixtureTearDown	ClassCleanup

Replace the following method calls:

NUnit Method Code	MSTest Method Call
Assert.Ignore	Assert.Inconclusive

At this point, the easy stuff is done, but Visual Studio will not recognize your project as an MSTest unit test project. (This only applies if you don’t create a new Unit Test project in Visual Studio to hold your converted tests.) If that’s the case, you need to edit the project file using a text editor and add the following tag to the first <PropertyGroup> in the XML:

        1: <ProjectTypeGuids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>

(These Guids are for a C# project. For a VB project, replace the second Guid with {F184B08F-C81C-45F6-A57F-5ABD9991F28F}.)

Depending on the complexity of your original NUnit tests, you may be done at this point. However, if you relied on NUnit TestFixtureSetup or TestFixtureTearDown methods you will need to make a few other changes.

In NUnit, these attributes would be applied to a non-static void method that takes no parameters. For MSTest, the methods must be static and the ClassInitialize method must take a TestContext parameter. This also means that you should add a public TestContext property as well. What you end up with is code that looks like this:

       1: private TestContext testContextInstance;

       2:  

       3: /// <summary>

       4: ///Gets or sets the test context which provides

       5: ///information about and functionality for the current test run.

       6: ///</summary>

       7: public TestContext TestContext

       8: {

       9:     get

      10:     {

      11:         return testContextInstance;

      12:     }

      13:     set

      14:     {

      15:         testContextInstance = value;

      16:     }

      17: }

      18:  

      19: [ClassInitialize()]

      20: public static void ClassInit(TestContext context)

      21: {

      22:     MessageBox.Show("ClassInit " + context.TestName);

      23: }

      24:  

      25: [ClassCleanup()]

      26: public static void ClassCleanup()

      27: {

      28:     MessageBox.Show("ClassCleanup");

      29: }

If you had code in your NUnit TestFixtureSetup or TestFixtureTearDown methods that manipulated non-static data you will need to rework your tests or move that code to a constructor/finalizer combination to achieve the same results.

Unfortunately, the Assert (and related classes) used by MSTest are not as complete as the ones offered by NUnit so you may also end up changing some of your tests. The following Asserts are not available in MSTest:

Assert.IsNaN
Assert.IsEmpty
Assert.IsNotEmpty
Assert.Greater
Assert.GreaterOrEqual
Assert.Less
Assert.LessOrEqual
Assert.IsAssignableFrom
Assert.IsNotAssignableFrom
CollectionAssert.IsEmpty
CollectionAssert.IsNotEmpty
StringAssert.AreEqualIgnoringCase
StringAssert.IsMatch
FileAssert.AreEqual
FileAssert.AreNotEqual

You may be tempted to replace StringAssert.IsMatch with StringAssert.Matches from MSTest but they really aren’t equivalent methods. StringAssert.Matches matches the actual result against a regular expression pattern.

The other thing to watch out for is any place you use the ExpectedException attribute. The syntax is identical between NUnit and MSTest, however the meaning is not. In NUnit, the message parameter is used to verify the message of the exception (by comparing the Message property of the exception with this text). MSTest uses this text as the message to display if the exception is not thrown. There are better ways to test for exceptions that don’t use the ExpectedException attribute at all.

All in all, I’ve been very happy with the relative ease of migrating my NUnit tests to MSTest and using the MSTest framework in general. Yes, there are things that the older unit testing frameworks provide that MSTest does not, but I believe that is just a matter of age. In time, MSTest will offer the same functionality. The nice thing about MSTest is that it is built in to Visual Studio and the code coverage and unit testing capabilities are integrated with the IDE without requiring additional tools, add-ins, macros, or other hoops in order to run your tests and evaluate the results. Everything you need to write effective unit tests, analyze the results and ensure good code coverage is already available to you.

Technorati Tags: MSTest, Unit Tests, NUnit

Reading all bytes from a Stream

Scott Dorman — Sat, 10 Jan 2009 21:24:47 GMT

I was working on some Stream extensions today and added a method which will read all of the data from a stream in to a byte array. Some of the classes which derive from Stream provide a similar method (MemoryStream, for example, provides a GetBuffer() method to do this). The drawback here is that the base Stream class doesn’t provide an abstract GetBuffer() method; instead it’s up to each individual derived class to implement such a method. This is perfectly reasonable as a stream may not have an underlying buffer for storage like MemoryStream does.

Taking that into consideration, you read streams the same way. The call to Stream.Read() takes an array of bytes as a buffer to fill during the read operation. It would be nice to be able to get the entire contents of the stream as a byte array.

Looking around I found an excellent blog post by Jon Skeet that provides a few implementations on how to do this. The thing I didn’t like about Jon’s implementation is that it uses Array.Copy in order to resize the array (when there is more data available than the buffer can hold) and to return the properly sized array at the end. (It also has two exit points, which I don’t ordinarily like, but that’s a minor issue.)

The concern with using Array.Copy is that it accesses the elements by index and must be somewhat generic in order to support all of the .NET languages. Since streams tend to be rather large, this introduces unnecessary overhead.

At this point, you might be asking “Why unnecessary overhead? How else do you copy arrays?” This question brings us to System.Buffer, which has been available in .NET since .NET 1.1 although you’ve probably never heard of it until now. A Buffer is designed to manipulate arrays of primitive types and treats each type as a series of bytes without any regard to behavior or limitations. How does this help us? Remember, Stream.Read returns an array of bytes and byte is a primitive type. So we can use Buffer to copy the array elements directly in memory rather than by index, which provides better performance than Array.Copy.

After modifying Jon’s implementation to use Buffer, fixing an issue I noticed (the stream’s position was never reset to 0 prior to reading) and getting rid of that pesky second exit point, my implementation is:

        1: /// <summary>

       2: /// Reads the contents of the stream into a byte array.

       3: /// data is returned as a byte array. An IOException is

       4: /// thrown if any of the underlying IO calls fail.

       5: /// </summary>

       6: /// <param name="stream">The stream to read.</param>

       7: /// <returns>A byte array containing the contents of the stream.</returns>

       8: /// <exception cref="NotSupportedException">The stream does not support reading.</exception>

       9: /// <exception cref="ObjectDisposedException">Methods were called after the stream was closed.</exception>

/// <exception cref="System.IO.IOException">An I/O error occurs.</exception>

public static byte[] ReadAllBytes(this Stream source)

{

    long originalPosition = source.Position;

    source.Position = 0;

  

    try

    {

        byte[] readBuffer = new byte[4096];

  

        int totalBytesRead = 0;

        int bytesRead;

  

        while ((bytesRead = source.Read(readBuffer, totalBytesRead, readBuffer.Length - totalBytesRead)) > 0)

        {

            totalBytesRead += bytesRead;

  

            if (totalBytesRead == readBuffer.Length)

            {

                int nextByte = source.ReadByte();

                if (nextByte != -1)

                {

                    byte[] temp = new byte[readBuffer.Length * 2];

                    Buffer.BlockCopy(readBuffer, 0, temp, 0, readBuffer.Length);

                    Buffer.SetByte(temp, totalBytesRead, (byte)nextByte);

                    readBuffer = temp;

                    totalBytesRead++;

                }

            }

        }

  

        byte[] buffer = readBuffer;

        if (readBuffer.Length != totalBytesRead)

        {

            buffer = new byte[totalBytesRead];

            Buffer.BlockCopy(readBuffer, 0, buffer, 0, totalBytesRead);

        }

        return buffer;

    }

    finally

    {

        source.Position = originalPosition;

    }

}

It will still generally use at least 2 arrays (if the original array is already the same size as the total number of bytes read, it will not resize it) and sometimes a 3rd array (created inside the while loop) when the stream is larger than the original array. However, by using the Buffer.BlockCopy and Buffer.SetByte rather than the Array methods it should offer better performance.

Technorati Tags: C#, .NET, Streams, Buffer