There is a way however, to intercept the message before it is returned to the front-end and log the error automatically the way we are used to with Elmah.

First we set up an ErrorHandlerFilter class which will override the default error stream message ( {“Message”:”There was an error processing the request.”, “StackTrace”:””, “ExceptionType”:””})} with a more meaningful error message with details.

   1: using System;

   2: using System.Collections.Generic;

   3: using System.IO;

   4: using System.Linq;

   5: using System.Text;

   6:  

   7: namespace Namespace.ElmahExtension

   8: {

   9:     public class ErrorHandlerFilter : Stream

  10:     {

  11:  

  12:         private readonly Stream _responseFilter;

  13:  

  14:         public List<byte> OriginalBytesWritten { get; private set; }

  15:  

  16:         private const string Content =

  17:           "{\"Message\":\"There was an error processing the request.\"" +

  18:           ",\"StackTrace\":\"\",\"ExceptionType\":\"\"}";

  19:  

  20:         public ErrorHandlerFilter(Stream responseFilter)

  21:         {

  22:             _responseFilter = responseFilter;

  23:             OriginalBytesWritten = new List<byte>();

  24:         }

  25:  

  26:         public override void Flush()

  27:         {

  28:             byte[] bytes = Encoding.UTF8.GetBytes(Content);

  29:             _responseFilter.Write(bytes, 0, bytes.Length);

  30:             _responseFilter.Flush();

  31:         }

  32:  

  33:         public override long Seek(long offset, SeekOrigin origin)

  34:         {

  35:             return _responseFilter.Seek(offset, origin);

  36:         }

  37:  

  38:         public override void SetLength(long value)

  39:         {

  40:             _responseFilter.SetLength(value);

  41:         }

  42:  

  43:         public override int Read(byte[] buffer, int offset, int count)

  44:         {

  45:             return _responseFilter.Read(buffer, offset, count);

  46:         }

  47:  

  48:         public override void Write(byte[] buffer, int offset, int count)

  49:         {

  50:             for (int i = offset; i < offset + count; i++)

  51:             {

  52:                 OriginalBytesWritten.Add(buffer[i]);

  53:             }

  54:         }

  55:  

  56:         public override bool CanRead

  57:         {

  58:             get { return _responseFilter.CanRead; }

  59:         }

  60:  

  61:         public override bool CanSeek

  62:         {

  63:             get { return _responseFilter.CanSeek; }

  64:         }

  65:  

  66:         public override bool CanWrite

  67:         {

  68:             get { return _responseFilter.CanWrite; }

  69:         }

  70:  

  71:         public override long Length

  72:         {

  73:             get { return _responseFilter.Length; }

  74:         }

  75:  

  76:         public override long Position

  77:         {

  78:             get { return _responseFilter.Position; }

  79:             set { _responseFilter.Position = value; }

  80:         }

  81:     }

  82: }

Now, we’re going to need to set up a class that implements IHttpModule.  which we’ll use to intercept the message being passed after the Request and EndRequest handlers execute.

   1: using System;

   2: using System.Diagnostics;

   3: using System.IO;

   4: using System.Text;

   5: using System.Web;

   6: using System.Web.Services.Protocols;

   7: using Elmah;

   8:  

   9: namespace Namespace.ElmahExtension

  10: {

  11:     public class ElmahExtension : IHttpModule

  12:     {

  13:         private HttpApplication _application;

  14:  

  15:         public void Dispose()

  16:         {

  17:         }

  18:  

  19:         public void Init(HttpApplication context)

  20:         {

  21:             _application = context;

  22:             _application.PostRequestHandlerExecute += OnPostRequestHandlerExecute;

  23:             _application.EndRequest += OnEndRequest;

  24:         }

  25:  

  26:         private void OnPostRequestHandlerExecute(object sender, EventArgs e)

  27:         {

  28:             var context = sender as HttpApplication;

  29:             if(context != null && (context.Request.Path.Contains(".asmx") && (context.Response.StatusCode >= 400 && context.Response.StatusCode < 600)))

  30:             {

  31:                 context.Response.Filter = new ErrorHandlerFilter(context.Response.Filter);

  32:             }

  33:         }

  34:  

  35:         static void OnEndRequest(object sender, EventArgs e) 

  36:         {

  37:             var context = (HttpApplication)sender;

  38:             var errorHandlerFilter = context.Response.Filter as ErrorHandlerFilter;

  39:  

  40:             if (errorHandlerFilter == null)

  41:             {

  42:                 return;

  43:             }

  44:  

  45:             var originalContent = Encoding.UTF8.GetString(errorHandlerFilter.OriginalBytesWritten.ToArray());

  46:             ErrorLog.GetDefault(context.Context).Log(new Error(new Exception(originalContent)));

  47:         }

  48:     }

  49:  

  50: }

Notice in the OnPostRequestHandlerExecute function we’re intercepting any request that comes from a Webservice (.asmx page) and has a status code of greater than 400 (All error code types).  At his point we want to set the ErrorHandelerFilter to the current Response.Filter value.

Now in the OnEndRequest function we want to get the current context and set the error handler based on the filter which should now be persisting the values we set in the previous function.  Once we have the error values all we have to do is call the Elmah manual logging API and log the exception.

