Brendan Enrick

Daily Software Development

Old Blog Favorites

I am somewhat partial to a few of the posts from my previous blog. For some of these posts, I just like the post, some the content about which the post was written, and some were just popular posts.

Installing SQL Server Management Studio with SQL Server: My most popular post is one written about a painful experience installing SQL Server's client tools. Sadly the popular post is out of date. My first post about the topic I found a solution that worked and managed to install the software. I late found out that there was a better way and I updated the post. The problem is that Google continued to send traffic to the old one. For my blog it was a pretty popular post. it has had over 25,000 views.

The original version - Installing SQL Server Management Studio with SQL Server

The current version - SQL Server Client Tools Installation

Visible Whitespace in Visual Studio: Another post written about a traumatic experience was when I accidentally used a keyboard shortcut and enabled visible white space. It caused a blue dot to show for every space character in visual studio. Wow was it hard to read my code with that on. Well I Googled for it, and at the time I didn't receive any results. There are some now my post is one of them. I also didn't notice the option to turn it off. I used an algorithm I like to call brute force to figure out the keyboard shortcut I typed. It was Ctrl + E + S. Comments let me know of a bunch of other ways to solve the problem for different configurations and versions of Visual Studio.

Visible Whitespace in Visual Studio

Return Within a C# Using Statement: IDisposable objects are nice to work with. I prefer not dealing with external resources, which is generally what you're doing with disposable objects, but having this interface makes it a little bit nicer. I wrote a post telling people it was safe to return from within the using statement, because the using statement will make sure that the object is disposed. In the lifetime of the post only one person actually challenged me on it and asked me to provide code showing that what I said is true. I of course responded to that comment and then posted a response on this blog. My response includes sample code showing that using statements make sure that the object is disposed.

If you like the second post make sure you thank Lambros Kaliakatsos for commenting on the first one.

The original post - Return Within a C# using Statement

The follow up including sample code - Returning From Inside a Using Statement

Performance with DropDownLists and ViewState: One thing that it seems a lot of ASP.NET developers still don't understand very well is ViewState. Page lifecycle stuff seems to really be fueling the MVC craze these days. I wrote a post talking about how ViewState can hurt the performance of your applications if you let it get out of hand. The example I used is the drop down list, but it can certainly get a bit crazy from grids, repeaters, etc. I wrote an article basically saying that you should try to avoid ViewState if you're going to have too much of it. I later followed up with a post about how to use a DropDownList without ViewState. Some people are concerned that you will not be able to use the SelectedValue property, but you can if you wire it up correctly. It is all about understanding that painful Page Lifecycle.

Performance with DropDownLists and ViewState

Using a DropDownList without ViewState

There are plenty of other posts I like in there, but I think I've bored my readers enough for one day. I've got a couple of posts lined up which should be a little bit more interesting than this one, so keep reading. As always, have a great day.

ASP.NET MVC Beta Released

Just in case you missed the blog post from Scott Guthrie yesterday, I will post this.

Scott Guthrie's MVC Beta Announcement

ASP.NET MVC Beta Download

One of my favorite little added bonuses of using IDEs is that I get a lot of helpers that generate code and files for me. If I call a method that doesn't exist I am able to have a stub of the method automatically generated. In the ASP.NET MVC beta they've added a new menu for adding views.

The Add View window it brings looks extremely useful. I look forward to using that to create my views. It handles strongly-typed views and MasterPage selection.

Overall it looks like a nice release.

For those of you who want to deploy using ASP.NET MVC keep in mind that Scott says this in his post.

Today's ASP.NET MVC Beta release comes with an explicit "go-live" license that allows you to deploy it in production environments.  The previous preview releases also allowed go-live deployments, but did so by not denying permission to deploy as opposed to explicitly granting it (which was a common source of confusion).  Today's release is clearer about this in the license.

Good day and enjoy ASP.NET MVC's newest release.

A Note on ASP.NET Session

A while back, I was asked a question by one of the junior developers here at Lake Quincy Media. I had him working on a little feature on an ASP.NET site which could be easily handled using Session. "Where is session stored, on the server or the client?" he asked. As a quick response I said that it's stored on the server. He followed that by saying, "So it doesn't use a cookie?"

And that was all it took to set me on one of my usual lengthy explanations of how a piece of functionality actually works.

How is ASP.NET Session stored?

