As I noted in my previous post, I recently discovered that my approach for building Web Solution Packages (WSPs) in Microsoft Office SharePoint Server (MOSS) 2007 isn't compatible with Team Foundation Build.

I'm actually a little embarrassed to say this, but when I created the original "DR.DADA" approach for MOSS 2007 development back on the Agilent Technologies project, we were using Visual SourceSafe -- not Team Foundation Server (TFS) -- and a "manual" build process.

I'd used VSS and automated builds on other projects before (using NAnt), but never got around to automating our MOSS 2007 builds on the Agilent project because, honestly, there were just too many other higher priority items. Besides, each build only required a couple of minutes of actual human effort because most of the build was scripted.

Still, an automated daily build (and deployment to DEV) is a really, really good thing to have.

I've been fortunate to be on a few projects since then that have leveraged TFS.

However, up until about a month ago, I hadn't used Team Foundation Build (outside of the Jameson Datacenter, of course) due to the fact that we are leveraging the extranet TFS instance hosted by Microsoft.

Note that Microsoft IT makes it very easy for us to provision new TFS projects on either the extranet or one of several internal TFS instances. Configuring builds using Team Foundation Build on one of the intranet TFS instances is very easy (from what I hear), but I strongly prefer working off the extranet TFS instance because then I don't have to VPN into CorpNet in order to have access to source control.

However, choosing the extranet TFS instance also means we can't configure builds using the out-of-the-box functionality in Team Foundation Server (at least not without setting up a build server on the extranet). Fortunately, I've found a way to schedule "manual" builds that look a lot like automated builds performed using Team Foundation Build.

So, if you are building SharePoint WSPs -- regardless of whether you use the real Team Foundation Build or my "imitation Team Foundation Build" -- you need a way to build the WSPs without referring to referenced assemblies using relative paths.

As I first mentioned in my previous post, relative paths work just fine when compiling from within Visual Studio or using MSBuild from the command line. However, they don't work at all when queuing the builds through Team Foundation Build.

The problem with relative paths is that Team Foundation Build uses a different folder structure when compiling your projects. Specifically, it changes the output folder for all compiled items to be under a new Binaries folder -- not the location specified in the project settings within Visual Studio.

In other words, if you refer to a referenced assembly using something like:

..\..\..\CoreServices\bin\%BUILD_CONFIGURATION%\Fabrikam.Demo.CoreServices.dll

then you will find that this works just fine when building through Visual Studio -- or even when compiling using TFSBuild.proj from the command line (a.k.a. a "Desktop Build"). However, if you then queue the build through Team Foundation Server, you'll find your build fails because the referenced assembly was actually output to a different folder.

If you dive into the log file for the build, you will find that Team Foundation Build modifies the OutDir variable and sets it to something like:

C:\Users\svc-build\AppData\Local\Temp\Demo\Daily Build - Main\Binaries\Debug\

So the trick to building WSPs with Team Foundation Build is to leverage the OutDir variable instead of relying on relative paths to referenced assemblies.

Here is the updated DDF file based on my earlier sample:

;
; This ddf specifies the structure of the .wsp solution cab file.
;
; HACK: OPTION EXPLICIT cannot be used when specifying a variable with the /D option,
; otherwise MakeCAB aborts with an error similar to the following:
;
;        ERROR: Option Explicit and variable not defined: OUT_DIR
;
;.OPTION EXPLICIT    ; Generate errors for undefined variables

.Set CabinetNameTemplate=Fabrikam.Demo.Publishing.wsp

; The following variable must be set when calling MakeCAB (using the /D option)
;.Define OUT_DIR=

.Set DiskDirectoryTemplate=CDROM    ; All cabinets go in a single directory
.Set CompressionType=MSZIP            ; All files are compressed in cabinet files
.Set UniqueFiles=ON
.Set Cabinet=ON
.Set DiskDirectory1=%OUT_DIR%\Package

DeploymentFiles\PackageFiles\manifest.xml

.Set SourceDir=%OUT_DIR%            ; Copy assemblies from %OUT_DIR% folder

Fabrikam.Demo.Publishing.dll
Fabrikam.Demo.CoreServices.dll

.Set SourceDir=                    ; Copy files relative to project folder

.Set DestinationDir=Fabrikam.Demo.Publishing.DefaultSiteConfiguration
DefaultSiteConfiguration\FeatureFiles\Feature.xml

.Set DestinationDir=Fabrikam.Demo.Publishing.Layouts
Layouts\FeatureFiles\Feature.xml
Layouts\FeatureFiles\ProvisionedFiles.xml

.Set DestinationDir=Fabrikam.Demo.Publishing.Layouts\MasterPages
Layouts\MasterPages\FabrikamMinimal.master

;.Set DestinationDir=Fabrikam.Demo.Publishing.Layouts\PageLayouts
;Layouts\PageLayouts\MinimalPage.aspx

.Set DestinationDir=Fabrikam.Demo.Publishing.Layouts\Images
Layouts\Images\FabrikamLogo_32x32.png

.Set DestinationDir=Fabrikam.Demo.Publishing.Layouts\Themes\Theme1
Layouts\Themes\Theme1\BreadcrumbBullet.gif
Layouts\Themes\Theme1\FauxColumn-Fixed-2Col.png
Layouts\Themes\Theme1\FauxColumn-Fixed-3Col.png
Layouts\Themes\Theme1\Fabrikam-Basic.css
Layouts\Themes\Theme1\Fabrikam-Core.css
Layouts\Themes\Theme1\Fabrikam-FixedLayout.css
Layouts\Themes\Theme1\Fabrikam-IE.css
Layouts\Themes\Theme1\Fabrikam-IE6.css
Layouts\Themes\Theme1\Fabrikam-QuirksMode.css
Layouts\Themes\Theme1\Tab-LeftSide.jpg
Layouts\Themes\Theme1\Tab-RightSide.jpg

.Set DestinationDir=ControlTemplates\Fabrikam\Demo\Publishing\Layouts
Layouts\Web\UI\WebControls\GlobalNavigation.ascx
Layouts\Web\UI\WebControls\StyleDeclarations.ascx

.Set DestinationDir=Layouts\Fabrikam
Layouts\MasterPages\FabrikamMinimal.master

Note how I've replaced the BUILD_CONFIGURATION variable with the OUT_DIR variable. Not surprisingly, the OUT_DIR variable in the DDF is specified similar to how BUILD_CONFIGURATION was previously specified when calling makecab.exe. However, unlike the build configuration the OutDir variable will likely contain spaces as well as a trailing slash (which makecab.exe apparently doesn't like). Therefore we must quote the OutDir variable and append with "." if a trailing slash is found.

Here is the corresponding update to the project file:

  <PropertyGroup>
    <BuildDependsOn>
      $(BuildDependsOn);
      CreateSharePointSolutionPackage
    </BuildDependsOn>
    <QuotedOutDir>"$(OutDir)"</QuotedOutDir>
    <QuotedOutDir Condition="HasTrailingSlash($(OutDir))">"$(OutDir)."</QuotedOutDir>
  </PropertyGroup>
  <Target Name="CreateSharePointSolutionPackage" Inputs="@(None);@(Content);$(OutDir)$(TargetFileName);" Outputs="$(ProjectDir)$(OutDir)Package\Fabrikam.Demo.Publishing.wsp">
    <Message Text="Creating SharePoint solution package..." />
    <Exec Command="makecab /D OUT_DIR=$(QuotedOutDir) /F &quot;$(ProjectDir)DeploymentFiles\PackageFiles\wsp_structure.ddf&quot;" />
  </Target>

With these changes, the SharePoint WSP is successfully built regardless of whether it is compiled through Visual Studio, from the command line using MSBuild and the TFSBuild.proj file, or as an automated build using a Team Foundation Build server.

I added another tool to my Toolbox yesterday: SketchPath.

The SketchPath site labels it as "The XPath Tool" but I'd say it more like "The XPath Tool."

I've seen a few other tools for quickly building and testing XPath expressions against an XML document, but they pale in comparison to SketchPath. There are a number of online tools that unquestionably require less effort to get started with, but you'll likely find them very limiting as well.