The final piece you have to do is set up the webConfig to recognize and use your IHttpModule code. n In your config file navigate down to System.Web >> HttpModules and fill in the attribute accordingly.

   1: <system.web>

   2:     <httpModules>    

   3:       <add name="ElmahExtension" type="Namespace.ElmahExtension.ElmahExtension"/>

   4:     </httpModules>

   5: </system.web>

Once you compile and run, any errors encountered in your web services should now be logged by Elmah just like any others.

Thanks to Reddy Kadasani, Mike Gerety and Dylan Barrett for their contributions to this solution.

This kind of solution can be applied to several situations such as complex data processing, dynamic loading, or combining them all into a seamless form submission process that would clear the form on post backs.

We can accomplish this process simply by grabbing an event, such as a button click, and collecting all the required information using jQuery.  Next using a JSON call, we can pass all the parameters to the web service and execute our code from there.

Here, I’ll start with a simple .aspx page with jquery, a textbox, and link that will be used to call the web service.

   1: <%@ Master Language="C#" MasterPageFile="~/Site.Master" AutoEventWireup="true" CodeBehind="ThisPage.cs" Inherits="ThisSolution.ThisProject.ThisFolder" %>

   2:  

   3: <asp:Content ID="Content1" ContentPlaceHolderID="HeadContent" runat="server">

   4:     <script src="/Scripts/jquery-1.4.1.min.js" type="text/javascript"/>

   5: </asp:Content>

   6:  

   7: <asp:Content ID="Content2" ContentPlaceHolderID="MainContent" runat="server">

   8:     <asp:TextBox ID=”textBox” TextMode="MultiLine" runat="server"></asp:TextBox>

   9:     <a href="#" class="buttonClass"> Save </a>

  10:     <asp:Label ID=”successLabel” runat="server"></asp:Label>

  11: </asp:Content>

Next, you will need to establish your web service and create an .asmx file.  There are a couple of important things to note here. Line 5 will be by default commented out.  So in order for us to make our JSON call we’re going to need this uncommented.  Also, notice I’m returning a string.  For the purposes of this demo I am going to return a string to the UI and display a message, but you can return any kind of object that can be serialized down to a primitive data type.

   1: [WebService(Namespace = "http://tempuri.org/")]

   2: [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]

   3: [System.ComponentModel.ToolboxItem(false)]

   4: // To allow this Web Service to be called from script, using ASP.NET AJAX, uncomment the following line. 

   5: [System.Web.Script.Services.ScriptService]

   6: public class wService : System.Web.Services.WebService

   7: {

   8:     [WebMethod()]

   9:     [ScriptMethod(UseHttpGet = false, ResponseFormat = ResponseFormat.Json)]

  10:     public string UpdateComment(string textBoxText)

  11:     {

  12:         var success = Service.CallToDb(textBoxText);

  13:  

  14:         if(success)

  15:         {

  16:             return "Call to Database using text was successful";

  17:         }

  18:         else 

  19:         {

  20:             return "Call to Database using text was not successful";

  21:         }    

  22:     }           

  23: }

I use a jQuery selector to pick up on the mouse click of the link and gather our data into an javascript object.  Note that when passing parameters through this object you have to name them the same way as you do in the parameter declaration of the web service.