In ASP.NET, session data is stored on the server. It is stored in a per-user basis and maintained only for a limited period of time. Anyone who has used sessions knows that it is accessed during server-side code execution and is accessed using strings as keys. So we know that Session data is stored as key-value pairs. The following is basically how we access the session information. In this code I store a string in Session and pull it back out from session.

string name = "Brendan Enrick";
Session["fullName"] = name;
string nameFromSession = Session["fullName"] as string;

Pretty simple really. It is a nice way to store data for a user during this visit to the site.

How are users associated with their session?

In the default scenario for ASP.NET Session, cookies are used. No, the data is not stored in the cookie. When a Session is started on the site, the user is given a cookie (yummy cookie) which contains a unique identifier for accessing the session. While the user navigates around the site, the browser sends the cookie information to the server. This is what keeps the user associated with his session. Each time the server receives the cookie from the user so when your code requests data from session, it is pulling the data from the session associated with that user.

Can cookies be avoided?

Yes, it is possible to avoid using cookies. Session is able to run without cookies by setting a boolean property in the web.config file to true. The property is called cookieless and it is on sessionState. When session is not using cookies it instead places the SessionId in the url the user requests. Internal links on the site contain the unique session id so that the processing which occurs on the server is able to access the correct session values. I prefer not using this method because it just makes URLs all over the site look terrible.

How long are values saved in session?

By default the timeout for session in ASP.NET is 20 minutes. This means that the session will expire 20 minutes after the user last accessed the site, so as long as the user continues using the site it will not expire. If the user waits 25 minutes before clicking a link, the session will have expired. It is easy to adjust the length of time before sessions expire. In the web configuration file you can simply adjust the value for timeout on the sessionState element.

<sessionState cookieless="false" timeout="45" />

And this is why asking me questions can be a bit crazy. I'll first go on a lecture about the topic and then eventually I'll publish a blog post so I don't have to lecture again. Now if someone asks me that question I'll send him here.

Using a DropDownList without ViewState

One of the most ViewState heavy controls is the DropDownList. It stores in ViewState the Text and Value for every ListItem in the DropDownList. This means large Lists can get really nasty when ViewState comes into play. They also include all of these entries a second time because they're all in the html. Being in the html will only slow the page down as it is sent to the user, but the ViewState is downloaded by the user and also must be uploaded back up to the web server. This is a horrible user experience if the page has a large amount of ViewState. Since upload speeds are usually worse than download, the user will probably not like the amount of time the postbacks on the site take. In the following example I am going to show how much ViewState can be saved by simply reloading the data into the DropDownList each time the page is requested.

This is how much ViewState my hundred item DropDownList contains at the beginning of this example.