I know I'm not the only one who thinks SketchPath rocks. Scott Hanselman included it in his 2009 Ultimate Developer and Power Users Tool List for Windows.

If you do any significant amount of work with XML, I recommend you download SketchPath today.

If you are using Basic Authentication or Forms-Based Authentication (FBA) with Microsoft Office SharePoint Server (MOSS) 2007 -- or any Web site, for that matter -- then you must configure secure communication (HTTPS) using SSL certificates.

However, you probably didn't select to enable SSL when you originally created your Web application (after all, you most likely don't want to use Basic Auth or FBA exclusively, but rather only for users accessing the site externally). If you followed the process I recommend for customers deploying MOSS solutions, you created the Web application using an intranet URL (e.g. http://fabrikam) and subsequently extended the Web application to the Internet zone (e.g. http://www.fabrikam.com) or Extranet zone (e.g. http://extranet.fabrikam.com) -- utilizing the SharePoint alternate access mappings feature.

Now that you need to enable secure communication, you might once again consider extending the Web application -- say to the Custom zone -- and select the option to use SSL (e.g. https://www.fabrikam.com). After all, this is the recommendation in the following TechNet article:

Specifically, here is the text that I am referring to:

We do not recommend reusing the same IIS Web site for your HTTP and SSL hosting. Instead, extend a dedicated HTTP and a dedicated SSL Web site, each assigned to its own alternate access mapping zone and URLs.

Wait a minute...let me see if I've got this right...you want me to extend my Web application -- thereby creating yet another copy of my Web.config files -- just to enable SSL? That doesn't seem like a good idea.

After all, managing the multitude of Web.config files across multiple Web application and Web servers in a farm seems to be one of the most challenging aspects for the Release Management and Operations teams (at least in my experience during the past several years). [I can't tell you how many times I've compared Web.config files during the process of troubleshooting various issues and found discrepancies due to manual changes not getting applied consistently. Sure, the risk of this is drastically reduced if you leverage the SPWebConfigModification infrastructure, but there are still rare occasions when a little manual "tweaking" is necessary -- and these often lead to inconsistent Web.config files.]

Therefore, one of my goals with any SharePoint solution is to minimize the number of Web.config files that are used. It seems reasonable to expect two different Web.config files to be used for a site that uses Windows Authentication internally and Forms Authentication externally, since this is configured using the <authentication> element.

For example, in the Default zone you probably want to specify:

    <authentication mode="Windows" />

Whereas in the Internet zone you instead need something like this:

    <authentication mode="Forms">
      <forms loginUrl="/Public/Pages/default.aspx" defaultUrl="/" />
    </authentication>

Okay, so if we want to avoid creating a new Web application -- and the corresponding Web.config file(s) -- how can we support both HTTP and HTTPS on the same Web application? It turns out to be rather simple.

For a starting point, let's assume you've just created your Web application using the default (i.e. intranet) URL -- say, http://fabrikam -- which uses Windows Authentication. This is the site that your content authors will use to manage the site.

The first step is to create an alternate access mapping (AAM).

To configure an alternate access mapping:

1. On the SharePoint Central Administration home page, click the Application Management tab on the top link bar.
2.  On the Application Management page, in the SharePoint Web Application Management section, click Create or extend Web application.
3. On the Create or Extend Web Application page, in the Adding a SharePoint Web Application section, click Extend an existing Web application.
4.  On the Extend Web Application to Another IIS Web Site page:
   1. In the Web Application section, select the Web application to extend (e.g. http://fabrikam).
   2. In the IIS Web Site section, in the Port and Host Header boxes, enter the corresponding values such as 80 and www.fabrikam.com, respectively.
   3. In the Security Configuration section, keep the default options (you can configure forms authentication, anonymous access, and SSL later).
   4. In the Load Balanced URL section, ensure the default value specified in the URL box is correct (e.g. http://www.fabrikam.com:80) and in Zone dropdown list, select Internet.
   5. Click OK.
      

The next step is to install your SSL certificate on the site. Once you've procured your certificate and installed it through Internet Information Services (IIS) Manager, you then need to add a public URL in SharePoint for HTTPS and add an HTTPS binding in IIS.

To add a public URL to HTTPS:

1.  On the SharePoint Central Administration home page, click the Operations tab on the top link bar.
2.  On the Operations page, in the Global Configuration section, click Alternate access mappings.
3.  On the Alternate Access Mappings page, click Edit Public URLs.
4.  On the Edit Public Zone URLs page:
   1. In the Alternate Access Mapping Collection section, select the Web application (e.g. http://fabrikam).
   2. In the Public URLs section, copy the URL from the Internet box to the Custom box, and change http:// to https://.
   3. Click Save.

To add an HTTPS binding to the site in IIS:

1. Click Start, point to Administrative Tools, and then click Internet Information Services (IIS) Manager.
2. In Internet Information Services (IIS) Manager, click the plus sign (+) next to the server name that contains the Web application, and then click the plus sign next to Sites to view the Web applications that have been created.
3. Click the name of the Web application corresponding to the Internet zone (e.g. SharePoint – www.fabrikam.com80). In the Actions section, under the Edit Site heading, click Bindings….
4. In the Site Bindings window, click Add.
5. In the Add Site Binding window:
   1. In the Type: dropdown, select https.
   2. In the SSL Certificate: dropdown, select the certificate corresponding to the site (e.g. www.fabrikam.com).
   3. Click OK.
   4. In the Site Bindings window, click Close.

At this point, your SharePoint site supports Windows Authentication both internally (via http://fabrikam) and externally (via http://www.fabrikam.com and https://www.fabrikam.com). The final steps are to enable anonymous access and configure Forms Authentication.

Note that after configuring Forms Authentication, users will not automatically be redirected from HTTP to HTTPS for the login page. To achieve this user experience, I've used a couple of techniques in the past that are based on the same fundmental concept. The first technique utilized code on the login page to automatically detect HTTP connections and redirect to HTTPS. The second technique was essentially the same logic, but rather than utilizing code embedded in the login page, it is encapsulated in a Login Form Web Part. I'll discuss this redirect code in a follow-up post.

I recently promised to finish this blog post that has been sitting in "unpublished" status since June 2008, so here it is...

Have you ever encountered the following error in Microsoft Office SharePoint Server (MOSS) 2007?

An error occurred during the processing of . The attribute 'autoeventwireup' is not allowed in this page.

I just searched for this using Bing and it seems like I'm not the only one who has ever experienced this issue. However, glancing through a few of the top search results, I didn't see any solutions to the error.

The problem occurs when you have a custom master page which includes code and that master page subsequently becomes unghosted. I believe this happens with custom page layouts that are customized as well.

I have to admit that I was completely stumped when I first encountered this error a few years ago while working on the Agilent Technologies project. I eventually tracked down the root cause to be unghosted pages, but we were not using SharePoint Designer to create or customize our master pages, so I couldn't understand why we would occasionally encounter this error.

My speculation is that when the feature/solution containing the custom master page is deactivated, retracted, and deleted (as part of the "DR.DADA" process), SharePoint has some "smarts" within it that essentially equates to:

• Hey, this master page (or page layout) is currently in use so removing it could really break the site.
• Therefore, I'd better make a copy of it and store it in the database (i.e. unghost it).

Unfortunately, when we subsequently added, deployed, and activated the solution/feature, SharePoint would still attempt to use the unghosted master page and summarily generate the error stating that "the attribute 'autoeventwireup' is not allowed in this page."

Note that this is pure speculation on my part as to what was causing the master page to become unghosted.

However, what I do know for sure is that once I reghosted the master page, the AutoEventWireup error would magically disappear.

Here are the steps to reghost a master page or page layout:

1. Browse to Site Settings page for your site. Note that if your master page is causing the AutoEventWireup error, you can explicitly specify the URL (e.g. http://fabrikam/_layouts/settings.aspx).
2. On the Site Settings page, under the Look and Feel section, click Reset to site definition.
3. On the Reset Page to Site Definition Version page:
   1. In the Reset to Site Definition section, ensure the option to Reset specific page to site definition version is selected, and then in the Local URL of the page box, typtype the URL of the master page or page layout that you want reset (e.g. http://fabrikam/_catalogs/masterpage/FabrikamMinimal.master).
   2. Click Reset.
   3. In the confirmation dialog that appears stating that you will lose all customizations, including web part zones, custom controls, and in-line text, click OK.

Note that in ASP.NET, the default value for the AutoEventWireup attribute is true. Therefore you might assume that you could simply remove the attribute from your custom master page in order to avoid the error when the master page is unghosted. After all, the error clearly states that the AutoEventWireup attribute is not allowed in this page, right?

In other words, the solution to the problem would seem to be simply be a matter of changing something like this...

<%@ Master Language="C#" AutoEventWireup="true" Codebehind="FabrikamMinimal.master.cs"
    Inherits="Fabrikam.Demo.Publishing.Layouts.MasterPages.FabrikamMinimal" %>

...to this:

<%@ Master Language="C#" Codebehind="FabrikamMinimal.master.cs"
    Inherits="Fabrikam.Demo.Publishing.Layouts.MasterPages.FabrikamMinimal" %>

Unfortunately -- at least in my experience -- this doesn't work. It only leads to other errors, such as:

The event handler 'OnPreRender' is not allowed in this page.

The above error occurs when the master page contains something like the following:

            <asp:SiteMapPath ID="BreadcrumbSiteMapPath" Runat="server"
                SiteMapProvider="CurrentNavSiteMapProviderNoEncode"
                RenderCurrentNodeAsLink="true"
                SkipLinkText=""
                OnPreRender="BreadcrumbSiteMapPath_OnPreRender">

I attempted to resolve this by converting the BreadcrumbSiteMapPath_OnPreRender event handler to a method and invoking the method from the Page_PreRender event handler instead. However, that only led to yet another error:

Code blocks are not allowed in this file.

Sensing a very deep "rat hole" at this point, I decided it wasn't worth pursuing this issue any further.

Fortunately, as I've stated before, I don't believe master pages and page layouts deployed through solutions and features should subsequently be customized through SharePoint Designer. In my opinion, these items should be tightly managed through your SCM (software configuration management) process -- in other words, versioned in your source control system and subsequently deployed through a formal change process.

Of course, if your custom master pages and page layouts are very simple (i.e. no code-behind) then you probably will never encounter this problem.

I started using Password Minder almost immediately after reading about it in the July 2004 edition of MSDN Magazine. I don't know about you, but trying to remember all of my various passwords for dozens of Web sites, numerous network accounts, VMs, etc. is really quite a nightmare. [I'm actually a little embarrassed to say that on more than one occasion I've had to hack one of my VMs in order to reset the password for a domain admin. This process definitely isn't for the faint of heart, but it was better than having to rebuild my FABRIKAM domain from scratch.]

Instead I tend to use no more than three or four passwords that I can remember (and change every couple of months) and a whole bunch of randomly generated passwords that I rely on Password Minder to store securely.

Note that all of the service accounts used in the "Jameson Datacenter" (a.k.a. my home lab) use random 20 character passwords.

Hence, why I added Password Minder to my Toolbox years ago. [Thanks to Keith Brown for sharing this wonderful utility, as well as take the time to write about the internals of how it works.]

However, there were a few problems I had with the original Password Minder.

First, it didn't like the fact that my Documents folder is redirected to a server. In other words, my encrypted password file is:

\\BEAST\Users$\jjameson\Documents\My Passwords.xml

Consequently, I encountered the following error when trying to save my password file:

Failed to save the password file. Here are the gory details:

GetVolumeInformation failed:
The filename, directory name, or volume label syntax is incorrect.

I discovered that I could avoid this error by clearing the Let Password Minder control the DACL checkbox in the Password Minder Options dialog window.

The next problem that I encountered was Password Minder throwing up on me (in other words, generating an unhandled IndexOutOfRangeException) when one of my passwords somehow ended up being an empty string (to this day I'm still not sure how that empty password managed to get saved to the file).

Thus I made a small change to line 381 of CryptMaster.cs. The original code was:

            if (null == record.EncryptedUserId) {

I changed this to:

            if (string.IsNullOrEmpty(record.EncryptedUserId) == true) {

The third problem (which I didn't encounter until a few years later) was that Password Minder wouldn't run on my Windows Vista x64 desktop.

Note that the original project settings specified Platform target: Any CPU and thus pwm.exe would generate a BadImageFormatException when trying to load the 32-bit NativeHelpers.dll.

Could not load file or assembly 'NativeHelpers, Version=1.5.0.4, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An attempt was made to load a program with an incorrect format.

This was easy enough to fix simply by setting Platform target to x86 and then recompiling.

So, why do I blog about Password Minder after all this time? Well, just this week I finally got around to incorporating it into my "Toolbox" Visual Studio solution that is scheduled to build daily using Team Foundation Server, and I discovered that my Team Foundation Build server wasn't setup to build C++ projects, which is what I will blog about next.

Stay tuned...I need to eat some breakfast first ;-)

I am sure that I'm not the first one to tell you this, but you can't believe everything you read on the Internet these days ;-)

Case in point...I've seen a number of sources claim that custom HTTP modules are not supported in Microsoft Office SharePoint Server (MOSS) 2007 and Windows SharePoint Services (WSS) v3.

These statements make it sound like if you add your own custom processing to the pipeline of each page request, you will instantly teleport your Production SharePoint farm into that vast wasteland we generally refer to as "Unsupported" -- where your support calls to Microsoft will be summarily terminated shortly after getting your Service Request (SRX) number.

Not so -- at least in this particular case.

Thank goodness, at least for my sake, because I've worked on a number of MCS (Microsoft Consulting Services) projects where we've delivered custom HTTP modules. It's always a little scary that something we deliver as part of an MCS engagement will later be deemed "unsupported."

In general, we are very good about knowing what is -- and is not -- supported, but there's always a chance that something "creative" we do in order to satisfy the business requirements for our customers will later be considered a problem by Microsoft Customer Service and Support (CSS).

There are, in fact, lots of things you can do with SharePoint that will thrust you into the dreaded "unsupported" category, but a custom HTTP module isn't one of them.

How can I say this with such conviction? Well, yesterday I came across the following on MSDN:

Support Details

A HTTP module assembly can be installed in the Web application’s \bin directory or in the global assembly cache.

Because an HTTP module is always called as part of the page processing pipeline, a poorly designed or faulty module can have a detrimental effect on performance or perceived stability of the environment. Thoroughly test each module for performance before deploying it.

If you want to see it for yourself, you can go straight to the source:

Obviously you want to be very cautious about using custom HTTP modules, but there are definitely scenarios where this is a good approach.

For the sake of this post, let's assume that you have a directory that contains some empty folders you want to get rid of. How the empty folders got there isn't important; all that matters is that you have some and you want to get rid of them.

A few years ago, I created the following script (starting from a sample I found in the Script Center on TechNet) to recursively enumerate a folder structure, identify any empty folders, and subsequently delete them.

Option Explicit

If (WScript.Arguments.Count <> 1) Then
    WScript.Echo("Usage: cscript DeleteEmptyFolders.vbs {path}")    
    WScript.Quit(1)
End If

Dim strPath
strPath = WScript.Arguments(0)

Dim fso
Set fso = CreateObject("Scripting.FileSystemObject")

Dim objFolder
Set objFolder = fso.GetFolder(strPath)

DeleteEmptyFolders objFolder

Sub DeleteEmptyFolders(folder)
    Dim subfolder
    For Each subfolder in folder.SubFolders
        DeleteEmptyFolders subfolder
    Next
    
    If folder.SubFolders.Count = 0 And folder.Files.Count = 0 Then
        WScript.Echo folder.Path & " is empty"
        fso.DeleteFolder folder.Path
    End If    
End Sub

As you can see, there's really nothing complex here. Nevertheless I still find it to be a very useful script from time to time, so I thought I should share it. I used it this morning and it occurred to me that I should throw it up on the blog.

Just be sure to run it with CScript -- and not the default WScript -- or you'll find the WScript.Echo messages rather frustrating.

Have you ever wanted to display data in a table but limit the size of the rows and columns within the table?

For example, consider the classic master/detail view that we often find in software applications, in which items are shown in a summary table and each row provides a link to allow users to see more detail about the item.

However, unlike the typical master/detail scenario, you need to limit the amount of real estate consumed on the page by the summary table. In addition, if text within a column is too long to fit within the constrained area, you want to show the full text when the mouse cursor hovers over the cell.

The following figure illustrates the desired end result:

Figure 1: Constrained table

See full-sized image.

Here is the sample ASP.NET page that I created this morning to demonstrate this:

<%@ Page Language="C#" AutoEventWireup="true"
    CodeBehind="ConstrainedTable.aspx.cs"
    Inherits="Fabrikam.Demo.Web.UI.ConstrainedTable" %>

<!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>Demo - Constrained Tabular Data</title>
    <link rel="Stylesheet" href="http://meyerweb.com/eric/tools/css/reset/reset.css" />
    <style>
        /* Basic formatting
        ----------------------------------------------------------------------*/
        body {
            color:#000000;
            font-family: Verdana, Arial, Helvetica;
            font-size: small;
            margin: 10px;
        }
        h1, h2, h3, h4, h5, h6, strong {
            font-weight: bold;
        }
        h1 {
            font-size: 1.5em;
            margin: .67em 0;
        }
        table caption {
            font-weight: bold;
            margin: 10px 0;
        }
        table.displayTable {
            border-left: 1px solid #36295E;
            border-right: 1px solid #36295E;
            margin: 1em 0;
        }
        table.displayTable th {
            text-align: left;
        }
        table.displayTable th, table.displayTable td {
            border-bottom: 1px solid #36295E;
            padding: 5px 10px;
            vertical-align: top;
        }
        table.displayTable thead th {
            background: #36295E;
            color: #FFF;
            padding: 8px 10px;
            border-bottom-width: 0;
        }        
        table.displayTable tr.altRow {
            background: #F4F4F4;
        }
        /* =constrainedTable
        ----------------------------------------------------------------------*/
        table.constrainedTable {
            table-layout: fixed;
            width: 540px;
        }
        table.constrainedTable th.nameColumn {
            width: 140px;
        }        
        table.constrainedTable td {
            overflow: hidden;
            -o-text-overflow: ellipsis; /* Opera */
            text-overflow: ellipsis;
            white-space: nowrap;
        }
    </style>
</head>
<body>
    <form id="form1" runat="server">
        <h1>Demo - Constrained Tabular Data</h1>
        <asp:GridView ID="ConstrainedGrid" runat="server"
            AutoGenerateColumns="false"
            Caption="Constrained Table"
            CssClass="displayTable constrainedTable"
            OnRowDataBound="ConstrainedGrid_RowDataBound"
            EnableViewState="false"
            UseAccessibleHeader="true">
            <AlternatingRowStyle CssClass="altRow" />
            <RowStyle CssClass="row" />
            <Columns>
                <asp:HyperLinkField
                    DataTextField="Site"
                    DataNavigateUrlFields="URL"
                    HeaderText="Site"
                    HeaderStyle-CssClass="nameColumn" />
                <asp:BoundField
                    DataField="Notes"
                    HeaderText="Notes"
                    HeaderStyle-CssClass="notesColumn" />
            </Columns>
        </asp:GridView>
    </form>
</body>
</html>

The most interesting parts of the ASP.NET page are the CSS rules for the constrainedTable class:

table.constrainedTable {
    table-layout: fixed;
    width: 540px;
}
table.constrainedTable th.nameColumn {
    width: 140px;
}        
table.constrainedTable td {
    overflow: hidden;
    -o-text-overflow: ellipsis; /* Opera */
    text-overflow: ellipsis;
    white-space: nowrap;
}

Changing the table-layout to fixed constrains the table to the specified width. Since I don't specify a width for the notesColumn it consumes the remaining width of the table.

Next, I specify that all cells in the constrained table should truncate the text within each cell if it is too wide to fit within the width of the column. This is achieved using the combination of overflow: hidden and white-space: nowrap. Finally, I use the text-overflow CSS property to show ellipsis when text within a cell is clipped (as well as a slight variation for the Opera browser).

Note

Support for the text-overflow CSS property is somewhat limited. In particular, you will find that a clipped table cell renders without the ellipsis in Firefox (at least in version 3.5.3). Oddly enough, this appears to have been supported in Internet Explorer since version 6. In addition to Internet Explorer and Opera, this also appears as expected in Safari.

Also note that constraining table cells using CSS does not automatically display the tooltip with the complete text. For that, you are on your own.

When using an ASP.NET GridView control, I recommend using the RowDataBound event in order to set the ToolTip property of the table cell. Just be sure to decode the contents of the cell to avoid having it encoded twice:

        protected void ConstrainedGrid_RowDataBound(
            object sender,
            GridViewRowEventArgs e)
        {
            foreach (TableCell cell in e.Row.Cells)
            {
                // Note: We need to decode the cell text in order to avoid
                // having it encoded twice (e.g. ">")
                cell.ToolTip = HttpUtility.HtmlDecode(cell.Text);
            }
        }

This is somewhat of a "brute force" approach since it makes no attempt to determine if the text will be truncated, but rather sets the ToolTip (in other words, the title attribute on the HTML element) for every cell. However, the simplicity of this approach -- and the resulting user experience -- far outweighs any extraneous markup (at least in my opinion).

Be aware that this simple approach for setting the ToolTip property doesn't support columns generated from a HyperLinkField, in which case cell.Text is empty (because the cell contains child controls, not simple text). In other words, it's a good thing my demo doesn't specify very long site names that don't fit within the 140 pixel width column constraint ;-)

Here is the complete code-behind for my sample ASP.NET page so you can run it yourself:

using System;
using System.Data;
using System.Globalization;
using System.Web;
using System.Web.UI.WebControls;

namespace Fabrikam.Demo.Web.UI
{
    public partial class ConstrainedTable : System.Web.UI.Page
    {
        protected void Page_PreRender(
            object sender,
            EventArgs e)
        {
            BindSampleData(this.ConstrainedGrid);

            this.ConstrainedGrid.HeaderRow.TableSection =
                TableRowSection.TableHeader;
        }

        #region BindSampleData

        private static void BindSampleData(
            GridView grid)
        {
            DataTable sampleData = new DataTable();
            sampleData.Locale = CultureInfo.InvariantCulture;

            sampleData.Columns.Add("Site");
            sampleData.Columns.Add("URL");
            sampleData.Columns.Add("Notes");

            sampleData.Rows.Add(
                new object[]
                {
                    "Microsoft",
                    "http://www.microsoft.com",
                    "Lorem ipsum dolor sit amet, consectetur adipiscing elit."
                        + "Morbi at sem lorem, ac blandit leo. Phasellus at"
                        + "ligula vitae enim dignissim tincidunt ornare nisl."
                });

            sampleData.Rows.Add(
                new object[]
                {
                    "MSDN",
                    "http://msdn.microsoft.com",
                    "Sed posuere mattis egestas. Aliquam commodo dolor"
                        + " vulputate odio lacinia bibendum. Nullam bibendum,"
                        + " neque vitae ullamcorper elementum, ligula dolor"
                        + " mollis erat, ut ultricies mauris tortor ut eros."
                });

            sampleData.Rows.Add(
                new object[]
                {
                    "TechNet",
                    "http://technet.microsoft.com",
                    "Vestibulum a leo nisl, sit amet porta eros. Proin vitae"
                        + " semper nunc. In facilisis nunc sit amet lacus"
                        + " accumsan mattis. Nulla facilisi. Pellentesque nisl"
                        + " sapien, dignissim ultrices semper et, mollis"
                        + " interdum sem. "
                });
            
            grid.DataSource = sampleData;
            grid.DataBind();
        }

        #endregion

        protected void ConstrainedGrid_RowDataBound(
            object sender,
            GridViewRowEventArgs e)
        {
            foreach (TableCell cell in e.Row.Cells)
            {
                // Note: We need to decode the cell text in order to avoid
                // having it encoded twice (e.g. ">")
                cell.ToolTip = HttpUtility.HtmlDecode(cell.Text);
            }
        }
    }
}