When setting up the call to the service you’re going to want to remember to call the “JSON.stringify” function on your data object so that it serializes properly and that your contentType as well as dataType are configured properly as well.

   1: <script type='text/javascript>

   2:     $('.buttonClass').live('click', function(){

   3:         var text = $('#textBox').text();

   4:         var data = new Object();

   5:         data.textBoxText = text;

   6:  

   7:         $.ajax({

   8:             type: "POST",

   9:             url: "/Ajax/WbServcie.asmx/UpdateComment",

  10:             data: JSON.stringify(data),

  11:             contentType: "application/json; charset=utf-8",

  12:             dataType: "json",

  13:             success: function(msg){

  14:                 $('#successLabel').val(msg);

  15:             },

  16:             error: function(msg){

  17:                 alert('Something, somewhere, has gone terribly wrong');

  18:                 return false;

  19:             }

  20:         });    

  21: </script>

Once you get a response from the service, you can set any of your data that is returned.  In this case, we’re returning a string indicating the call to the database was successful and will set a label on the page to show that.

And that’s it.  With just a few simple configurations we have a quick call back to the server without having to run an expensive post back.

Visible obviously means “visible,” while both Hidden and Collapsed mean “invisible.” The difference between Hidden and Collapsed is merely whether or not the invisible control occupies blank space on the screen that it would occupy if it were visible. Collapsed consumes no space, while Hidden does.

It’s nice to have the three options, but in most cases you’ll find that you just need the two options Visible and Collapsed. If you’re setting visibility to XAML controls using these two enums, you’ve probably noticed that it’s just not as clean as it is with Windows Forms or ASP.NET controls. You typically already have a Boolean value—either as a simple variable, or an expression—that determines whether the control should be visible or not. You could use that value to enable or disable the control, as the IsEnabled property is also a Boolean, but you can’t assign it to the Visibility property because that property expects one of the three Visibility enumerations—not a Boolean. That’s frustrating, because from a UX (user experience) perspective, where these concepts are used to convey “availability” to the user, hiding/showing controls versus enabling/disabling them is a subtlety of UI design. So developers should be able to think (and code) freely in terms of Booleans for both IsEnabled and Visibility.

Consider the C# code to manipulate the Visibility and IsEnabled properties of a button control:

OpenCustomerButton.IsEnabled = false;
OpenCustomerButton.IsEnabled = true;
OpenCustomerButton.Visibility = Visibility.Collapsed;
OpenCustomerButton.Visibility = Visibility.Visible;

bool isAvailable = true;
OpenCustomerButton.IsEnabled = isAvailable;
OpenCustomerButton.Visibility =
  (isAvailable ? Visibility.Collapsed : Visibility.Visible);

// Set the visibility according another button's enabled/disabled state
OpenCustomerButton.Visibility =
  (ManageCustomersButton.IsEnabled ? Visibility.Visible : Visibility.Collapsed);

You can see that because Visibility takes the enum rather than a bool, it’s harder to work with than IsEnabled, and just isn’t as neat. But we can do something about this. How? By writing a simple (one-line!) extension method that adds a ToVisibility method to the bool class:

public static class BoolExtensions
{
  public static Visibility ToVisibility(this bool isVisible)
  {
    return (isVisible ? Visibility.Visible : Visibility.Collapsed);
  }
}

Now the same UI code is much easier to read and write:

OpenCustomerButton.IsEnabled = false;
OpenCustomerButton.IsEnabled = true;
OpenCustomerButton.Visibility = false.ToVisibility();
OpenCustomerButton.Visibility = true.ToVisibility();

bool isAvailable = true;
OpenCustomerButton.IsEnabled = isAvailable;
OpenCustomerButton.Visibility = isAvailable.ToVisibility();

// Set the visibility according to another button's enabled/disabled state
OpenCustomerButton.Visibility = ManageCustomersButton.IsEnabled.ToVisibility();

Like? Me too. Neatness counts!

It would be even better if we could instead extend every UIElement with a Boolean property called IsVisible, and embed the conversion logic bi-directionally in the property’s getter and setter. But, unfortunately, you cannot create extension properties in .NET, only extension methods. So extending bool with a ToVisibility method is the next best thing.

One more tip: Put the BoolExtensions class inside a common code namespace that all your XAML classes import, so ToVisibility is always available without needing to add an extra using statement.

Remember, abusing extension methods quickly leads to messy, buggy code. Instead, find appropriate uses for extension methods that yield cleaner, tighter code.

To use the parallel feature in .NET 4.0 you need to use the namespace System.Threading.Tasks. Then you simply take the list structure that you want to traverse and iterate through it using Parallel.ForEach(IEnumerable<TSource> source, Action<TSource> body). For example,

Parallel.ForEach(someLargeList, item =>

{

doSomething();

});.

For information on synchronized parallel programming, take a look at http://reedcopsey.com/2010/01/22/parallelism-in-net-part-4-imperative-data-parallelism-aggregation/. The author goes over how you can synchronize dependent data using the .NET 4.0 multithreading feature.

Before .NET 4.0 one would have to overload methods if they wanted the ability to implement optional parameters. With this latest version of .NET, developers simply have to add the optional parameter in the last position of parameters as displayed below.

Example of Optional Parameters

Another new feature in .NET 4.0 is named parameters, which allow you to ignore the parameter order and mention parameters with names in a different order. For example:

Example of Named Parameters

Although Microsoft coins this as an improvement, I find that this gives way for confusing code that may be hard to manage. For instance, imagine reading several lines of code, written by someone else, with methods having parameters all jumbled in no particular order.

Finally, in situations where we want to redirect users to a new page permanently and update the search engine’s indexes, a new command Response.RedirectPermanent can be used in .NET 4.0. In previous versions of .NET, Response.Redirect was used to do the redirection. The caveat in the aforementioned approach was that the header information for the page would not be updated, therefore allowing search engines to keep the old information of the page in their indexes for search. With the new command Response.RedirectPermanent, header information is updated on the server, the user is directly redirected to the new page and it saves a double trip to server as well. In addition, search engines, on re-indexing of that site and page, update the header information in their index for better performance on searches.

While SharePoint 2010 supports .NET 3.5, it uses the .NET 2.0 compiler by default for ASP.NET pages.  If you write any UserControls or consume any DLLs in your hosted ASPX pages that utilizes .NET 3.5 features such as the var keyword, extension methods, and LINQ, you’ll get compilation error messages when attempting to access those pages.

To resolve this issue, you can edit the web.config in your site collection’s virtual directory (Usually under \inetpub\wwwroot\wss\virtualdirectories\<site>).  Add the following snippet under the configuration element:

<system.codedom>
  <compilers>
    <compiler language="c#;cs;csharp" extension=".cs" warningLevel="4"
              type="Microsoft.CSharp.CSharpCodeProvider, System, Version=2.0.0.0,
                    Culture=neutral, PublicKeyToken=b77a5c561934e089">
      <providerOption name="CompilerVersion" value="v3.5" />
      <providerOption name="WarnAsError" value="false" />
    </compiler>
  </compilers>
</system.codedom> 

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

Also, look under the Assemblies section and make sure you have the following entries:

   1: <add assembly="System.Web.Extensions, Version=3.5.0.0,Culture=neutral, PublicKeyToken=31BF3856AD364E35" />

   2: <add assembly="System.Xml.Linq, Version=3.5.0.0,Culture=neutral, PublicKeyToken=B77A5C561934E089" />

   3: <add assembly="Microsoft.SharePoint, Version=14.0.0.0,Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

   4: <add assembly="System.Web.Extensions, Version=3.5.0.0,Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

   5: <add assembly="Microsoft.Web.CommandUI, Version=14.0.0.0,Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

   6: <add assembly="Microsoft.SharePoint.Search, Version=14.0.0.0,Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

   7: <add assembly="Microsoft.Office.Access.Server.UI, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

   8: <add assembly="Microsoft.SharePoint.Publishing, Version=14.0.0.0,Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

Note: You can also add other .NET 3.5 assemblies here as needed.

This walkthrough will explain how to setup email alerts in TFS when there is a check-in. Using this method, you can not only select a TFS Project, but you can also select an individual folder. This is useful if you are not interested in some folders in the project, but want alerts on others.

TFS Check-In Alerts in Visual Studio 2008

First, TFS Power Tools must be installed for Visual Studio 2008 (Link), and Team Explorer (Link).

First make sure you are connected to TFS.

Tools >> Connect to Team Foundation Server…

Open Source Control Explorer.

View >> Other Windows >> Source Control Explorer.

Navigate to the folder that you want notifications on.

Right click and select "Alert on Change…"

The following popup window will display. From here you can set the alert name and the email that you want to send it to. It will try to default itself to the folder name and your email.

After that, you can view and modify the alert from the "Alerts Editor"

Team >> Alerts Editor…

You can also access that menu from the Team Explorer:

Once you open that, the original alert definition is as follows:

I usually don’t mind getting an alert when I check-in, so I usually remove the second row from the grid. You can also specify this in the add dialog above, but I wanted to display it here as an example.

From here, you can modify the alert as necessary. If you have a nightly or weekly build you may not want notifications from that, so you can exclude those as shown below.

From the Alerts Editor, you can also specify other event types shown below.

Work Item Alerts

Check In Alerts

Build Alerts

TFS Check-In Alerts in Visual Studio 2010

This can also be done in Visual Studio 2010, but you will need the TFS 2010 Power Tools (Link)

The setup or modification of alerts is very similar to that in Visual Studio 2008. One difference shown below is how you access the Alerts Explorer from Team Explorer.

Instead of clicking on the "Alerts" button for a specific project, you have to right click on the TFS server, and select Alerts Explorer.

You can still access this menu from Team >> Alerts Explorer as in Visual Studio 2008.

You also still get the same "Alert on Change…" option from Source Control Explorer.

Hope this helps.

Resources

Visual Studio Power Tools: http://msdn.microsoft.com/en-us/vstudio/bb980963.aspx

TFS 2008 Power Tools: http://www.microsoft.com/download/en/details.aspx?DisplayLang=en&id=15836

Team System 2008 Team Explorer: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=16338

TFS 2010 Power Tools: http://visualstudiogallery.msdn.microsoft.com/c255a1e4-04ba-4f68-8f4e-cd473d6b971f

Robert Lanzilli (robert.lanzilli@tallan.com)

If you’re not already familiar with FILESTREAM, you can get the necessary background by reading these two articles: Introducing FILESTREAM and Enabling and Using FILESTREAM. In this post, I’ll show you how to use the SqlFileStream class to achieve high-performance streaming of SQL Server FILESTREAM data in your .NET applications (the code is shown in C#, but can be written in VB .NET as well).

What Is SqlFileStream?

SqlFileStream is a class in the .NET Framework (.NET 3.5 SP1 and higher) that wraps the OpenSqlFilestream function exposed by the SQL Server Native Client API. This lets you stream BLOBs directly between SQL Server and your .NET application (written in C# or VB .NET). SqlFileStream is always used within a transaction. You create a SqlFileStream object when you are ready to store and retrieve BLOBs from varbinary(max) FILESTREAM columns. Just at that point in time, SQL Server will “step aside” and let you stream directly against the server’s file system—a native environment optimized for streaming. This provides you with a streaming “tunnel” between your application and SQL Server’s internally-managed file system. Using SqlFileStream will give your application lightning-fast BLOB performance. Let’s dive in!

Creating the Database

Before getting started, be sure that FILESTREAM is enabled for remote file system access at both the Windows Service and SQL Server instance levels (as explained in Enabling and Using FILESTREAM). Then create a FILESTREAM-enabled database as follows (be sure to create the directory, C:\DB in this example, before creating the database):

CREATE DATABASE PhotoLibrary
 ON PRIMARY
  (NAME = PhotoLibrary_data,
   FILENAME = 'C:\DB\PhotoLibrary_data.mdf'),
 FILEGROUP FileStreamGroup CONTAINS FILESTREAM
  (NAME = PhotoLibrary_blobs,
   FILENAME = 'C:\DB\Photos')
 LOG ON
  (NAME = PhotoLibrary_log,
   FILENAME = 'C:\DB\PhotoLibrary_log.ldf')

Next, use the database and create a table for BLOB storage as follows:

USE PhotoLibrary
GO

CREATE TABLE PhotoAlbum(
 PhotoId int PRIMARY KEY,
 RowId uniqueidentifier ROWGUIDCOL NOT NULL UNIQUE DEFAULT NEWID(),
 Description varchar(max),
 Photo varbinary(max) FILESTREAM DEFAULT(0x))

In this table, the Photo column is declared as varbinary(max) FILESTREAM, and will hold pictures that will be stored in the file system behind the scenes. (Refer to Enabling and Using FILESTREAM for a complete explanation of the varbinary(max) FILESTREAM and ROWGUIDCOL columns.) Notice the default value we’ve established for the BLOB column. The value 0x represents a zero-length binary stream, which is different than NULL. Think of it as the difference between a zero-length string and a null string in .NET; the two are not the same. Similarly, you won’t be able to use SqlFileStream against NULL instances of varbinary(max) FILESTREAM columns, and you’ll soon see why.

Writing SqlFileStream Code

Start Visual Studio, create a new Class Library project, and add a PhotoData class as follows:

using System;
using System.Data;
using System.Data.SqlClient;
using System.Data.SqlTypes;
using System.Drawing;
using System.IO;
using System.Transactions;

namespace PhotoLibraryApp
{
  public class PhotoData
  {
    private const string ConnStr =
      "Data Source=.;Integrated Security=True;Initial Catalog=PhotoLibrary;";

    public static void InsertPhoto
      (int photoId, string desc, string filename)
    {
      const string InsertTSql = @"
        INSERT INTO PhotoAlbum(PhotoId, Description)
          VALUES(@PhotoId, @Description);
        SELECT Photo.PathName(), GET_FILESTREAM_TRANSACTION_CONTEXT()
          FROM PhotoAlbum
          WHERE PhotoId = @PhotoId";

      string serverPath;
      byte[] serverTxn;

      using (TransactionScope ts = new TransactionScope())
      {
        using (SqlConnection conn = new SqlConnection(ConnStr))
        {
          conn.Open();

          using (SqlCommand cmd = new SqlCommand(InsertTSql, conn))
          {
            cmd.Parameters.Add("@PhotoId", SqlDbType.Int).Value = photoId;
            cmd.Parameters.Add("@Description", SqlDbType.VarChar).Value = desc;
            using (SqlDataReader rdr = cmd.ExecuteReader())
            {
              rdr.Read();
              serverPath = rdr.GetSqlString(0).Value;
              serverTxn = rdr.GetSqlBinary(1).Value;
              rdr.Close();
            }
          }
          SavePhotoFile(filename, serverPath, serverTxn);
        }
        ts.Complete();
      }
    }

    private static void SavePhotoFile
      (string clientPath, string serverPath, byte[] serverTxn)
    {
      const int BlockSize = 1024 * 512;

      using (FileStream source =
        new FileStream(clientPath, FileMode.Open, FileAccess.Read))
      {
        using (SqlFileStream dest =
          new SqlFileStream(serverPath, serverTxn, FileAccess.Write))
        {
          byte[] buffer = new byte[BlockSize];
          int bytesRead;
          while ((bytesRead = source.Read(buffer, 0, buffer.Length)) > 0)
          {
            dest.Write(buffer, 0, bytesRead);
            dest.Flush();
          }
          dest.Close();
        }
        source.Close();
      }
    }

    public static Image SelectPhoto(int photoId, out string desc)
    {
      const string SelectTSql = @"
        SELECT
            Description,
            Photo.PathName(),
            GET_FILESTREAM_TRANSACTION_CONTEXT()
          FROM PhotoAlbum
          WHERE PhotoId = @PhotoId";

      Image photo;
      string serverPath;
      byte[] serverTxn;

      using (TransactionScope ts = new TransactionScope())
      {
        using (SqlConnection conn = new SqlConnection(ConnStr))
        {
          conn.Open();

          using (SqlCommand cmd = new SqlCommand(SelectTSql, conn))
          {
            cmd.Parameters.Add("@PhotoId", SqlDbType.Int).Value = photoId;

            using (SqlDataReader rdr = cmd.ExecuteReader())
            {
              rdr.Read();
              desc = rdr.GetSqlString(0).Value;
              serverPath = rdr.GetSqlString(1).Value;
              serverTxn = rdr.GetSqlBinary(2).Value;
              rdr.Close();
            }
          }
          photo = LoadPhotoImage(serverPath, serverTxn);
        }

        ts.Complete();
      }

      return photo;
    }

    private static Image LoadPhotoImage(string filePath, byte[] txnToken)
    {
      Image photo;

      using (SqlFileStream sfs =
        new SqlFileStream(filePath, txnToken, FileAccess.Read))
      {
        photo = Image.FromStream(sfs);
        sfs.Close();
      }

      return photo;
    }

  }
}

Let’s explain the code in detail. We’ll start at the top with some required namespace inclusions. The two using statements to take notice of are System.Data.SqlTypes and System.Transactions. The System.Data.SqlTypes namespace defines the SqlFileStream class that we’ll be using to stream BLOBs. No special assembly reference is required to use this class, because it is provided by the System.Data.dll assembly that our project is already referencing (Visual Studio set this reference automatically when it created our project). The System.Transactions namespace defines the TransactionScope class that lets us code implicit transactions against the database. This class is provided by the System.Transactions.dll assembly, which is not referenced automatically. You’ll need to add a reference to it now, or the code will not compile. Right-click the project in Solution Explorer and choose Add Reference. In the Add Reference dialog, click the .NET tab, and scroll to find the System.Transactions component. Then double-click it to add the reference.

At the top of the class, we define a connection string as a hard-coded constant named ConnStr. This is just for demonstration purposes; a real-world application would store the connection string elsewhere (such as in a configuration file, possibly encrypted), but we’re keeping our example simple.

Streaming Into SQL Server

The first method defined in the class is InsertPhoto, which accepts a new photo integer ID, string description, and full path to an image file to be saved to the database. Notice that the InsertTSql string constant defined at the top of the method specifies an INSERT statement that includes the PhotoId and Description columns, but not the actual Photo BLOB column itself. Instead, the INSERT statement is followed immediately by a SELECT statement that retrieves two pieces of information we’ll use to stream the BLOB into Photo column much more efficiently than using ordinary T-SQL—namely, a logical UNC path name to the file and the transactional context token. These are the two values needed to use SqlFileStream, and you’re about to see how exactly. But all we’ve done so far is define a constant holding two T-SQL statements. The constant is followed by two variables declarations serverPath and serverTxn that will receive the two special values when we later execute those T-SQL statements.

The method then creates and enters a new TransactionScope block. This does not actually begin the database transaction (we’ve not even connected to the database yet), but rather declares that all data access within the block (and in any code called from within the block) must participate in a database transaction. Inside the TransactionScope block, the code creates and opens a new SqlConnection. Being the first data access code inside the TransactionScope block, this also implicitly begins the database transaction. Next, it creates a SqlCommand object associated with the open connection and prepares its command text to contain our T-SQL statements (the INSERT followed by the SELECT).

Invoking the ExecuteReader method executes the T-SQL statements and returns a reader from which we can retrieve the values returned by the SELECT statement. The transaction is still pending at this time. Our INSERT statement does not provide a value for RowId and instead allows SQL Server to automatically generate and assign a new uniqueidentifier ROWGUID value by default just like before when we used T-SQL to insert the first two rows. We’ve also pointed out that no value is provided for the Photo column—and this is exactly how the default 0x value that we defined earlier for the Photo column comes into play (we said we’d come back to it, and here we are).

Although the row has been added by the INSERT statement, it will rollback (disappear) if a problem occurs before the transaction is committed. Because we didn’t provide a BLOB value for the Photo column in the new row, SQL Server honors the default value 0x that we established for it in the CREATE TABLE statement for PhotoAlbum. This represents a zero-length binary stream, which is completely different than NULL. Being a varbinary(max) column decorated with the FILESTREAM attribute, an empty file gets created in the file system that SQL Server associates with the new row. At the same time, SQL Server initiates an NTFS file system transaction over this new empty file and synchronizes it with the database transaction. So just like the new row, the new file will disappear if the database transaction does not commit successfully.

Immediately following the INSERT statement, the SELECT statement returns Photo.PathName and GET_FILESTREAM_TRANSACTION_CONTEXT. What we’re essentially doing with the WHERE clause in this SELECT statement is reading back the same row we have just added (but not yet committed) to the PhotoAlbum table in order to reference the BLOB stored in the new file that was just created (also not yet committed) in the file system.

The value returned by Photo.PathName is a fabricated path to the BLOB for the selected PhotoId. The path is expressed in UNC format, and points to the network share name established for the server instance when we first enabled FILESTREAM (this is MSSQLSERVER in our example, as shown in Figure 9-1). It is not a path the file’s physical location on the server, but rather contains information SQL Server can use to derive the file’s physical location. For example, you’ll notice that it always contains the GUID value in the uniqueidentifier ROWGUIDCOL column of the BLOB’s corresponding row. We retrieve the path value from the reader’s first column and store it in the serverPath string variable.

We just explained how SQL Server initiated an NTFS file system transaction over the FILESTREAM data in the new row’s Photo column when we started our database transaction. The GET_FILESTREAM_TRANSACTION_CONTEXT function returns a handle to that NTFS transaction (if you’re not inside a transaction, this function will return NULL and your code won’t work). We obtain the transaction context, which is returned by the reader’s second column as a SqlBinary value, and store it in the byte array named serverTxn.

Armed with the BLOB path reference in serverPath and the transaction context in serverTxn, we have what we need to create a SqlFileStream object and perform direct file access to stream our image into the Photo column. We close the reader, terminate its using block, then terminate the enclosing using block for the SqlConnection as well. This would normally close the database connection implicitly, but that gets deferred in this case because the code is still nested inside the outer using block for the TransactionScope object. So the connection is still open at this time, and the transaction is still pending. It is precisely at this point that we call the SavePhotoFile method to stream the specified image file into the Photo column of the newly inserted PhotoAlbum row, overwriting the empty file just created by default. When control returns from SavePhotoFile, the TransactionScope object’s Complete method is invoked and its using block is terminated, signaling the transaction management API that everything worked as expected. This implicitly commits the database transaction (which in turn commits the NTFS file system transaction) and closes the database connection.

The SavePhotoFile method reads from the source file and writes to the database FILESTREAM storage in 512 KB chunks at a time using ordinary .NET streaming techniques. The method begins by defining a BlockSize integer constant that is set to a reasonable value of 512 KB. Picture files larger than this will be streamed to the server in 512 KB blocks at a time. The local source image file (in clientPath) is then opened on an ordinary read-only FileStream object.

Then the destination file is opened by passing the two special values (serverPath and serverTxn), along with a FileAccess.Write enumeration requesting write access, into the SqlFileStream constructor. Like the source FileStream object, SqlFileStream inherits from System.IO.Stream, so it can be treated just like any ordinary stream. Thus, you attain write access to the destination BLOB on the database server’s NTFS file system. Remember that this output file is enlisted in an NTFS transaction and nothing you stream to it will be permanently saved until the database transaction is committed by the terminating TransactionScope block, after SavePhotoFile completes. The rest of the SavePhotoFile method implements a simple loop that reads from the source FileStream and writes to the destination SqlFileStream, one 512 KB block at a time until the entire source file is processed, and then it closes both streams.

Streaming Out From SQL Server

The rest of the code contains methods to retrieve existing photos and stream their content from the file system into an Image object for display. You’ll find that this code follows the same pattern as the last, only now we’re performing read access.

The SelectPhoto method accepts a photo ID and returns the string description from the database in an output parameter. The actual BLOB itself is returned as the method’s return value in a System.Drawing.Image object. We populate the Image object with the BLOB by streaming into it from the database server’s NTFS file system using SqlFileStream. Once again, we start things off by entering a TransactionScope block and opening a connection. We then execute a simple SELECT statement that queries the PhotoAlbum table for the record specified by the photo ID and returns the description and full path to the image BLOB, as well as the FILESTREAM transactional context token. And once again we use the path name and transactional context with SqlFileStream to tie into the server’s file system in the LoadPhotoImage method.

Just as when we were inserting new photos (only this time using FileAccess.Read instead of FileAccess.ReadWrite), we create a new SqlFileStream object from the logical path name and transaction context. We then pull the BLOB content directly from the NTFS file system on the server into a new System.Drawing.Image object using the static Image.FromStream method against the SqlFileStream object. The populated image can then be passed back up to a Windows Forms application, where it can be displayed using the Image property of a PictureBox control.

Or, to stream a photo over HTTP from a simple ASP.NET service:

using System;
using System.Data;
using System.Data.SqlClient;
using System.Data.SqlTypes;
using System.IO;
using System.Transactions;
using System.Web.UI;

namespace PhotoLibraryHttpService
{
  public partial class PhotoService : Page
  {
    private const string ConnStr =
      "Data Source=.;Integrated Security=True;Initial Catalog=PhotoLibrary";

    protected void Page_Load(object sender, EventArgs e)
    {
      int photoId = Convert.ToInt32(Request.QueryString["photoId"]);
      if (photoId == 0)
      {
        return;
      }

      const string SelectTSql = @"
        SELECT Photo.PathName(), GET_FILESTREAM_TRANSACTION_CONTEXT()
         FROM PhotoAlbum
         WHERE PhotoId = @PhotoId";

      using (TransactionScope ts = new TransactionScope())
      {
        using (SqlConnection conn = new SqlConnection(ConnStr))
        {
          conn.Open();

          string serverPath;
          byte[] serverTxn;

          using (SqlCommand cmd = new SqlCommand(SelectTSql, conn))
          {
            cmd.Parameters.Add("@PhotoId", SqlDbType.Int).Value = photoId;

            using (SqlDataReader rdr = cmd.ExecuteReader())
            {
              rdr.Read();
              serverPath = rdr.GetSqlString(0).Value;
              serverTxn = rdr.GetSqlBinary(1).Value;
              rdr.Close();
            }
          }

          this.StreamPhotoImage(serverPath, serverTxn);
        }
        ts.Complete();
      }
    }

    private void StreamPhotoImage(string serverPath, byte[] serverTxn)
    {
      const int BlockSize = 1024 * 512;
      const string JpegContentType = "image/jpeg";

      using (SqlFileStream sfs =
        new SqlFileStream(serverPath, serverTxn, FileAccess.Read))
      {
        byte[] buffer = new byte[BlockSize];
        int bytesRead;
        Response.BufferOutput = false;
        Response.ContentType = JpegContentType;
        while ((bytesRead = sfs.Read(buffer, 0, buffer.Length)) > 0)
        {
          Response.OutputStream.Write(buffer, 0, bytesRead);
          Response.Flush();
        }
        sfs.Close();
      }
    }
  }
}

Conclusion

The OpenSqlFilestream function provides native file streaming capabilities between FILESTREAM storage in the file system managed by SQL Server and any native-code (e.g., C++) application. SqlFileStream provide a managed code wrapper around OpenSqlFilestream that simplifies direct FILESTREAM access from .NET applications (e.g., C# and VB .NET). This post explained how this API works in detail, and showed the complete data access code that uses SqlFileStream for both reading and writing BLOBs to and from SQL Server. That’s everything you need to know to get the most out of FILESTREAM. I hope you enjoyed it!

In general, exceptions should be bubbled up to the highest possible level to be caught and processed.  For example, in our project, a search goes through the following logical tiers:

UI -> Services -> Data/SharePoint/Refinement -> Web Services

There are quite a few instances where we’re catching exceptions in the Data or Services layer, logging them using common logging components or configurations, and then swallowing the exception one way or another.

This is a bad practice for few reasons:

• This behavior is not transparent to developers that may be using the DLL but do not have access to the source code.
• Logging from lower tier components is generally a bad idea, as it either requires a static logging location embedded in the dll or creates a dependency on the UI to provide pre-determined logging mechanism (i.e. EntLib).   (This can get especially ugly with EntLib, and EntLib Logging and ExceptionHandling blocks generally use named “policies” for handling and logging exceptions, and referencing them from a middle-tier component requires any UI consuming it to implement the exact same logging configuration.
• Applications consuming the DLL do not know about or are not given the ability to choose how to react to exceptions in the code.
• Swallowing exceptions dilutes the effectiveness of unit tests testing these functions, as tests can’t explicitly test for scenarios that might cause specific exceptions,
• Swallowing exceptions can make debugging issues a nightmare (if not impossible) for developers that might consume this middle-tier component and not have access to the source code.
• Catch blocks have an inherent performance cost.  Catching exceptions unnecessarily results in unnecessary performance degredataion.

There are a few legitimate cases where this best practice might not be followed:

1. The Exception contains potentially sensitive information

If the exception or exception message contains potentially sensitive information such as user credentials, server names, or any other sensitive information, it likely makes sense to catch the exception, create an exception that accurately describes the issue without the sensitive information, then throw that exception.  Note however, there are very few scenarios where this should not occur at the UI layer.

2. The exception is too vague or needs more metadata to be meaningful to the code consuming it.

If the exception by itself is too vague or requires rebadging or augmented metadata to be useful to the code consuming it, it generally makes sense to wrap the exception by creating an exception that allows the original exception to be set as an “InnerException”, and augments the original exception with more information.  This new exception should then be thrown.

3. The exception that was caught should not affect the execution of the code

If an exception occurs that should not affect the execution of the code, it may be swallowed or ignored in limited cases.  However, exceptions really should not be being thrown unless there is a severe enough issue to potentially interrupt program execution, so I’d suggest reviewing the code throwing the exception you are swallowing in this case.

4. The Exception Occurs At A Physical Tier Boundary

Your multi-tier applications may not only contain multiple logical tiers, but physical tiers as well.  (for example, your web application may rely on a web service layer on a separate physical server).  While your web service layer may be “middle-tier” as far as the overall application is concerned, exceptions should be caught, processed, and logged at the boundary to that physical tier.  Logging on the machine where the services resides aides in issue resolution, and it gives an opportunity to review exceptions for sensitive information before sending them over the network, where they may be intercepted.

Practice #2: You Should (Almost Never) Catch System.Exception

You should almost never write the following:

This code says that you don’t know what type of exception to expect, so catch them all.

Any exception that the code is not expecting is, by definition, an unexpected or unhandled exception.  You probably want your application to crash (or gracefully exit) with an “Unhandled Exception” message if an unexpected exception occurs! How can you be certain of the stability of the currently running instance of your code if an exception occurred somewhere that you didn’t expect?

Also, catching specific exceptions helps greatly in diagnosing issues, and displaying useful and meaningful error messages to your users.  I think we all know how frustrating a generic error message such as “An error occurred.” can be.

If you think an exception might occur but you don’t know the type, either determine the type and catch it or don’t implement a handler at all!   If you need to throw an exception and there’s not an exception type available that is specific to the error that occurred, create a new one.

Practice #3: Always Null-Check Objects Returned from a Function Call

Review the 5 lines of code below.

What’s wrong with this picture?

If you said Null Reference Exception you’re right.  Never, ever access any member of any object that has been returned from a function without checking for null.  You should never assume that a function will return an instantiated object.

Never.

Even if you wrote the function you’re calling.

We all work on projects with multiple developers, and at any given time another developer (or even you) may alter the code and end up returning a null object without realizing that there is some expectation that an instantiated object be returned by some callers.

Taking the extra time to type 15-20 extra characters can mean the difference between stable software and buggy, error-prone code.

Conclusion

I wrote this as an e-mail to my team after doing some refactoring and realized that it could be beneficial to a wider audience being that violations of these practices are so common.  I’ve made these mistakes (as I’m sure many of us have) numerous times in the past, so writing this up was a good reminder for me to focus on these points when writing code.

Please feel free to post additions, corrections, questions, and concerns in the comments section below!  The dialogue will benefit all involved!

Thanks to all of the organizers at the NYC Code Camp for an excellent day of learning and networking! This year, it “sold out” in 27 hours! The speakers were excellent and the event was run very smoothly.

I have posted the slide deck (including the demo code) for your viewing pleasure.

Material: