Custom popup and windows in WPF the MVVM way

In WPF, using the regular window control to launch child windows makes MVVM and separating a View concern from the ViewModel very difficult.

The problem:
The window control works nicely as a shell for your application, however, launching child windows is problematic because the window control cannot be defined in xaml unless as the root element.
So, if you wanted to launch child windows inside a parent window, you lose the ability to declare these in xaml. This loss means you will not be able to bind to properties in your ViewModel from the view for the purpose of opening/closing a window. Instead you end up doing this imperatively in code which means more code, more thought, more work.

Following is what you end up doing in the most minimalistic cases.

MyWindow window = new MyWindow();
window.ShowDialog();

Adding code such as the above means you are forced to make your ViewModel create instances of your Window and launch them when needed. Clearly something you will not appreciate during testing and since this will provide a tight coupling to a Window control in your ViewModel, it is useless to your tests and eventually breaks your pattern.

What would have been nice instead is if we could do the following :

<my:ModalDialogPopup IsOpen="{Binding FirstPopupIsOpen, Mode=TwoWay}"/>

If we could define our window declaratively in Xam as above, then we use the databinding capabilities in WPF and bind to an FirstPopupIsOpen property in our ViewModel, which is what we are after but sadly not currently possible.

The solution 1: A custom Control that behaved like a Window
Writing a custom control was pretty simple as we make use of the existing Popup control in Wpf. The popup control is pretty wild and requires taming but solves this problem.

Some reasons to design our solution around the existing Popup control:

1. The popup control is designed to stay always ontop, which has it's pitfalls but it solves more problems than it brings. More specifically we will want the ability to hide the content under the popup while the popup is in view.
2. The popup control can be positioned in so many ways, however what we are after is the ability to define a set of Left, Top coordinates and this is supported out of the box.
3. The popup control supports a few animations out of the box. This means we can apply a nice sliding or a fade effect with zero effort.
4. The popup control can contain child controls obviously. This is great and serves our purpose very well.
5. Enjoy the beauty of an adorner masking the background beneath the ModalDialogPopup.
   

The solution we end up with is a control like the following :

<my:ModalDialogPopup IsOpen="{Binding FirstPopupIsOpen, Mode=TwoWay}">
            <my:ModalDialogPopup.HostedContent>
                <ContentControl>
                    <Grid Height="200" Width="300">
                        <TextBlock VerticalAlignment="Center" 

                             HorizontalAlignment="Center" FontSize="20">
                            This is the first modal popup
                        </TextBlock>
                    </Grid>
                </ContentControl>
            </my:ModalDialogPopup.HostedContent>
        </my:ModalDialogPopup>

One inherent problem I had not considered while writing this control is that just like the Window control, even with a custom popup control, the limitation to not being able to nest a popup in another popup existed. That's because when showing the child, we are forced to hide the parent for technical reasons that exist in the popup control only(the popup control will always be the top most control).

That means if the parent is larger than the child in dimention, portions of controls in the parent will show and interaction with those pieces becomes possible. When a child popup is launched, we want it to behave as a modal window, so it shouldn't be able to interact with controls in popups beneat it. Sadly the adorner cannot help us here as it cannot cover the “Always ontop” popup.


Ofcourse, the solution to deal with this limitation is to hide the parent when the child is in view, which doesn't help the nesting because if the parent is hidden, then the child will be hidden too! I guess there is a good reason why the Window control in WPF does not allow nesting! Too bad I had to discover this at my own expense.

Even with this shortcomings, in most cases, you can workaround the nesting limitation by designing your solutions with this drawback in mind.

As you can note from the piece of xaml code in the previous code listing above, we have a control that can be defined in our view declaratively that takes content via the HostedContent template. We can also set a Title, and content in it's HostedContent template. In the previous code listing, everytime the property FirstPopupIsOpen evaluates to “true” in our ViewModel, the popup will open.

By default the custom popup provides an OK and Cancel button whose caption/visibility you can set. If you need more customizations you can very well customize its template by providing a custom style. Attemping to supply custom styling is quite simple because the default markup we use is plain and this is intentional since styling is subjective and a trival matter. This enables you to provide custom styling of your own without fighting your way through heavy use of xaml.

If you take a look at the code listing below, all we have is a 3 row grid, one holding the title, the second holding the content you define in the HostedContent template and the last row to hold the OK and Cancel buttons. Simply put, you are in control of the styling and the default style template is prive of any bloated styling markup to distract you.

<ResourceDictionary 

xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
                    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
                    xmlns:local="clr-namespace:WpfPopup.Controls">
    <Style TargetType="{x:Type local:ModalDialogPopup}">
        <Setter Property="Template">
            <Setter.Value>
                <ControlTemplate 

                     TargetType="{x:Type local:ModalDialogPopup}">
                    <Popup x:Name="dialog" AllowsTransparency="True">
                        <Grid x:Name="content">
                            <Grid.RowDefinitions>
                                <RowDefinition Height="20"/>
                                <RowDefinition Height="*"/>
                                <RowDefinition Height="20" />
                            </Grid.RowDefinitions>
                            <TextBlock Grid.Row="0" x:Name="title" />
    <!-- the hosted content -->
                            <ContentPresenter x:Name="contentHost" 

                                Grid.Row="1" Margin="5"/>
                            <StackPanel Grid.Row="2" Orientation="Horizontal" 

                                HorizontalAlignment="Right">
                                <Button Content="Ok" x:Name="buttonOK" 

                                  MinWidth="100" Margin="0,0,5,0" />
                                <Button Content="Cancel" x:Name="buttonCancel" 

                                   MinWidth="100" Margin="0,0,5,0" />
                            </StackPanel>
                        </Grid>
                    </Popup>
                </ControlTemplate>
            </Setter.Value>
        </Setter>
    </Style>
</ResourceDictionary>

And here it is when popped open in the example solution attached to this post :

It's actually quite a minimal control without any bells and whistles and leave the responsibility of styling it in your hands, any way you want. Notice the adorner masking the background and the convenient Ok/Cancel buttons. It's so much simpler to use and easy to test. The amount of work need to set this up compared to a window control (solution 2 below) is minimal.

Surely there is some value for such a control but it is most definitely not a resonable replacement to the Window control entirely, as far as launching child windows is concerned.

Fortunately, the needed work to decouple the existing Window control from the ViewModel could very well be done with a simple interface contract, which brings us to the next solution.

Solution 2 : Decoupling the Window control from the ViewModel
This solution relies on dependency injection to provide proper decoupling of the Window control from the viewmodel. So, we'll need a dependency injection container. You may use any at this point, I'll be using Microsofts Unity. This will also make it a breeze to inject a stub in place of the Window control when Unit testing.

First, let's look at what we're going to construct. It's going to be a series of dialogs. The main Window, and 2 child windows.

The main window :

A child window launched from the main window above :

And finally another child window launched from the child window above :

Ok, now that we know what we are building, lets start. The procedure is simple. We'll start by defining the common functionality we'd normally use from the Window Control in our ViewModel by throwing it into an interface.

public interface IChildWindow
{
 void Close();
 bool? ShowDialog();
 void SetOwner(object window);
 bool? DialogResult { get; set; }
}

We do this for each View that is a window control. The reason is simple, in order to decouple the window from the viewmodel, what we are going to do is use constructor injection. By injecting this dependency in the constructor we can ensure easy substitution with fake stubs during testing and everything will just work.

Let's also decouple the window we plan to launch by adding yet another interface :

public interface IChildWindowNested
{
 void Close();
 bool? ShowDialog();
 void SetOwner(object window);
 bool? DialogResult { get; set; }
}

And finally, the viewmodel:

public class ChildWindowViewModel
{
 private readonly IChildWindow _childWindow;
 private readonly IChildWindowNested _childWindowNested;
 private ICommand _okCommand;

 private ICommand _openCommand;

 public ChildWindowViewModel(IChildWindow childWindow,
    IChildWindowNested childWindowNested)
 {
  _childWindow = childWindow;
  _childWindowNested = childWindowNested;
 }

 public ICommand OpenCommand
 {
  get
  {
   return _openCommand ?? (_openCommand =
    new DelegateCommand(OpenClick));
  }
 }

 public ICommand OkCommand
 {
  get
  {
   return _okCommand ?? (_okCommand =
    new DelegateCommand(OkClick));
  }
 }

 private void OpenClick()
 {
  _childWindowNested.SetOwner(_childWindow);
  _childWindowNested.ShowDialog();
 }

 private void OkClick()
 {
  _childWindow.DialogResult = true;
  _childWindow.Close();
 }
}

As you can notice in the above class, we are passing 2 interfaces in the constructor. The first is the window using this viewmodel : ChildWindow.xaml and the second is the window it will launch : ChildWindowNested.xaml

The relationship between these two windows is a typical parent child relationship, ChildWindow.xaml is the parent, while ChildWindowNested.xaml is the child being launched.

The reason we pass IChildWindow, the parent window in this case is because :

1. We need to tell the child Window we are launching who it's owner is. That way we can nicely position the child window relative to it's parent.
2. As this is the viewmodel of ChildWindow.xaml, we will also want to handle closing this parent window when it's Ok and Cancel buttons are clicked.

The reason we pass IChildWindowNested, the child window we are launching is because:

1. We want to launch this dialog based on an action in ChildWindow.xaml
2. To decouple the window from the viewmodel, because we will be using dependency injection to set up this dependency on the window control.

Now the codebehind for ChildWindow.xaml :

public partial class ChildWindow : Window, IChildWindow
{
 private readonly IUnityContainer _container;

 public ChildWindow()
 {
  InitializeComponent();
  _container = UnityContainerResolver.Container;
  var childWindowNested = 

                             _container.Resolve<IChildWindowNested>();

  DataContext = new ChildWindowViewModel(this, 

                                                childWindowNested);
  Closing += ChildWindowClosing;
 }

 #region IChildWindow Members

 public void SetOwner(object window)
 {
  Owner = window as Window;
 }

 #endregion

 private void ChildWindowClosing(object sender, CancelEventArgs e)
 {
  e.Cancel = true;
  Visibility = Visibility.Hidden;
 }
}

We can setup the viewmodel binding to the DataContext in several ways however doing this in the codebehind of the view as in the sample code above is the most flexible of all solutions especially if your moving beyond the typical blog post samples.

At the end of the day, it's only a matter of opinion and what's important is that there is no dependency impeding you from testing your application. And ofcourse that it does not break your pattern. In our case, it's both convenient as we want to pass a reference of the current window to the viewmodel and at the same time, we want to do it in a very decoupled way to help us test our viewmodel.

Also note that we are hooking into the closing handler and cancelling the default close behavior of the Window control. That's because once a window is closed, we cant reopen it and we'll need to create a new instance of the window.
Certainly this depends on your use case. For me, my requirements are such that I need to reuse the window being closed. This works nicely.

What about dependency injection and how is our Unity container setup ? It's quite simple in this case. For this sample code, I just created a singleton that registers all dependencies with the container :

public class UnityContainerResolver
{
 private static IUnityContainer _container;

 private UnityContainerResolver()
 {
 }

 public static IUnityContainer Container
 {
  get
  {
   if (_container == null)
   {
    _container = new UnityContainer();
    RegisterTypes();
   }
   return _container;
  }
 }

 static void RegisterTypes()
 {
  _container.RegisterType<IMainWindow, MainWindow>();
  _container.RegisterType<IChildWindow, ChildWindow>();
  _container.RegisterType<IChildWindowNested, 

                                                    ChildWindowNested>();
 }
}

That's it. By registering dependencies with a dependency container, it becomes so easy to inject fakes in our viewmodel in place of the real object. In our case, when testing, we can make a different registration by mapping to our fake mock objects and this is relatively simple when using a dependency container :

static void RegisterTypes()
{
 _container.RegisterType<IMainWindow, MockMainWindow>();
 _container.RegisterType<IChildWindow, MockChildWindow>();
 _container.RegisterType<IChildWindowNested, 

                                  MockChildWindowNested>();
}

And MockChildWindow having enough code to satisfy the contract of IChildWindow.

public class MockChildWindow : IChildWindow
{
 public object Owner { get; set; }
 public void Close()
 {
  //
 }

 public bool? ShowDialog()
 {
  return true;
 }

 public void SetOwner(object window)
 {
  Owner = window;
 }

 public bool? DialogResult
 {
  get;
  set;
 }
}

The viewmodel itself only uses methods exposed by the contract so we are safe to use a fake object as above for testing.

I have added a test app containing the custom popup and all code discussed here. Be sure to check it out!
Download sample application

Display and Editor Templated View Helpers in ASP.NET MVC

Templated view helpers simplify your work greatly by allowing you to specify that rendering is required for display or input via Display and Editor templated Helpers respectively without needing to explicitly specify what Html element to map the properties to, in our model.

For example, given the following controller that is passing a model to the view :

// Get: /Home/Edit/1
public ActionResult Edit(int id)
{
 var p = GetPerson(id);
 return View(p);
}

Now, without resorting to Templated View Helpers, in order to display our model for edit, in the view we can attempt to offload the task of rendering an appropriate Html element for a property in our model to a View Helper :

@model MvcLab.Models.Person

@{
    ViewBag.Title = "Edit a person";
}

@using (Html.BeginForm()) {
    @Html.TextBox(Model.FirstName);
}

in the above example, Html.TextBox will output :

<input id="FirstName" name="FirstName" 

       type="text" value="Alessandro" />

