As I stated in my last post, the var keyword is an acknowledgement that I do not care what the type of the variable is - I only care what it can do.

Into the IUknown

Most developer start on the path to this revelation when they discover interface-based programming.

Consider: we need to write a method that returns a collection of strings. Callers of the method will only need to loop over the items and perform some action. The number of elements to return is not known at compile time, so we'll declare a generic List<string>, populate it within a loop, and then return it to the caller.

The junior developer will declare the return type of the method as List<string>:

List<string> GetNames(){}

Acknowledging that callers should not be bothered with having to know an implementation detail (the fact that a List was used instead of a fixed-sized array), and knowing that they only need to loop over the returned items, a more experienced developer might declare the method:

IEnumerable<string> GetNames() {}

Which means any variable the receives the return value will also be typed as IEnumerable<string>:

IEnumerable<string> names = GetNames();

Here's the kicker - in both scenarios, the GetNames method is really returning an object of type List<string>! When the supposedly more experienced developer chooses to return a more abstract type like IEnumerable<string>, type information is lost. Yikes! The names local variable above holds a List<string> instance, but you (the client developer) don't know it. As scary as that might sound, you probably realize that you don't care. As long as you can do the things you need to do with names (loop over it), you are happy.

Walking like a duck

Now let's take that train of thought and consider duck typing in a dynamic language like Python. I can declare the following method:

def Recycle(service):
    service.Stop()
    service.Start()

It takes a single parameter named service. What is the type of the parameter that is expected? I don't know. And after the initial anxiety settles, there is the liberating realization that I don't have to care! All I know, or care, is that any object instance that is passed to this method must implement a Start() and a Stop() method. The same method can be used with instances of a Lawnmower, AuditLogger, or SongPlayer class (assuming they all have Start and Stop methods).

Getting closer to the goal

Let me be clear - I am not suggesting that implicit typing in C# 3.0 is the same as duck typing. What I am suggesting is that the 2 examples above are points along the "progression of understanding" of the same concept: it is the behavior of an object that really matters, as opposed to the type name that is attached to it. Interface-based programming is near the start. Implicit typing is further along the progression. Duck typing is closer to the end.

I think we will find that programmers who have been exposed to and understand languages which support duck typing will be more likely to be comfortable with and embrace the var keyword. They have already made the mental leap that type information serves the computer more than it serves the human. If you haven't yet, do yourself a favor and learn a dynamic programming language, even if you know you will continue to spend your days with static typing.

Dare Obsanjo asked the question To var or not to var? He asserted "case closed" at the end of his post, and closed it to further comments, but I would like to continue the conversation.

He pulls out the common straw man argument that the anti-var (C# 3.0's implicity type keyword) crowd likes to attack. They assume that fans of implicit typing just want to save a few keystrokes. It isn't about less keystrokes. For me, its about thinking a little bit less like a computer and a little bit more like a human. I prefer to think less about Types and more about behaviors. The var keyword is an acknowledgement that I do not care what the type of the variable is - I only care what it can do.

I'll address a few specific quotes from his post (emphasis is mine).

[Referring to ReSharper] So it seems there are two suggestion modes. The first suggests using the var keyword when the name of the type is obvious from the right hand side expression being evaluated such as casts or new object creation. The second mode suggests replacing type declarations with the var keyword anywhere the compiler can infer the type... The first suggestion mode makes sense to me since the code doesn't lose any clarity and it makes for shorter code. The second mode is the one I find problematic it takes information out of the equation to save a couple of characters per line of code.

In both situations, it is about removing compiler noise. I have already given the compiler enough information for it to do its job. I don't care about a couple characters.

For example, the claim that it leads to "better naming for local variables" really means it compels developers to use LONGER HUNGARIAN STYLE VARIABLE NAMES.

Longer, more descriptive variable names? Yes, please. Hungarian style? That assumes I care about the type (which I don't see my follow-up post).

...these long variable names add more noise to the code overall since they show up everywhere the variable is used compared to a single type name showing up when the variable is declared.

This is completely different understanding of the term "noise" as it relates to code. To me, "noise" in a computer language is all of the stuff that makes code look like something that needs to be decoded. It is all of the stuff that normal humans would not use when communicating with each other. Your source code is a communication medium - it communicates intent to the computer, and to the humans that need to maintain it. Anything that is added purely for the computer's benefit is noise to the human. It commonly takes the form of angle brackets, parentheses, semi-colons, etc. Sometimes it takes the form of redundant or extraneous type information. But I would never consider a descriptive variable name "noise", just because it takes up a little more screen real-estate.

It is interesting that Dare seems to reject the argument that var helps promote use of better variable names, and yet the example which spurred his post illustrates it perfectly:

I found this change to be somewhat puzzling since while it may have shortened the code by a couple of characters [There he goes counting characters again] on each line but at the cost of making the code less readable. For example, I can't tell what the type of the variable named lvi is just by looking at the code.

The var keyword did not make the code less readable, it just made the poor choice of variable names more apparent. Might listItem or feedItem be a little more readable than lvi?

It seems his primary argument against var is that always knowing the type of a variable is of utmost importance. Why? When you are writing code, doesn't your IDE let you know what behaviors are available to your object instances? When you are reading code, can you not assume that the compiler has already checked it for invalid code?

Ayende Rahien will be giving a course on buliding DSLs with Boo in Austin on May 19-20. I'm a closet fan of Boo, having lurked on the mailing list for about 6 months, and really looking forward to getting a stronger grasp of the language, and the benefits of building your own domain specific languages. This is a great opportunity to learn from the preeminent creator of Boo DSLs.

Scott Bellware sent a good writeup to the AgileATX mailing list:

This class takes you deeper into the reasoning and power of dynamic
programming on the CLR.  It will show you how to build and take
advantage of DSL's for your own CLR applications, and why DSL's and
language-oriented programming are such a valuable practice at this
point on the programming timeline. 
You'll leave this class having been jump-started on a new, powerful
language and paradigm, and be connected to other motivated .NET folks
who are working toward bringing some of successes of dynamic
programming communities into the .NET community.

The class will also give you the opportunity to check out a town that
folks are starting to recognize as a progressive and leading .NET
competency in North America, and to have some fun with Austin's
developer community folks in lush green and sunshine of Central Texas.

There are still some spots open, if you are interested you can register here.

So a high profile ALT.NETter, who is not in attendance at this weekend's altnetconf, has decided he no longer wants to be associated with the group because of its perceived negativity. It is a shame he wasn't here in person to experience the bizarro-world like ending to Day 2. The closing remarks, which is a chance for anyone in attendance to stand and share their thoughts on the day, were composed entirely of expressions of excitement around the just demonstrated System.Web.MVC framework, and thanks and appreciation to the Microsoft ASP.NET team that created it. This is not an easy crowd to please, but mostly because we all want to be able to assert our preference of tools and practices individually. NOT because we want to use "anything but Microsoft", but because we want to be able to choose "some things that are not from Microsoft". When Microsoft does provide a great tool (as they did with the .NET Framework, and potentially the MVC framework) members of the crowd are willing embrace it. Now, we are not a hive mind (a fact which seems to be frustrating some people that want us to come to some kind of consensus... on anything), so I won't say everyone is excited about it. But unlike the earlier opening remarks, at the end nobody stood up to air their grievances with Microsoft. It was all smiles and love for Scott Guthrie (who was there demonstrating the framework and representing the ASP.NET team). Yes, even from Scott Bellware.

(Of course, it may all be a side effect of ScottGu's super-hero power of being able to foster man-crush's from entire rooms of ornery, cynical developers.)

Jeremy D. Miller recently wrote about how to make a NAnt script branch based on the machine it's runnig on. Since I've been working almost exclusively with MSBuild, I figured it might be educational to post the equivalent script.

First, in Jeremy's example, he is really only changing the values of a property based on the machine name. If that is all you need to do, the MSBuild solution is fairly straightforward. I'll include the entire file contents so that you can easily copy/paste and test, and verify their are no hidden tricks.

This takes advantage of the fact that all environment variables are immediately available as properties in an MSBuild script; and that all Windows machines (that I've worked on recently) have the COMPUTERNAME environment variable set.

However, if you actually needed to run different tasks (as opposed to just setting properties), things would look a little different. One way I might approach it would be:

I created a separate dummy target called MachineSpecificTasks. It is just used to define the different targets that you make available for each environment. I make all of the machine specific targets as dependencies on this target, so that the script will attempt to execute each of them. I could have just as easily skipped the MachineSpecificTasks target and put the dependencies on my Build target, but I felt that list might get large and get confusing. Better to hide it away. I then set a condition on each target so that it is only run if the computername environment variable matches the given computer name. I went a little further and showed how you could associate multiple computer names (PRODUCTION-SERVER1 and PRODUCTION-SERVER2) with the same set of tasks (collectively called ProductionServers).

There is probably a way to use the CallTarget task to more closely match the look of the NAnt solution, but I'm not sure if it would buy you anything.

Hope that helps.

It's official, the technology formerly known as Atlas will be called...  Microsoft AJAX Library, ASP.NET 2.0 AJAX Extensions, and ASP.NET AJAX Control Toolkit!

Wow, those names are actually intuitive and descriptive. This is such a relief, considering what COULD have been... I had my bets on the dry, but .NET 3.0 compliant "Windows Dynamic Web Foundation"? Or the completely absurd "ASP.NET 7.0" ;-)

Yeah, about that... I completely made it up. It wasn't a hoax; no, I wasn't trying to fool anyone or make anyone believe it so that I could secretly laugh at them. It was a satire, so that I could publicly laugh at the madness of Microsoft naming schemes. I wanted to try and draw some attention to the issue, and hopefully motivate some people to go sign the Reverse WinFX Petition. Not because I thought Microsoft would change their mind, but because I wanted them to get the message that we don't want marketing decisions obfuscating and hijacking the terminology that we developers use to communicate. Its a version number - it has a very specific meaning, it is not a brand. Of all the things to lift from the Java camp, why did we want the version number confusion?

If you believed my post regarding Atlas => ASP.NET 7.0, I'm sorry, it wasn't my intention to deceive. But the fact that a number of people did believe it just demonstrates the levels of absurdity we've come to expect and accept from Microsoft when it comes to branding. I tried to make it absurd. I tried to make it so ridiculous, and so obvious that it was fake (the quotes were almost word for word cut from one of the linked articles about the .NET 3.0 naming), but people still believed it. Apparently I need to work on my comedic writing and satirical wit.

Thanks to the Microsoft Web Platform team for the sane naming and their ability to continue delivering technology without waiting for a large release vehicle (and sorry for any confusion the last post may have caused).

• Allow unexpected exceptions on all threads to be logged by a top level exception handler
• Do not let the application die because of an exception, no matter which thread it is running on (at least not before I get a chance to log it).
• Do not clutter the application logic with repeated try..catch and logging code.

System.Threading.ThreadPool.QueueUserWorkItem(new SafeWaitCallback().Call(DoTask));

using System;
using System.Net;
using System.IO;
using System.Runtime.Serialization.Formatters.Binary;
using System.Runtime.Serialization;

publicclass SafeWaitCallback {
  publicstatic Uri ApplicationUri;
  System.Threading.WaitCallback callback;

  public System.Threading.WaitCallback Call(System.Threading.WaitCallback callback) {
    this.callback = callback;
    return CallbackWrapper;
  }

  privatevoid CallbackWrapper(object state) {
    try
    {
      callback(state);
    }
    catch (Exception e)
    {
      byte[] exceptionData;

      MemoryStream stream =new MemoryStream();
      BinaryFormatter formatter =new BinaryFormatter(null, new StreamingContext(StreamingContextStates.Persistence));
      formatter.Serialize(stream, e);
      exceptionData = stream.ToArray();

      WebClient client =new WebClient();
      Uri handler =new Uri(ApplicationUri, "TransferException.axd");
      try
      {
        client.UploadData(handler, exceptionData);
      }
      catch (WebException) { }
    }
  }
}

using System;
using System.Web;
using System.IO;
using System.Runtime.Serialization.Formatters.Binary;
using System.Runtime.Serialization;

publicclass TransferredExceptionHandler : IHttpHandler {
  publicbool IsReusable { get { returntrue; }}

  publicvoid ProcessRequest(HttpContext context) {
    byte[] exceptionData =newbyte[context.Request.ContentLength];
    context.Request.InputStream.Read(exceptionData, 0, exceptionData.Length);

    Exception transferredException;
    MemoryStream stream =new MemoryStream(exceptionData);
    BinaryFormatter formatter =new BinaryFormatter(null, new StreamingContext(StreamingContextStates.Persistence));
    transferredException = (Exception)formatter.Deserialize(stream);
    thrownew Exception("[Background exception transferred - see InnerException]", transferredException);
  }
}

Download AspNetBackgroundExceptions.zip (2.55 KB)

Now, instead of burying in your blog your sage advice on how to really use the classes in the .NET Framework, despite what the documentation says, you can add it right to the source for everyone to see.
http://msdnwiki.microsoft.com

I only mention it, because that's where I will be putting most of my sage advice going forward.

• Properties now display in the order they are listed in web.config
  
• Design-time view now uses same rendering method as runtime
• Fixed design-time bug that caused it to fail when a profile property type was not specified
• Design-time view now has a Smart Tag to allow you to preview an anonymous user's profile
  

Of the billion toolbar buttons that Visual Studio 2005 includes, I couldn't find one to open a command prompt to the project directory. This is a must-have for us command-line SubVersion users. Luckily, a quick Google search turned up this post (its actually the comment from Barry Gervin that I credit). Updated for VS 2005:

From the Tools -> External Tools... menu, click Add, and fill in:

Title: Command Prompt &Here
Command: C:\WINDOWS\system32\cmd.exe
Arguments: /k ""C:\Program Files\Microsoft Visual Studio 8\VC\vcvarsall.bat"" x86
Initial Directory: $(ProjectDir)

Note the Title is important only because I wanted to use the letter 'H' as my shortcut key since it is close to the 'T', and unused on the default Tools menu. This enables the very easy one-handed keystroke ALT+T,H.

I then went to Tools->Customize..., selected Tools from the Categories, then found "External Command 3" (there were 2 other tools already registered in VS) in the Commands section, and dragged it up to my toolbar. Right-click on the new button on the toolbar, select Default Style, then Change Button Image, and choose the square (its a good starting point). Using Edit Button Image... I drew a crude "C:".

When creating a designer for an ASP.NET server control, it is often very useful to read settings from the user's web.config file. In previous versions of the .NET Framework, you had to jump through hoops to access the web.config file at design time. I was very thankful for this solution when I needed it, but I'm happy to move on. The dependency on EnvDTE felt wrong, and the fact that it used COM interop with the VS.NET IDE meant it probably would not work with any other tool.

Thankfully, in .NET 2.0, it is much simpler. If you want to get the full path to web.config (useful for parsing the XML manually), it has been reduced to:

Note: you will want to check for nulls and handle appropriately. The call to GetService could return null if the design tool hosting your control does not support this service (something other than VS.NET). And of course the call to GetProjectItemFromUrl could fail if there is no web.config in the project.

Even better, instead of parsing web.config yourself, you can get strongly-typed access to the configuration using the new classes in the System.Configuration namespace. For example, in my ProfileView control, I use code similar (more null checking) to the following to discover information about the configured profile properties:

Once you get the Configuration object as demonstrated above, reading a value out of the appSettings section is as easy as:

Of all the new providers that ASP.NET 2.0 introduces, I think the RoleProvider will be the most frequently implemented in a corporate IT environment. Intranet applications can usually take advantage of Windows integrated authentication for user identification. By default, this will create a WindowsPrincipal object that contains all of the user's domain groups as roles to be used for authorization. However, it has been my experience that most applications do not use domain groups for their role-based authorization. It is more likely that they have a database (or some other store) that associates a user's Windows login name with application specific roles.

In the past (.NET 1.x), you could get around this by hooking into the HttpApplication.AuthenticateRequest event (via Global.asax or an IHttpModule). You would lookup the user's roles in your data store, initialize a GenericPrincipal with the roles, and then use it to replace the WindowsPrincipal on the current thread*.

This process is greatly simplified by the introduction of the RoleProvider framework, which is already hooked into the request processing lifecycle by way of the RolePrincipal class. This means you no longer need to manually hook into an application event or create a custom principal, just to set the user's roles. The provider model allows you to focus your code on the singular task of retrieving the roles for a user.

The biggest drawback to the new approach is that the contract for a RoleProvider is pretty extensive. In addition to the large number of methods that must be implemented, there are additional "expected implementation details" that the signatures do not cover (a topic recently discussed by K. Scott Allen).

The good news is that these implementation details have been thoroughly documented in a white paper on MSDN. The bad new is that because of the wealth of information, you will probably find yourself needing to re-read that paper every time you try to implement a new provider.

That is exactly the problem I am trying to solve by introducing my ASP.NET RoleProvider Visual Studio template. Download the zip file, save it or rename it so it has a .vsi exentsion, run it, and accept the prompts (and warnings - sorry, I did not sign the code**). You will now have a new option when adding a new file to a project.

Just name the file, and a class with that name will be added to your project. The class inherits from RoleProvider, and has a stub implementation for all of the methods so it can immediately compile. At the very least, you will need to modify the GetRolesForUser() method, and take a look at each section marked with a TODO: comment. Most of the other remaining methods will just throw a NotSupportedException. This is actually a legitimate implementation for many scenarios, as you may not need the additional functionality of the RoleManager. However, if you do want to implement a full solution, the whitepaper guidance for each method is included as comments. If you find the guidance comments distracting, I provided instructions on how to do a quick find/replace to delete them all.

I plan to create additional templates for the other common provider types, but I would like to get some feedback first. I want to know if people find this helpful. How could it be better? The biggest thing I struggled with is how much documentation to include. I always get a little overwhelmed when I add a new file, thinking I'm starting fresh, only to be presented with a bunch of code or comments. It creates the feeling that the person has to read and understand it all before they modify anything. I tried to put focus on the parts that matter (with the TODO comments, and calling out the main method GetRolesForUser). What do you think? Should there be more guidance comments, or less? Should I include the XML Documentation comments for each method, copied from MSDN?

Download the installation file here and provide feedback in the comments below.

* For a few more details on the 1.x approach, check out this article on FormsAuthentication. Step 4 is the relevant part, and works just as well for Windows authentication (use the WindowsIdentity instead of FormsIdentity).

** If you do not trust the automatic installation, you can perform a manual install. Keep the file extension from as .zip and extract the contents (a .vscontent file that you can delete, and 2 .zip files). Copy the 2 zip files to your user item templates folder - the "Visual Studio user item templates location" setting in the Projects and Solutions | General tab of the Visual Studio 2005 options dialog.

The numbers in my last post were a little misleading (as you might expect from un-scientific homebrew benchmarks). I showed that ExplicitOpen (2.5 seconds) was slightly faster than ImplicitOpen (2.9 seconds), but both were significantly faster than NoConnectionPooling (7.5 seconds). The whole point of the test was to see how the performance of running 2 queries within a method could vary, based on different approaches. However, in order to get a larger sample size, I ran the methods within a loop for 1000 iterations. It was intended to just give me more test runs, but the loop actually had a side effect. When connection pooling was enabled (for ExplicitOpen and ImplicitOpen), the same connection was used for all 1000 iterations. I had only wanted the same connection to be used for the 2 queries within the methods. So when I turned connection pooling off, the dramatic difference wasn’t because running the 2 queries was much slower – it was because I was now making 2000 connections to the database instead of 1.

If I wanted to compare the performance of running the 2 queries with connection pooling on and off, within a loop, I would need to make sure each iteration of the loop used a new connection in all 3 scenarios (ExplicitOpen, ImplicitOpen, NoConnectionPooling).
An easy way to force a new connection is to change the connection string. I changed the signature of each of the methods to accept an integer argument:

static void ExplicitOpen(int iteration)

I then added an Application Name property to the connection string; altering the application name for each iteration:

"data source=(local);initial catalog=issuevision;integrated security=true;application name=TestCP" + iteration.ToString()

The new results:

ExplicitOpen 9.0
ImplicitOpen 9.5
NoConnectionPooling 7.6

These results show that ExplicitOpen is still faster than ImplicitOpen, but now NoConnectionPooling is much faster than the other 2. How can this be? Well, since none of the scenarios are reusing a connection across iterations, you gain an advantage by removing the connection pooling overhead by explicitly disabling it in the connection string.

The original conclusion was correct (ExplicitOpen is slightly faster than ImplicitOpen), but it is difficult to measure the relative performance with connection pooling turned off. The results of running a single iteration of each method vary too widely to draw any conclusions -- you need the multiple iterations for things to average out. But once you introduce multiple iterations, you blur the effect of connection pooling.

As a bonus, we can now conclude that if you know you are not going to re-use a connection (rare, unless each user of your application is given their own database login), it is better to turn off connection pooling explicitly.

David hayden's post about explicitly opening SqlConnection objects when doing multiple SqlDataAdapter.Fill calls didn't sit well with me. The premise is that if you are going to make multiple calls to Fill(), you should open the connection first yourself, to avoid Fill() opening and closing the connection for each call. I'll quote his conclusion:

"...in the case of multiple back-to-back Fill requests to the DataAdapter, it is more performant to explicitly open the connection in the beginning so that each Fill request on the DataAdapter does not open and close the database connection, resulting in the database connection being opened and closed several times."

The reason it doesn't sit well with me, is that I believe in connection pooling. I don't know all of the gory details of how it works under the hood, but I believe it exists. I believe that when I call SqlConnection.Open(), I am not necessarily creating a new network connection to the database - I may just be re-using an existing connection that is sitting idle in the pool.

But he was quoting Sahil's Pro ADO.NET 2.0, and I have no doubt that Sahil knows more about ADO and SQL Server than I do, so I started to doubt my belief.  Maybe connection pooling really DOESN'T exist! Time to get some cold hard facts, (in the form of completely un-scientific homebrew benchmarks).

The test harness:

static void Main(string[] args)
{
System.Diagnostics.Stopwatch sw =new System.Diagnostics.Stopwatch();
sw.Start();
for (int i = 0; i < 1000; i++)
{
ExplicitOpen();
//ImplicitOpen();
}
sw.Stop();
Console.WriteLine(sw.Elapsed);
}

Very simple. Run one of the methods a thousand times, and report the cumulative elapsed time.  Comment it out, un-comment the other one, and re-run.

The code for the two different methods are almost exactly the same. I only made very minor changes to the code from David's post, to account for the fact that I didn't have the pubs database handy (I used the IssueVision database from the DevDays 2004 sample app).

Here is the code for ExplicitOpen():

static void ExplicitOpen()
{
using (SqlConnection connection =new SqlConnection("data source=(local);initial catalog=issuevision;integrated security=true;"))
{
SqlCommand sqlCat = connection.CreateCommand();
sqlCat.CommandText ="Select * from issues";
SqlCommand sqlProd = connection.CreateCommand();
sqlProd.CommandText ="Select * from staffers";

SqlDataAdapter adapter =new SqlDataAdapter();
adapter.SelectCommand = sqlCat;
DataSet dataset =new DataSet();

connection.Open();
adapter.Fill(dataset, "Issues");
adapter.SelectCommand = sqlProd;
adapter.Fill(dataset, "Staffers");
connection.Close();
}
}

ImplicitOpen() is exactly the same, only the connection.Open() and connection.Close() lines are removed.

Running ExplicitOpen() 1000 times took an average of 2.5 seconds. Running ImplicitOpen() 1000 times took an everage of 2.9 seconds. I ran them both multiple times and the numbers were always consistent, so I think they are somewhat believable.
How about that. Opening the connection explicitly IS a bit faster. So does that mean connection pooling doesn't exist?

I opened the Profiler tool included with SQL Server 2000 and created a connection to my database with the default profiling template. I removed the looping in the main method so that the method would only be called once.  This is what I saw when I ran ExplicitOpen():

Audit Login
SQL:BatchCompleted   Select * from issues
SQL:BatchCompleted   Select * from staffers
Audit Logout

This is what I saw when I ran ImplicitOpen():

Audit Login
SQL:BatchCompleted   Select * from issues
RPC:Completed        exec sp_reset_connection
SQL:BatchCompleted   Select * from staffers
Audit Logout

Aha! As you can see, there is still only 1 connection being made (a single Audit Login and Audit Logout). So it looks like we're both right. There is always 1 connection, but explictly opening is still slightly faster. The difference is the call to sp_reset_connection (which is undocumented in Books Online) which cleans up the connection so it can be re-used.

So, if I could get rid of that call to sp_reset_connection, could I get the same performance as ExplicitOpen()? I copied ImplicitOpen() to a new method and named it ImplicitOpenNoReset(). The only change I made was appending "connection reset=false;" to the end of the connection string. Running 1000 iterations took 2.6 seconds. Much closer to ExplicitOpen(), but there is still a bit of overhead. (Warning: I have no idea how safe or advisable it is to disable the connection reset - do not interpret this as a recommendation for improving your connection pooling performance for general usage - it was just for the purposes of this test.)

Finally, to prove to myself that connection pooling really does exist, and really does help, I created a new copy of ImplicitOpen() named NoConnectionPooling(). The only difference is the connection string includes "pooling=false;". Running 1000 iterations took... 7.5 seconds! Ouch.

My take away is that connection pooling really exists, it really does help you, and in general, you do not have to worry about maximing the use of an open SqlConnection object by keeping it around for multiple queries. But if you have to squeeze out the absolute best performance possible, you will get a slight gain by calling Open() once when you have consecutive queries. Thanks to David for a thought-provoking post.

Update: I discovered a flaw in my benchmarking approach which skewed some of these results. I wrote up the details in a new post.