<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwULLTEwNjkzMDQ2Nz
MPZBYCAgMPZBYEAgEPEA8WAh4LXyFEYXRhQm91bmRnZBAVZAlFbGVtZW50IDAJRWxlbWVudCAxCUVsZW1lbnQg
MglFbGVtZW50IDMJRWxlbWVudCA0CUVsZW1lbnQgNQlFbGVtZW50IDYJRWxlbWVudCA3CUVsZW1lbnQgOAlFbG
VtZW50IDkKRWxlbWVudCAxMApFbGVtZW50IDExCkVsZW1lbnQgMTIKRWxlbWVudCAxMwpFbGVtZW50IDE0CkVs
ZW1lbnQgMTUKRWxlbWVudCAxNgpFbGVtZW50IDE3CkVsZW1lbnQgMTgKRWxlbWVudCAxOQpFbGVtZW50IDIwCk
VsZW1lbnQgMjEKRWxlbWVudCAyMgpFbGVtZW50IDIzCkVsZW1lbnQgMjQKRWxlbWVudCAyNQpFbGVtZW50IDI2
CkVsZW1lbnQgMjcKRWxlbWVudCAyOApFbGVtZW50IDI5CkVsZW1lbnQgMzAKRWxlbWVudCAzMQpFbGVtZW50ID
MyCkVsZW1lbnQgMzMKRWxlbWVudCAzNApFbGVtZW50IDM1CkVsZW1lbnQgMzYKRWxlbWVudCAzNwpFbGVtZW50
IDM4CkVsZW1lbnQgMzkKRWxlbWVudCA0MApFbGVtZW50IDQxCkVsZW1lbnQgNDIKRWxlbWVudCA0MwpFbGVtZW
50IDQ0CkVsZW1lbnQgNDUKRWxlbWVudCA0NgpFbGVtZW50IDQ3CkVsZW1lbnQgNDgKRWxlbWVudCA0OQpFbGVt
ZW50IDUwCkVsZW1lbnQgNTEKRWxlbWVudCA1MgpFbGVtZW50IDUzCkVsZW1lbnQgNTQKRWxlbWVudCA1NQpFbG
VtZW50IDU2CkVsZW1lbnQgNTcKRWxlbWVudCA1OApFbGVtZW50IDU5CkVsZW1lbnQgNjAKRWxlbWVudCA2MQpF
bGVtZW50IDYyCkVsZW1lbnQgNjMKRWxlbWVudCA2NApFbGVtZW50IDY1CkVsZW1lbnQgNjYKRWxlbWVudCA2Nw
pFbGVtZW50IDY4CkVsZW1lbnQgNjkKRWxlbWVudCA3MApFbGVtZW50IDcxCkVsZW1lbnQgNzIKRWxlbWVudCA3
MwpFbGVtZW50IDc0CkVsZW1lbnQgNzUKRWxlbWVudCA3NgpFbGVtZW50IDc3CkVsZW1lbnQgNzgKRWxlbWVudC
A3OQpFbGVtZW50IDgwCkVsZW1lbnQgODEKRWxlbWVudCA4MgpFbGVtZW50IDgzCkVsZW1lbnQgODQKRWxlbWVu
dCA4NQpFbGVtZW50IDg2CkVsZW1lbnQgODcKRWxlbWVudCA4OApFbGVtZW50IDg5CkVsZW1lbnQgOTAKRWxlbW
VudCA5MQpFbGVtZW50IDkyCkVsZW1lbnQgOTMKRWxlbWVudCA5NApFbGVtZW50IDk1CkVsZW1lbnQgOTYKRWxl
bWVudCA5NwpFbGVtZW50IDk4CkVsZW1lbnQgOTkVZAlFbGVtZW50IDAJRWxlbWVudCAxCUVsZW1lbnQgMglFbG
VtZW50IDMJRWxlbWVudCA0CUVsZW1lbnQgNQlFbGVtZW50IDYJRWxlbWVudCA3CUVsZW1lbnQgOAlFbGVtZW50
IDkKRWxlbWVudCAxMApFbGVtZW50IDExCkVsZW1lbnQgMTIKRWxlbWVudCAxMwpFbGVtZW50IDE0CkVsZW1lbn
QgMTUKRWxlbWVudCAxNgpFbGVtZW50IDE3CkVsZW1lbnQgMTgKRWxlbWVudCAxOQpFbGVtZW50IDIwCkVsZW1l
bnQgMjEKRWxlbWVudCAyMgpFbGVtZW50IDIzCkVsZW1lbnQgMjQKRWxlbWVudCAyNQpFbGVtZW50IDI2CkVsZW
1lbnQgMjcKRWxlbWVudCAyOApFbGVtZW50IDI5CkVsZW1lbnQgMzAKRWxlbWVudCAzMQpFbGVtZW50IDMyCkVs
ZW1lbnQgMzMKRWxlbWVudCAzNApFbGVtZW50IDM1CkVsZW1lbnQgMzYKRWxlbWVudCAzNwpFbGVtZW50IDM4Ck
VsZW1lbnQgMzkKRWxlbWVudCA0MApFbGVtZW50IDQxCkVsZW1lbnQgNDIKRWxlbWVudCA0MwpFbGVtZW50IDQ0
CkVsZW1lbnQgNDUKRWxlbWVudCA0NgpFbGVtZW50IDQ3CkVsZW1lbnQgNDgKRWxlbWVudCA0OQpFbGVtZW50ID
UwCkVsZW1lbnQgNTEKRWxlbWVudCA1MgpFbGVtZW50IDUzCkVsZW1lbnQgNTQKRWxlbWVudCA1NQpFbGVtZW50
IDU2CkVsZW1lbnQgNTcKRWxlbWVudCA1OApFbGVtZW50IDU5CkVsZW1lbnQgNjAKRWxlbWVudCA2MQpFbGVtZW
50IDYyCkVsZW1lbnQgNjMKRWxlbWVudCA2NApFbGVtZW50IDY1CkVsZW1lbnQgNjYKRWxlbWVudCA2NwpFbGVt
ZW50IDY4CkVsZW1lbnQgNjkKRWxlbWVudCA3MApFbGVtZW50IDcxCkVsZW1lbnQgNzIKRWxlbWVudCA3MwpFbG
VtZW50IDc0CkVsZW1lbnQgNzUKRWxlbWVudCA3NgpFbGVtZW50IDc3CkVsZW1lbnQgNzgKRWxlbWVudCA3OQpF
bGVtZW50IDgwCkVsZW1lbnQgODEKRWxlbWVudCA4MgpFbGVtZW50IDgzCkVsZW1lbnQgODQKRWxlbWVudCA4NQ
pFbGVtZW50IDg2CkVsZW1lbnQgODcKRWxlbWVudCA4OApFbGVtZW50IDg5CkVsZW1lbnQgOTAKRWxlbWVudCA5
MQpFbGVtZW50IDkyCkVsZW1lbnQgOTMKRWxlbWVudCA5NApFbGVtZW50IDk1CkVsZW1lbnQgOTYKRWxlbWVudC
A5NwpFbGVtZW50IDk4CkVsZW1lbnQgOTkUKwNkZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dn
Z2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2
RkAgUPDxYCHgRUZXh0BQlFbGVtZW50IDBkZGQCc/YoLQgXzJamhzzCRizwdOQs9w==" />