By using the Html.TextBox helper, we were able to specify explicitly what input element we wanted mapped to a property in our model.

This is nice but we've had to explicitly state that we wanted a TextBox mappped to the FirstName field.

The same can be achieved by using Templated View Helpers which are yet a more convenient way to associate an Html element to a property in our model :

@using (Html.BeginForm()) {
    @Html.EditorFor(x => x.FirstName);
}

The above piece of code will also render an Html input element :

<input class="text-box single-line" 

      id="FirstName" name="FirstName" type="text" value="Alessandro" />

The output is pretty much the same, but notice that we didn't explicitly state what element to associate to the FirstName property. How this works is that it bases its assumption on the data type of the property and whatever model attribute meta data decorations set on it.

In ASP.NET MVC 2 onwards, there are 3 Editor Helpers that do the same thing with slight differences in usage. @Html.Editor, @Html.EditorFor and @Html.EditorForModel, the first can take a string containing our property name and the second a strongly typed model to property mapping expression and the third will just use the strongly typed model passed to the view by default.

They each provide some flexibility how the Editor Template View Helper is used. We'll be using @Html.EditorFor and @Html.EditorForModel for the remainder of this post.

The following piece of code in the view uses EditorForModel.

@model MvcLab.Models.Person

@{
    ViewBag.Title = "A person";
}

@using (Html.BeginForm()) {
    @Html.EditorForModel();
<p><input type="submit" value="Save" /></p>
}

<p>
    @Html.ActionLink("Back to List", "Index")
</p>

Something as simple as @Html.EditorForModel(); will output an input element for each property in our model. Notice how we didn't loop nor needed to pass the model. Since we're passing the Model in the view, using the default no arguments overloads works just nicely. The above piece of code in the view will output to screen :

While this renders our model, we can see that the output needs a bit more tweaking, for example the field labels are using the property name, this can be tweaked on the model itself using attribute decorations such as :

[DisplayName("First name")]
public string FirstName { get; set; }

Next, the id field is displaying. We'd rather this was not displayed, as this too can be compensated for by providing another attribute decoration on the property such as :

[HiddenInput(DisplayValue = false)]
public int PersonId { get; set; }

Completed person class after the noted changes :

public class Person
{
 [HiddenInput(DisplayValue = false)]
 public int PersonId { get; set; }
 [DisplayName("First name")]
 public string FirstName { get; set; }
 [DisplayName("Last name")]
 public string LastName { get; set; }
 public Address Residence { get; set; }
}

This renders as below :

That's much better, yet now we can note that our complex property Residence, which is a class with its own set of properties, did not render. In order to fix this we can try the following :

@using (Html.BeginForm()) {
    @Html.EditorForModel();
 @Html.EditorFor(x => x.Residence);
<p><input type="submit" value="Save" /></p>
}

<p>
    @Html.ActionLink("Back to List", "Index")
</p>

While this is all great and works by convention, we do eventually lose fine grained control over how each field is rendered in the end. One option is to go back to rendering each field individually eg: @Html.EditorFor(x => x.FirstName) directly in the view, but then if we need to reuse this model in another view, we keep repeating each field over and over again. The extra code in each view also begins to weigh on us and becomes unmaintainable sooner than later.

One way to solve this is to move the logic into a Partial view which can then be reused in a single line of code on other views where we'd want to render a Person model. An even nicer approach is to use convention, again designating Editor and Display templates for our Templated View Helpers. Using this approach will result in providing us with fine grained control over the output. Lets try that now.

Instead of creating the rendering for our model in the view directly, lets move it to a partial view. Following convention for Templated View Helpers, the partial view (template) needs to be stored in the following locations :
/Views/Shared/DisplayTemplates/TemplateName.cshtml and /Views/Shared/EditorTemplates/TemplateName.cshtml.

And since our model is a Person object, we will name our template Person.cshtml for both Display and Editor templates. This is to follow convention as that is the template it will look for based on the type name. There is still more flexibility in defining a template by using meta data attributes UIHint and passing a template name there or by passing a template explicitly in the Templated View Helper itself.

To keep the post simple we are going to use only default convention and setup custom EditorTemplates as the procedure is the same for DisplayTemplates. Along with the article I've included a sample application that shows usage for both Display and Editor templates.

/Views/Shared/EditorTemplates/Person.cshtml :

@model MvcLab.Models.Person

@Html.ValidationSummary(true)
<fieldset>
    <legend>Person</legend>

    @Html.HiddenFor(model => model.PersonId)

    <div class="editor-label">
        @Html.LabelFor(model => model.FirstName)
    </div>
    <div class="editor-field">
        @Html.EditorFor(model => model.FirstName)
        @Html.ValidationMessageFor(model => model.FirstName)
    </div>

    <div class="editor-label">
        @Html.LabelFor(model => model.LastName)
    </div>
    <div class="editor-field">
        @Html.EditorFor(model => model.LastName)
        @Html.ValidationMessageFor(model => model.LastName)
    </div>
</fieldset>

<!-- Note that the Residence property is a complex type for whom
 we've defined a template too in : Views\EditorTemplates\Address.cshtml -->
 @Html.EditorFor(model => model.Residence)

and now a Template for Address, though we could have done it in the Person object itself, as this gives us the flexibility of reusing the Address models rendering in any view.

/Views/Shared/EditorTemplates/Address.cshtml

@model MvcLab.Models.Address

    <fieldset>
        <legend>Address</legend>

        <div class="editor-label">
            @Html.LabelFor(model => model.City)
        </div>
        <div class="editor-field">
            @Html.EditorFor(model => model.City)
            @Html.ValidationMessageFor(model => model.City)
        </div>

        <div class="editor-label">
            @Html.LabelFor(model => model.Country)
        </div>
        <div class="editor-field">
            @Html.EditorFor(model => model.Country)
            @Html.ValidationMessageFor(model => model.Country)
        </div>
    </fieldset>

Note that, upto this point, we have not written a single line of code. What we see so far is all auto generated scaffolding when electing to set a strongly typed class on a partial view in Visual Studio itself. This is much quicker and we're left with remodeling the markup to fit our design requirements.

Below is a screenshot of the Add View dialog that we've used to autogenerate most of the code above.

Next, we are finally ready to reuse these templates in our views :

/Views/Home/edit.csHtml

@model MvcLab.Models.Person

@{
    ViewBag.Title = "Edit a person";
}

@using (Html.BeginForm()) {
    @Html.EditorForModel();
<p><input type="submit" value="Save" /></p>
}

<p>
    @Html.ActionLink("Back to List", "Index")
</p>

Note that the code in our view and every other view that wants to reuse the Person model has gone down to a single method call : @Html.EditorForModel()

and the output :

Final conclusions :
As we have seen, by using Templated View Helpers, we were able to promote reusability of our models rendering and in the process we were not limited by typical black box solutions as we were able to gain fine grained control by defining custom templates for our models.

Best yet, we followed convention over configuration and ended up doing little work with improved productivity and maintainability of our code. Following the same procedure here on this post, we can define custom templates for Display View Helpers too in the same way we provided templates for Editors.

The sample application provided along with this post defines templates for both Display and Editor Helpers.

This is what it all looks like in solution explorer :

Sample application : download
Reference material :
http://msdn.microsoft.com/en-us/library/ee402949.aspx
http://msdn.microsoft.com/en-us/library/system.componentmodel.dataannotations.uihintattribute.aspx

MARS - Multiple Active Result Sets support in SQL Server 2005 and above

SQL Server 2005 onwards supports MARS - Multiple Active Result Sets. MARS enables you to reuse an existing connection to perform operations on SQL Server. This makes MARS a viable alternative to server-side cursors with significant performance boosts. As powerful that may seem it has it's drawbacks so care needs to be taken when using it.


Here's an example from msdn:

SqlCommand cmd = conn.CreateCommand();
SqlCommand cmd2 = conn.CreateCommand();
cmd.CommandText = @"select operation_id, operation_code, product_id, quantity 
      from dbo.operations where processed=0";
cmd2.CommandText = @"update dbo.operations set processed=1 
      where operation_id=@operation_id";
SqlParameter opid=cmd2.Parameters.Add("@operation_id", SqlDbType.Int);
reader=cmd.ExecuteReader();
while (reader.Read())
{
   ProcessOperation();
   opid.Value=reader.GetInt32(0); // operation_id
   //notice how we are trying to execute an update query on the second command
   //this is going to fail miserably because
   //we did not set MutipleActiveResultSets=Yes 
   //on the connectionstring
   cmd2.ExecuteNonQuery();
}

By default MARS is not enabled. So reusing the same connection as the example above will throw an exception of type :

InvalidOperationException, There is already an open DataReader associated with this Connection which must be closed first.

Say hello to MARS :

Enabling usage of MARS is as simple as setting MultipleActiveResultSets=Yes on your connectionString, eg:

<connectionStrings>
    <clear />
      <add name="TyppsDB" 
         connectionString="Data Source=typps-pc;Initial Catalog=TyppsDB;
                 Integrated Security=True;MultipleActiveResultSets=Yes" />
 </connectionStrings>

you can now issue multiple commands on the same connectionstring which can result in a performance boost since opening and closing a connection can be expensive.

When retrieving recordsets, the client has to eager load, meaning consume the resultsets immediately as oppossed to executing the command and not reading the data. Not doing so will cause the server-side buffer(Where sql server is hosted) to hold on to the data in memory and tie up resources, locks, threads etc something you want to avoid.

Instead you want the data to stream to the client as fast as possible as the server returns the resultset without the server holding a large recordset in memory and tying up resources. This is not specific to MARS by the way, but when used correctly with eager loading meaning you consume the data as the command is executed  you can benefit from a significant performance boost as you have the ability to execute more commands and retrieve data seamlessly without the overhead of closing and reopening a connection to Sql Server.

myReader = myCommand.ExecuteReader(); while(myReader.Read())
{
 //consume immediately now, don't wait.
}

Any command that is a SELECT, FETCH, READTEXT, RECEIVE, BULK INSERT (or bcp interface) or Asynchronous cursor population can take full advantage of MARS.

What this means is that with MARS enabled, each of these commands listed above are defined in terms of interleaved executions, allowing them to be processed atomically within the same connection but with the ability to interleave, this means they can resume execution from the points where they were suspended if at all suspended.

For instance, INSERT and UPDATE cannot take advantage of MARS. Now, consider a long running INSERT or UPDATE operation followed by a SELECT statement, all executing within the same connection. Such an operation will suspend the SELECT command until the UPDATE or INSERT has completed and then resume the SELECT operation.

Consider reversing the above example where you had a SELECT followed by an UPDATE or INSERT operation within the same connection. Even in this case, if the UPDATE or INSERT command are issued while the SELECT is executing, then the SELECT command will interleave and as such become suspended until the INSERT or UPDATE complete and only after completion of the UPDATE or INSERT operation, will it resume execution.

This is because the SELECT command can take advantage of MARS and has the ability to resume from the point where it was suspended making it an interleaved execution.

Lastly, note that there are some intricacies when using transactions with MARS. You will need to workaround using recommendations provided eg: by using batch-scoped transactions.

References :
http://msdn.microsoft.com/en-us/library/ms345109(v=sql.90).aspx
http://msdn.microsoft.com/en-us/library/ms174377.aspx

.NET exceptions, error handling for the exceptional case

The tip of the day consists of, in making sure to use a try/catch block to trap individual exception types such as SqlException which is specific whereas Exception being more general.

For instance, imagine you are connecting to a database, it's quite common to experience a connection failure that you might not expect. So it makes sense to try to handle any unexpected connection failures.

First, try and discover the SqlConnection members class on msdn and drill down to the SqlConnection.Open method, there's a section including the exceptions that the open method may throw and we find two :

InvalidOperationException and SqlException with the specifics on what the conditions are when these exceptions are thrown.

Similarly, we can write code likewise :

try
{

 //connect to db and do something useful
}
catch(InvalidOperationException invalidException)
{
 // specific exception
 // usually occurs when trying to open a conenction
}
catch (SqlException sqlexception)
{
 // specific exception
 // will occur when opening a connection
}
catch (Exception exception)
{
   // lastly the general exceptional case will kick in
   // could be anything that the first two exceptional cases didn't catch.
}

Note how Exception ( the mother of all exceptions) is handled last and instead we branch out by starting with more specific exceptions, InvalidOperationException and SqlException. This allows us to catch more specific exceptions and then move on to the more general exceptions. This is a good practice.

Lastly, when logging your exceptions, use the default implementation of ToString of the exception thrown to obtain the name of the class that threw the current exception, the message, the result of calling ToString on the inner exception, and the result of calling Environment.StackTrace with line number etc.

Final notes:
If an exception can be handled programmatically without resorting to try/catch then investigate that route first. Handle the exceptions that are relevant to your code, throw back everything else. Read Best Practices for Handling Exceptions

References :
http://msdn.microsoft.com/en-us/library/seyhszts.aspx
http://msdn.microsoft.com/en-us/library/system.exception.tostring.aspx
http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection_methods(v=VS.71).aspx
http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.open(v=VS.71).aspx

Silverlight or Html5 - from A .NET developer perspective.

Html5 vs Silverlight for the .NET developer :

If you are already invested in .NET, then you have been honing a particular set of skills for the past decade. This puts you at a position where it is difficult to favor Html5 simply because you lose some agility and sometimes this may make all the difference.