And at the end of it, this is all that remains.

<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwULLTEwNjkzMDQ2NzM
PZBYCAgMPZBYCAgUPDxYCHgRUZXh0BQpFbGVtZW50IDIzZGRky26p9Cn4TiZyx2yoBv7mRgWW+gQ=" />

It is a frightening thought, but there are plenty of sites with far more ViewState than this. I am talking some people have talked to me about pages that are multiple megabytes in size.

In the following example I use a simple page with 1 DropDownList, 1 Button, and 1 Label.

Here is the starting Default.aspx page.

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title>Untitled Page</title>
</head>
<body>
    <form id="form1" runat="server">
    <div>
        <asp:DropDownList ID="DropDownList1" runat="server" EnableViewState="true" />
        <asp:Button ID="Button1" runat="server" Text="Postback" />
        <asp:Label ID="Label1" runat="server" />
    </div>
    </form>
</body>
</html>

Here is the starting Default.aspx.cs code-behind file.

using System;
using System.Web.UI.WebControls;

public partial class _Default : System.Web.UI.Page 
{
    protected void Page_Load(object sender, EventArgs e)
    {
        if (!IsPostBack)
        {
            // Create my data source (this would normally be data access or something similar)
            System.Collections.Generic.List<ListItem> myData = new System.Collections.Generic.List<ListItem>();
            for (int i = 0; i < 100; i++)
            {
                myData.Add(new ListItem("Element " + i.ToString(), i.ToString()));
            }
            DropDownList1.DataSource = myData;
            DropDownList1.DataBind();
        }
        else
        {
            Label1.Text = DropDownList1.SelectedValue;
        }
    }
}

Now we can make a little change here. We need to disable ViewState. The other change that we need to make is that we now have to populate the data on every request. We also need to make sure that we populate the DropDownList before Initialization of the Page occurs. This means we should override OnInit and place out code before base.OnInit. The reason we do this is so that we have data loaded in the DropDownList before the selected value of controls are set for us. Otherwise we would have to handle this on our own.

This is the new Default.aspx

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title>Untitled Page</title>
</head>
<body>
    <form id="form1" runat="server">
    <div>
        <asp:DropDownList ID="DropDownList1" runat="server" EnableViewState="false" />
        <asp:Button ID="Button1" runat="server" Text="Postback" />
        <asp:Label ID="Label1" runat="server" />
    </div>
    </form>
</body>
</html>

This is the new Default.aspx.cs

using System;
using System.Web.UI.WebControls;

public partial class _Default : System.Web.UI.Page 
{
    protected override void OnInit(EventArgs e)
    {
        // Create my data source (this would normally be data access or something similar)
        System.Collections.Generic.List<ListItem> myData = new System.Collections.Generic.List<ListItem>();
        for (int i = 0; i < 100; i++)
        {
            myData.Add(new ListItem("Element " + i.ToString(), i.ToString()));
        }
        DropDownList1.DataSource = myData;
        DropDownList1.DataBind();
        base.OnInit(e);
    }

    protected void Page_Load(object sender, EventArgs e)
    {
        if (IsPostBack)
        {
            Label1.Text = DropDownList1.SelectedValue;
        }
    }
}

Enjoy not having TONS of extra ViewState. Remember that ViewState is extremely useful, but can cause problems if you ignore its existence completely. It can lead to huge pages that are quite slow.

Passing ViewData to User Controls in ASP.NET MVC Preview 4

Yesterday I was upgrading an ASP.NET MVC site from Preview 2 to Preview 4. For the most part this is an easy process. Some assemblies needed to be updated and some information updated in the web.config file. Route declaration changed, but the same information is still required, so updating that was pretty easy. The released documentation and examples clearly show these changes. I also had to make the change to my controller actions so that they return ActionResults instead of being void methods. Again, this is a fairly simple task.

There was an adjustment to user controls which caused some problems though. Yasir and I were working on this task together so we could both learn about the preview 4 changes in MVC. We scoured articles looking for this information, and we tried many different changes to the user control.

Our problem was that we could not get access to the ViewData. ViewData in the user control was always null. It was quite annoying. Eventually in desperation after reading articles and release notes and not finding what we were looking for, we started reading the source code for MVC. We took a look at this file, which is the one containing the extension method we were calling in the .aspx files. System.Web.Mvc.UserControlExtensions This file contains the extension method RenderUserControl, which our code used.

The .aspx code we were using

<%
   =Html.RenderUserControl("~/Views/Shared/MyUserControl.ascx", ViewData, new { DisplayTitle = "Hello World!" }) 
%>

RenderUserControl calls this method called DoRendering

private static string DoRendering(ViewUserControl instance, ViewContext context, object controlData, object propertySettings) {
            ViewPage dummyPage = new ViewPage();
            dummyPage.ViewContext = context;
            dummyPage.Controls.Add(instance);
            dummyPage.InitHelpers();

            //set the properties

            SetUserControlProperties(instance, propertySettings);

            if (controlData != null) {
                instance.ViewData.Model = controlData;
            }
            else {
                instance.ViewData = context.ViewData;
            }

            //Render it

            string result = HtmlExtensionUtility.RenderPage(dummyPage);

            return result;
        }

In my haste to find a solution, I didn't read the code very carefully. All I noticed was exactly how to solve our problem. I discovered that the controlData parameter we were passing to this method was being assigned into instance.ViewData.Model. I didn't even read the next couple of lines which gave away the real answer. We went and added in the .Model to our code so that it could access the ViewData. The ViewData we were passing was going into a property of the ViewData called Model, so we just used it. We went to our user control and we changed the code there. This felt really bad to us, but we went along with it.

Today I realized our error. I was thinking about the code we had looked at this morning, and I realized our mistake. I was wondering, "Why was it checking if control data was null? If it was null shouldn't ViewData.Model be null? That's our ViewData right?" That is when I realized what must have been after that.

We were not supposed to be using Model. We had some standard ViewData. No strongly-typed ViewData was being used. We were using an the standard ViewDataDictionary object and passing it to the user control. A ViewUserControl object (which is the class we were inheriting from) supports generics. It was at that time when I realized exactly what everything was being used for. The Model property and the controlData parameter are there for strongly typed ViewData. You can use boxing and unboxing or generics to pass strongly-typed data to your ViewControl. The parameter and the generic Model were added so that the ViewData property of the ViewUserControl would not be interfered with.

This solution the MVC guys use allows custom ViewData to be used without having to muck the ViewData property of the user controls. Since they added this extra piece it could be the generic one. So now I have gone and changed my code. I no longer pass the ViewData as was done in the past. It is now simply grabbed from the context of the page. I pass a null value instead of passing in any controlData to the RenderUserControl method. It wires everything up for me now.

<%=Html.RenderUserControl("~/Views/Shared/MyUserControl.ascx", null, new { DisplayTitle = "Hello World!" })%>

As a reminder to everyone. Open source code means that you can go look at the code. If you are not sure how something works, just go read the code. It is freely available on CodePlex. You can look at how everything is working and get a much better understanding of the inner workings of the technology.

Handling Password Recovery

I recently answered a blog post about how to handle password recovery in ASP.NET. My first thoughts when I read this questions are along the lines of, "Ah! Don't recover passwords!"

With any authentication system it is important to remember this one thing passwords should always be hashed. I don't care who you are or what system you're using, you should never ever have passwords stored in your system which are not at least encrypted in some format. In ASP.NET you want to use hashing. Being able to "recover" a password implies that the password is in a form that you could make it user-readable.

This is bad since it means that if someone managed to obtain your password data they could potentially obtain people's passwords. Considering that lots of users will use the same password in multiple places, that could be very bad.

What you need to do instead of recovering a password is to reset a user's password. They can then log in using the new password and change it to the one they want. This allows you to keep their password secure and to still allow them to recover from the issue. It just makes it a little bit more complicated for the user, but having the extra security is by far worth it. Most users will agree with you on this.

As a user I am quite upset when a site is able to "recover" my password. I am annoyed by the password policies of quite a few sites on the Internet. I've had sites limit the length of my passwords, limit the types of characters I may use, and many other sometimes asinine things.

Just always use password resets. It just makes things a little bit safer for your users. They'll be thanking you for it even if they don't actually express it to you.

Here you can read about ASP.NET Password Recovery. I just recommend you use hashed passwords and only allow password reset and not password retrieval.

Web Application Projects are better than Web Sites

Recently I was explaining the difference between the web application project and the web site to the budding developers I've been working with. I suffered greatly while using web sites instead of web application projects. I remember having a great deal of pain while my assemblies dueled each other. Scott Guthrie posted about the dueling assembly problem.

Dueling Assembly Reference Problem

The problem I refer to as a “dueling reference” occurs when you setup multiple file-based references to assemblies from a VS 2005 Web Site Project that are each updated dynamically (using .refresh files), and which in turn have dependencies on different versions of a common shared assembly library.

This one reason was more than enough in my opinion to switch to web application. It took some sites which could take upwards of five to ten minutes to compile and made them take ten seconds. I can't ask for much better improvement there.

Another great benefit of using Web Application Projects instead of using the Web Site is that there is a project file managing what is and is not included. On a few of the projects I've worked on in the past we have had some trouble with source control and web sites. It is much easier if you can just define what is and is not included in the web site. With the classic web sites, it was a loose system. The site was defined as a folder in the file system. With the web application project your site is defined using a project file which dictates which files will and will not be included.

On really annoying part of web sites are the refresh files used for adding assemblies into the bin folder. There are files which say where the assembly can be obtained. If you're working with source control you need to have these files in source control. The problem is that you need to not have the actual binaries in that location in source control or the refresh files will not work correctly. This creates some huge headaches because Visual Studio wants to check in these files (assemblies) being included by the refresh files. Ouch.

The feel of web applications is more consistent with everything else in Visual Studio. This consistency is nice, since there now is "Open Web Site" and "Open Project". It is quite annoying to have two different things to work with. If they were both just project that would make it so much simpler.

Far too many people are still using the sites, so I doubt that Microsoft will remove them from future versions of Visual Studio anytime soon. It doesn't really hurt me to have them, but I pretty much exclusively use Web Application Projects over Web Sites. I even do this for small little one shot sites. I've just grown to like them so much that I cannot turn back.

If I have to deal with refresh files again, I'll just go crazy.

Generic Recursive Find Control Extension

Earlier today I posted about a Recursive Find Control Extension Method. Since then, I was informed by Steve Smith that I should check out the generic find control method which Aaron Robson has on his blog. He has some pretty nice methods there, so I just adapted them to be extension methods now. As extension methods the code looks like this.

/// <summary>
/// Similar to Control.FindControl, but recurses through child controls.
/// </summary>
public static T FindControl<T>(this Control startingControl, string id) where T : Control
{
    T found = startingControl.FindControl(id) as T;
 
    if (found == null)
    {
        found = FindChildControl<T>(startingControl, id);
    }
 
    return found;
}
 
/// <summary>     
/// Similar to Control.FindControl, but recurses through child controls.
/// Assumes that startingControl is NOT the control you are searching for.
/// </summary>
public static T FindChildControl<T>(this Control startingControl, string id) where T : Control
{
    T found = null;
 
    foreach (Control activeControl in startingControl.Controls)
    {
        found = activeControl as T;
 
        if (found == null || (string.Compare(id, found.ID, true) != 0))
        {
            found = FindChildControl<T>(activeControl, id);
        }
 
        if (found != null)
        {
            break;
        }
    }
 
    return found;
}

And this new extension method is called very similarly to how we called the previous code. It is called using the following code.

Label theOtherLabel = LoginView1.FindControl<Label>("OtherControlToFind");
if (theOtherLabel != null)
{
    theOtherLabel.Text = "Found this one also!";
}

It is able to find the Label inside of the the following LoginView.

<asp:LoginView ID="LoginView1" runat="server">
    <LoggedInTemplate>
        <asp:Panel ID="Panel1" runat="server">
            <asp:Panel ID="Panel2" runat="server">
                <asp:Panel ID="Panel3" runat="server">
                    <asp:Panel ID="Panel4" runat="server">
                        <asp:Panel ID="Panel5" runat="server">
                            <asp:Label ID="ControlToFind" runat="server" Style="color: Red" />
                            <asp:Label ID="OtherControlToFind" runat="server" Style="color: Blue" />
                            <asp:Label ID="AlwaysShow" runat="server" Text="This shows no matter what." />
                        </asp:Panel>
                    </asp:Panel>
                </asp:Panel>
            </asp:Panel>
        </asp:Panel>
    </LoggedInTemplate>
</asp:LoginView>

I've also updated my FindControl method so that is just an overload of the previous method. Since my extension method takes the same parameters and returns the same type as the existing find control method I needed to rename it FindControlR. I've now updated it so it takes an extra parameter, but doesn't have a different name. I've added a boolean "recurse" parameter. If this is set to false it just calls the standard FindControl method and if it is set to true it will recursively call itself finding the desired control.

This is the final product followed by how one would call it.

/// <summary>
/// Searches recursively in this control to find a control with the name specified.
/// </summary>
/// <param name="root">The Control in which to begin searching.</param>
/// <param name="id">The ID of the control to be found.</param>
/// <returns>The control if it is found or null if it is not.</returns>
public static Control FindControl(this Control root, string id, bool recurse)
{
    if (!recurse)
    {
        return root.FindControl(id);
    }
    System.Web.UI.Control controlFound; 
    if (root != null) 
    { 
        controlFound = root.FindControl(id);
        if (controlFound != null)
        {
            return controlFound;
        }
        foreach (Control c in root.Controls) 
        {
            controlFound = c.FindControl(id, true);
            if (controlFound != null)
            {
                return controlFound;
            }
        } 
    } 
    return null;
}
Label theLabel = LoginView1.FindControl("ControlToFind", true) as Label;
if (theLabel != null)
{
    theLabel.Text = "Found it!";
}

I hope everyone else sees the great value in extension methods.

Creating a Recursive FindControl Extension Method

So one of the most useful methods for ASP.NET development that never seems to be included in ASP.NET is a recursive find control method. This problem results from the standard FindControl method on controls only searching within that control. It only finds child controls not grandchildren or anything farther down the line. This means that anything nested within other controls is a pain to access.

This limitation of the standard FindControl is annoying and has prompted me as well as many other people to use homegrown FindControl methods to solve this problem. This is a big problem when trying to programmatically access controls within templates. So earlier today I read on a list someone having trouble with the built-in find control, and it made me thing that a recursive find control would make a great extension method since it is a method plenty of people want to see on the control class anyway. So I went and wrote this simple little extension method.

For this nifty example I'll use this as my Page class. I've nested some Panels here to make sure that a standard find control would not work.

<form id="form1" runat="server">
<div>
    <asp:Panel ID="Panel1" runat="server">
        <asp:Panel ID="Panel2" runat="server">
            <asp:Panel ID="Panel3" runat="server">
                <asp:Panel ID="Panel4" runat="server">
                    <asp:Panel ID="Panel5" runat="server">
                        <asp:Label ID="ControlToFind" runat="server" />
                    </asp:Panel>
                </asp:Panel>
            </asp:Panel>
        </asp:Panel>
    </asp:Panel>
</div>
</form>

Now you'll see here in the code behind I am calling my recursive find control extension method. Notice that I am checking for null afterwards. This is because if I do not find the control my method returns null, so I should check for this. Also because I am using the as statement if the control is not a label my variable will also be null.

protected void Page_Load(object sender, EventArgs e)
{
    Label theLabel = form1.FindControlR("ControlToFind") as Label;
    if (theLabel != null)
    {
        theLabel.Text = "Found it!";
    }
}

Here is the code which makes this cool extension method possible.

public static class Extensions
{
    /// <summary>
    /// Searches recursively in this control to find a control with the name specified.
    /// </summary>
    /// <param name="root">The Control in which to begin searching.</param>
    /// <param name="id">The ID of the control to be found.</param>
    /// <returns>The control if it is found or null if it is not.</returns>
    public static Control FindControlR(this Control root, string id)
    {
        System.Web.UI.Control controlFound; 
        if (root != null) 
        { 
            controlFound = root.FindControl(id);
            if (controlFound != null)
            {
                return controlFound;
            }
            foreach (Control c in root.Controls) 
            {
                controlFound = c.FindControlR(id);
                if (controlFound != null)
                {
                    return controlFound;
                }
            } 
        } 
        return null;
    }
}