Since MIX11, there is much debate with regard to Html5 vs silverlight. And developers continue to ask, what should I use. When I try to make a decision on the technology to use and power my applications the following facts helps me consolidate my ideas and beliefs further and this is also my current state of mind.

• Silverlight is cross browser / platform

Note: This is great news if we are comparing silverlight to wpf but when compared to html5, we can agree on one thing. Html5 will be available on many more devices so it's not actually a pro for silverlight however, it's good to note that silverlight runs on those devices where it counts :

All major browsers on both the mac and windows are supported. *nix support through Novell mono moonlight, which currently lags a bit behind but don't let this be a show stopper for you. You can easily develop a secondary slim version that works for moonlight which currently fully supports version 2.0 of silverlight and one that supports 3.0 is almost complete.

Depending on the features your using, you might even be able to provide support for your application in it's full glory or perhaps with a minor workarounds if this audience is very important to you. Finally you also get to target the mobile platform wp7(Currently html5 support is lagging on wp7).

• Strongly typed languages support (c#, vb.net). Unlike losely typed languages, you will benefit greatly from compile time error checking, and many language specific features.

• Easy deployment --your compiled silverlight assembly includes the compiled code and xaml files for all your pages in your application. These files are embedded as resources and are compressed. While this is the default, it's also very flexible, meaning you can split your code in modules that can be dynamically downloaded by your silverlight application upon request. Tip: Prism is a great library if you want to benefit from modularity among other things in your silverlight apps.

• First class IDE support. Not only are you benefiting from superb IDE support for both designing your applications in expression blend while doing the development in visual studio, but your way of working changes very little if you are already a developer in the microsoft space. Note that we will soon see some pretty good IDE support for Html5 as well, so this particular con for html5 won't hold true for very long.

• Reuse existing known code patterns. Patterns and practices have been gathered over the years and are a way for us to reuse "experience" in our development. Some are our own, some are industry known patterns and practices. On the other hand, Javascript too has been around for a very long time and they too have adopted their own set of patterns and practices, but clearly as a .NET developer, with silverlight, you don't have to relearn anything. I do heavy development in both c# and javascript, so this point is pretty moot for me, however, it's an important decision maker when chosing the right technology.

• Reusing existing code --You already have existing code written for the .net framework, be it code that simply executes on the server or perhaps a WPF desktop application. Porting this code to run on the client instead in silverlight is much easier than rewriting it from scratch in javascript.

• As a web developer, you write client-side code for Silverlight in the same language that you use for server-side code (such as C# and VB), similarly you will be able to leverage the same objects you use on the server, so : generics, LINQ, Lambda, collections and many more even though only a subset of the .NET framework classes.

• IE8, 7 and 6 support is important to you because you still have a lot of clients on these browsers. This is a given in silverlight, yet these browsers currently do not support the html5 featureset. Using another third party plugin such as google frame to target content to this user group ( also currently constituting the majority) is out of the question. Why should the largest portion of your userbase be served in downlevel?

• Install and upgrade --fully managed install and upgrade mechanism in place for Silverlight. This means as new versions of silverlight are made available, we can start using them in our applications right away and based on the runtime version of silverlight your applications are built against, that version will be used or the user will prompted to download and install it. This is fully managed by Microsoft and you do nothing in this department other than some minimal configurations such as MinRuntimeVersion and so forth.

Counter this with Html5, where features that constitute Html5 are supported at the discretion of the browser vendor. This means each browser vendor will pick up the feature they think is useful or important and will implement it. This makes it quite easy to find a feature that works in one browser but doesn't work in another or simply a feature that works in the latest versions of the browser while your left working around to compensate for the feature loss in older versions.

In fact not too long ago whatwg has officially moved to a non-versioned model where Html5 is simply known as Html. This move by whatwg makes sense to me also because no browser currently supports the entire featureset of Html5 and therefore the name is misleading. Infact no browser ever supported html4 completely. Silverlight, being a plugin does not suffer from this lack of feature uniformity across browsers/devices.

Final notes : 
One thing is sure, Html5 has been a hot topic for a while now and with the release of ie9 it has gotten even hotter. This is a fresh area with room for plenty of innovation and new business opportunities to tap into. Like all new things, there's a gold rush. Everybody is pushing out web applications that uses shiny new Html5 features, because that is the current trend and there's lots of room for investment. This is a large market segment with a wider audience.

As a .NET developer, if you are selling development tools, you are no longer confined to Microsoft developers, instead suddenly the web is your oyster. Lastly, it makes the headlines to invest in Html5 at this early stage, which can quickly translate to free marketing for you. That's someting to consider as well.

So, in the end, which one is the better? Today I'm confident about my silverlight investment because it made sense for my application and it's needs. However on a different project, I may sing a different tune all together. Sadly, there is no better choice. You know your application, only you know what it needs.

For instance I developed Abmho based on need. I couldn't find a proper syntax highlighter on the web that simply worked, that wasn't riddled with adverts and one that didn't require me to make a request to the server everytime. Soon this became irritating and so I decided to make one myself.

It was important that my syntax highlighter executed in the browser as an application and was fast and responsive. I also wanted to complete development fast and I have a .NET background. I also already had a syntax highlighter library in c#. Rewriting this library in javascript would have simply taken forever. It was certainly not worth the effort.

This move allows me to ship a wpf version (currently in the works) that requires subtle minimal changes to get working as a full fledged desktop application that I will be making available soon since Silverlight is a subset of Wpf. All this wouldn't be possible if I had gone the Html5 route.

Setting up a ConnectionStrings in .NET

ConnectionStringBuilder :

Tip for today is the ConnectionStringBuilder class. This is quite an unknown class but can result very useful in building your connectionstring. Normally, you'd take a connection string and pass it directly to your connection objects such as SqlConnection or DbConnection classes directly.

Quick example from msdn :

private static void CreateCommand(string queryString,
    string connectionString)
{
    using (SqlConnection connection = new SqlConnection(
               connectionString))
    {
        SqlCommand command = new SqlCommand(queryString, connection);
        command.Connection.Open();
        command.ExecuteNonQuery();
    }
}

As you can note from this classical example above, the connectionstring is passed directly to the SqlConnection object's constructor. While this is fine, any error in the connection and it's quite easy to make a mistake, won't be known until the connection is opened.

Further more, if you want to pass some additional values, or modify existing values in the connectionstring it can be time consuming and again error prone and more effort than you want to invest.

Say hello to the ConnectionStringBuilder. What this class does for you is that it facilitates parsing a connection string and also provides named properties you can simply set in code or whose values you want retrieved. A classic code example from msdn itself :

using System.Data;
using System.Data.SqlClient;

class Program
{
    static void Main()
    {
        // Create a new SqlConnectionStringBuilder and
        // initialize it with a few name/value pairs.
        SqlConnectionStringBuilder builder =
            new SqlConnectionStringBuilder(GetConnectionString());

        // The input connection string used the 
        // Server key, but the new connection string uses
        // the well-known Data Source key instead.
        Console.WriteLine(builder.ConnectionString);

        // Pass the SqlConnectionStringBuilder an existing 
        // connection string, and you can retrieve and
        // modify any of the elements.
        builder.ConnectionString = "server=(local);user id=ab;" +
            "password= a!Pass113;initial catalog=AdventureWorks";

        // Now that the connection string has been parsed,
        // you can work with individual items.
        Console.WriteLine(builder.Password);
        builder.Password = "new@1Password";
        builder.AsynchronousProcessing = true;

        // You can refer to connection keys using strings, 
        // as well. When you use this technique (the default
        // Item property in Visual Basic, or the indexer in C#),
        // you can specify any synonym for the connection string key
        // name.
        builder["Server"] = ".";
        builder["Connect Timeout"] = 1000;
        builder["Trusted_Connection"] = true;
        Console.WriteLine(builder.ConnectionString);

        Console.WriteLine("Press Enter to finish.");
        Console.ReadLine();
    }

    private static string GetConnectionString()
    {
        // To avoid storing the connection string in your code,
        // you can retrieve it from a configuration file. 
        return "Server=(local);Integrated Security=SSPI;" +
            "Initial Catalog=AdventureWorks";
    }
}

Note: the same applies for the generic non SqlClient class DbConnection and you'd use the apposite DbConnectionStringBuilder class.

Lastly, retrieving the connectionString itself can be facilitated by using Server explorer, after having made the connection to the database visually in VS.NET you need to select your database in solution explorer and right click - Properties. From the property grid you can see the connectionstring VS.NET is using. That is the connectionstring you want.

Alternatively you can use create a DataLink and copy the autogenerated connectionstring created by the DataLink. Follow the url in the references section below.

Reference material :
http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnectionstringbuilder.aspx
http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.aspx
http://msdn.microsoft.com/en-us/library/ms718102(v=vs.85).aspx ( DataLink )
http://msdn.microsoft.com/en-us/library/33wwc2yw(v=VS.80).aspx (Server Explorer)

Typps 3.1 released

A new 3.1 stable release is available for download.