To create an extension method all I need to do is create a static method in a static class and pass as a parameter "this Type name" where Type and name are the type we wish to extend and name is a local variable name for the instance with which we wish to interact.

One thing I don't see in many examples of extension methods which I have used here is passing a parameter in the extension method. It really is this simple to pass the extra parameter.

This syntax reminds me a lot of the python language whose non-static class methods accept "this" as a parameter. It defines them as taking the instance as a parameter.

Have a great day!

Performance with DropDownLists and ViewState

DropDownList-HornsOne problem I've noticed on a bunch of sites is a large amount of ViewState. I'm not going to sit here and explain all about ViewState. There are PLENTY of sources for information on that piece of technology. So in an extremely short description of what ViewState is I will say that, "ViewState is a way of preserving the state of the 'Viewed' elements of ASP.NET while the page is sent to the client and back to the server."

So what is the big deal? A little bit of extra information stored in a text file. That doesn't take long to download. Download speeds are really quick. WRONG! Sure, it does not take long to download a little bit of extra data, but ViewState is stored in an input control. This is how the data is able to get back to the server so it can reconstruct the previous state of things. This means clients will push the data up to the server. As many of you probably know upload speeds are much slower than download speeds.

OK, so I need to upload a little bit of extra data. How much are we talking about here? It can't be enough to matter.

I'll show you a bit of testing here. I'll create two ASP.NET pages.

Default.aspx

<form id="form1" runat="server">
    <div>
        <asp:DropDownList ID="DropDownList1" runat="server" />
        <asp:Button id="Button1" runat="server" Text="Postback" />
    </div>
</form>

Default2.aspx

<form id="form1" runat="server">
    <div>
        <asp:DropDownList ID="DropDownList1" runat="server" EnableViewState="false" />
        <asp:Button ID="Button1" runat="server" Text="Postback" />
    </div>
</form>

Default.aspx.cs

protected void Page_Load(object sender, EventArgs e)
{
    // Create my data source (this would normally be data access or something similar)
    System.Collections.Generic.List<ListItem> myData = new System.Collections.Generic.List<ListItem>();
    for (int i = 0; i < 100; i++)
    {
        myData.Add(new ListItem("Element " + i.ToString(), i.ToString()));
    }
    DropDownList1.DataSource = myData;
    DropDownList1.DataBind();
}

Default2.aspx.cs

protected override void OnInit(EventArgs e)
{
    base.OnInit(e);
    // Create my data source (this would normally be data access or something similar)
    System.Collections.Generic.List<ListItem> myData = new System.Collections.Generic.List<ListItem>();
    for (int i = 0; i < 100; i++)
    {
        myData.Add(new ListItem("Element " + i.ToString(), i.ToString()));
    }
    DropDownList1.DataSource = myData;
    DropDownList1.DataBind();
}

Note: When you disable ViewState you'll want to be binding data to the control during Init otherwise you'll run into some problems, because you'll be binding your data after ViewState has been restored.

These are the only differences between the two pages. So how much of a difference is there? The the amount of data being used for ViewState for the page with ViewState enabled on the DropDownList is 3.07 KB and for the page without ViewState enabled on the DropDownList 52 Bytes. Ok so not too big a deal right? Well imagine if you had a few of these on the page, and maybe the page posts back more than once while being used. Perhaps the hosting server is already somewhat slow. Perhaps you have users on dialup. Keep in mind that if you're setting values from the code for most controls it will end up in viewstate.

Note: Basic form controls will not be using ViewState since they post their values back anyway.

Grab a ViewState Decoder. I use the ViewStateDecoder from Pluralsight. If you use a tool to Decode the ViewState from these pages, you'll notice that the values from the dropdownlist are stored within. It will contain 3 things for each row of the dropdownlist. You'll have the Name of the list item, the value of the list item, and a bool. In total 2 strings and a bit, but since ViewState is all strings anyway this is all stored in a string format.

The spark that formed this blog post. I recently took on some pages with far too much viewstate. They had plenty of stuff on them and none of it had ViewState disabled. I took a page that had html source of 256 KB of data, and I dropped it down to 190 KB of data. It started with 74 KB of ViewState (ouch!) and now has 8 KB of ViewState (w00t!). The page is much much faster. It loads instantly now and when it does a postback it doesn't feel like the application is dying. All it took was removing ViewState from a bunch of controls.