At some point in their career everyone who creates ASP.NET applications has had issues with their site throwing exceptions that aren’t trapped.  We end up displaying a friendly error page at best, and at worst display the yellow ASP.NET error screen of death.  Generally speaking it’s best practice to configure your ASP.NET application to use friendly error pages so that your users aren’t presented with an exception and stack trace that are meaningless to them.

But how do you find out what exceptions are being thrown by users who are not you?  Over the years I’ve created many versions of the same type of code to handle these situations, so last night I created a project on codeplex that I’m calling sigh.net.  Essentially, sigh.net is a provider based unhandled exception handler for ASP.NET applications.  You can download the source at http://www.codeplex.com/sigh.

It’s extremely simple to use and doesn’t require you to change or add any code to your application.  I currently have an email provider created and am in the process of creating a SQL database provider.

Enjoy!

I’ve wanted to work with Silverlight for some time now, though I’ve not had a use for the technology until recently.  I wanted to create tutorial videos for .netSavant to help people learn a bit about the product.  After a bit of searching I found a fantastic code project article written by Karl Shifflett that walks you through the entire process of not only creating a high quality screen capture tutorial, but publishing it as a streaming silverlight video.

Click Here to read the article

To date I’ve only created and published a single tutorial for .netSavant.  I’ve several more planned that will hopefully be a bit more polished as I become more comfortable talking, effectively, to no one.

http://www.dotnetsavant.com/Overview/Tutorials.aspx

Enjoy!

As a followup to my system.nullable vs. tryparse entry, I’ve decided to publish the nullable parser code that I use in the data access system of .netSavant.

Download the C# file (in txt format)

Enjoy!

I’m proud to announce the release of my new code generating addin, .netSavant.  You can download the release candidate on the website from our download page.

The addin will help you create robust ado.net code with an intuitive drag and drop interface.  Additionally it will generate best practice implementations of three (currently) system interfaces:

• System.IEquatable<T>
• System.IDisposable
• System.ICloneable

Currently I am working on the example code that will help to explain how to best use the ado.net code that is generated.  I’m also working on more and better F.A.Q. entries to answer those pesky little problems that come along with learning a new tool.

If there is any functionality that you’d like to see added to the addin let me know; I’ll entertain any reasonable request.

Enjoy!

You’ve struggled through understanding commands and toolbars, pulled your hair out deciphering confusing API’s, and scarred your neighborhood with red-faced screams of frustration as you debug unhandled exceptions that crash visual studio.  After weeks, months or yes even years polishing an addin you still aren’t finished until you create an installer program.

The installer projects available in visual studio make creating an installer a trivial affair; however there are a few things to consider when making an installer for an addin project.

The .addin file

When you create a new addin project in visual studio 2005 or 2008 you will have an xml file in the root directory of your application named YourProjectName.addin.  Opening this file will show you the base structure of the xml that among other things defines the location of your addin assembly.  The trick of installing the addin via an installer project is placing this file in an appropriate location on the user’s workstation as well as modifying the xml to point to the location where your addin is installed.

Addins for visual studio 2005 and 2008 are installed by placing the .addin file in one of several locations on a developer’s workstation.  These locations are managed through visual studio under the Tools > Options > Environment > Add-in/Macro Security options page.  Here you will find a list of paths that visual studio will investigate when it loads to locate various addins that you may have installed.

I caution you on modifying this list; most addins that are written will be installed in one of the default paths specified by here.  If you change these default paths you could easily lose access to any addins that you already have installed.

Where to put your .addin file

For my addin, .netSavant, I use the following line of code during my installation process to generate a file path that the .addin file will be saved to:

Path.Combine(Environment.GetEnvironmentVariable(”ALLUSERSPROFILE”), @”Application Data\Microsoft\MSEnvShared\Addins\DotNetSavant.AddIn”);

This will generate a string value that looks like C:\Documents and Settings\All Users\Application Data\Microsoft\MSEnvShared\Addins\DotNetSavant.Addin (on my laptop).  Again, there are other locations that you could save the file to though I’ve found this one to be the most reliable as far as it’s existence on developer workstations, and being configured in visual studio (its included in vs.net by default).

One complexity to think of; If your user is installing on a non-english version of windows, I’m honestly not sure how to best compose the file save path.  I suppose I’ll have to deal with this eventuality eventually.  Until then I’m going to live in my quiet and warm happy place.

Creating the Installer Class

As with any installer project, if you want to perform some kind of custom installation action you’ll need to create an Installer class somewhere in your application.  This is as simple as creating a new class file and having it inherit from System.Configuration.Installer.  You’ll need to decorate your new class with the RunInstaller(true) attribute and override the Install, Uninstall, and Rollback methods.  These methods will be used to install your .addin file, remove your .addin file when your addin is uninstalled and roll back any installation tasks that you’ve performed if there is an error during the installation process.

Overriding Install

The most complex method of the installation process, this is where you’ll create your .addin file and save it to the path that I’ve mentioned above.

For .netSavant I store my .addin file in the root directory of my project and set its build action to “Embedded Resource”.  This way I can make simple adjustments to the file and it will always be available as a resource of the assembly.  This comes in handy during the installation process, specifically the Install method because I can access the embedded resource, modify the path defined in the Assembly nodes and write the xml contents to disk.

Since the release of vs.net 2008 I’ve updated my own installer to use a block of LINQ that looks something like this:

XDocument linqXmlDocument = null;
string installationPath = base.Context.Parameters["AssemblyPath"];
string addinResourceFile = Assembly.GetExecutingAssembly().GetName().Name + ".DotNetSavant.addin";

using (Stream resourceStream = Assembly.GetExecutingAssembly().GetManifestResourceStream(addinResourceFile)) {
    linqXmlDocument = XDocument.Load(XmlReader.Create(resourceStream));
}
var query = from assemblyNode in linqXmlDocument.Descendants()
    where assemblyNode.Name.LocalName.ToLower().Equals("assembly&quot 
    select assemblyNode;

foreach (XElement assemblyNode in query) {
    assemblyNode.SetValue(installationPath);
}
string addinXml = linqXmlDocument.ToString();

Note the use of base.Context.Parameters["assemblypath"].  The base installer object gives you access to these values to access form information collected during the installation process.  In this case I’m accessing the path that the user specified as the installation directory for the addin.

Overriding Uninstall

When uninstalling your addin, it would be prudent to delete the .addin file from the user’s file system.  Its just common sense that when you uninstall something you should remove everything that was added to the users computer during the installation process.

Overriding Rollback

The rollback method is where you will implement any clean up code that will be run if the installation process needs to terminate before its completion.  Be aware that you’ll not know at what point in the installation process this method might be invoked by your installer package, so any cleanup that you perform should be wrapped inside of try blocks so that the rollback method can execute cleanly.

Back to the Installer Project

Now that you have an installer class it’s a simple matter to wire it up to your installer.  Make sure that your installer references either the build output of your project or the compiled assembly of your project directly.  Then, right click on the installer project and select View > Custom Actions.  You’ll see four folder icons labeled Install, Commit, Rollback and Uninstall.  Simply right click on a folder, click “add custom action” and browse to the assembly that contains your installer class.  Do this once each for the Install, Rollback and Uninstall folders to end up with a configuration that looks something like this:

At this point the installer project is configured to use the custom installation process defined by the installer class.  When the installer is run the .addin file will be successfully written to a legitimate addin path as part of the installation process.  Conversely it will be removed from the file system during uninstallation.

Potential Issues

I hinted earlier that non-english users might have issues installing the addin using my methodology.  This is because I hard-code part of the .addin installation path in English during my install process.  It will be impossible to guarantee that the paths specified by default in visual studio will always be in English, thus we have a potential localization problem to deal with.  Remember that if you don’t see your addin in the addin manager in visual studio you most likely saved your .addin file to a path that is not recognized by the development environment.

Another common issue that is easy to overlook; make sure that you’ve specified a valid path to your assembly in your .addin files’ Assembly node.  If this path is incorrect visual studio will not load your addin.

Enjoy!

Like many addin developers I create options pages in visual studio to handle configuration of my software.  While extremely simple to create these pages, it is not obvious how they should be configured to load with visual studio.  Additionally, the documentation for creating options pages provided by Microsoft describes in detail how to create options pages, though neglects to describe how to make visual studio recognize your options page control.

Fortunately this is extremly simple to wire up.

<?xml version="1.0" encoding="utf-16" standalone="no"?>
<Extensibility xmlns="<a href="http://schemas.microsoft.com/AutomationExtensibility" mce_href="http://schemas.microsoft.com/AutomationExtensibility">http://schemas.microsoft.com/AutomationExtensibility</a>">
  <HostApplication>
    <Name>Microsoft Visual Studio</Name>
    <Version>9.0</Version>
  </HostApplication>
  <HostApplication>
    <Name>Microsoft Visual Studio</Name>
    <Version>8.0</Version>
  </HostApplication>
  <Addin>
    <FriendlyName>.netSavant</FriendlyName>
    <Description>.netSavant is a powerful code generator for the .net framework and Visual Studio.NET.  For more information please visit <a href="http://www.dotnetsavant.com/" mce_href="http://www.dotnetsavant.com/">http://www.dotnetsavant.com</a> </Description>
    <AboutBoxDetails>For more information about .netSavant please visit <a href="http://www.dotnetsavant.com/" mce_href="http://www.dotnetsavant.com/">http://www.dotnetsavant.com</a> </AboutBoxDetails>
    <AboutIconData></AboutIconData>
    <Assembly>Path to .netSavant assembly</Assembly>
    <FullClassName>DotNetSavant.Connect</FullClassName>
    <LoadBehavior>1</LoadBehavior>
    <CommandPreload>1</CommandPreload>
    <CommandLineSafe>0</CommandLineSafe>
  </Addin>
  <ToolsOptionsPage>
    <Category Name="DotNetSavant">
      <SubCategory Name="Adapter Generation">
        <Assembly>Path to .netSavant assembly</Assembly>
        <FullClassName>DotNetSavant.Controls.AdapterSettingsOptionsPage</FullClassName>
      </SubCategory>
    </Category>
  </ToolsOptionsPage>
</Extensibility> 

You’ll notice that I added a ToolsOptionPage node under the root Extensibility node of a standard .addin xml file.  Here you can identify hierarchal categories that will be displayed as visual studio options pages.In this example I’ve added a top level options page called “DotNetSavant” with a sub category named “Adapter Generation”.  Similar to the addin node of the base .addin file, both Category and SubCategory nodes can specify a single Assembly and FullClassName node.  Set the assembly nodes’ inner text to the path of the assembly where your options pages control exists and then specify the fully qualified name of your options pages class in the FullClassName node and your options pages will load with visual studio.Enjoy!

One of the most frustrating things I’ve found when programming addins for visual studio is the inability to globally trap unhandled exceptions the way that you can when  authoring a windows application.  Essentially visual studio intercepts exceptions your addin throws that you neglect to handle.  The worst part is that you don’t get any information about the exception before visual studio crashes!  Its great that Microsoft gets a dump of the crash, but you’re left standing empty handed and scratching your head.

Generally speaking an addin framework should not allow an addin to crash the host application.  It points to either a design concept that I can’t comprehend, a significant oversight in the design of the visual studio addin framework, or simply some kind of interop issue that visual studio doesn’t handle well.

Short of making sure that every block of code in your addin that can throw an exception is wrapped in a try block we don’t have a good methodology for dealing with unhandled exceptions.  While this is a good thing because it forces you to write solid code it can be exceptionally frustrating to to debug unforeseen issues in a production environment.

I’m still looking for a good way to trap or instrument unhandled exceptions in addins that I write, especially in runtime environments.  If I find a good approach I’ll be sure to write about it.

Enjoy!

Now that visual studio.net 2008 has been released developers have a much improved development environment and framework to produce high quality code with.  Extension methods are one of the new framework and IDE features that provides a powerful and clever method of extending objects that you do not have source code for or otherwise can’t directly extend.

Simply put, extension methods allow you to add new methods to the public contract of an existing type without sub-classing, decorating or recompiling the original type.  Prior to this release there were a few options available to solve this problem.

The Decorator Pattern

The decorator is a great design pattern for extending the functionality of an object without sub-classing.  Without going into the nitty gritty details of decorator implementation, essentially you create an object that takes the object that you want to decorate as an argument to your new objects constructor.  Next, you’d create whatever methods you need in your object, accessing the “decorated” object as needed.

Using this pattern, you can extended the functionality of an existing object without subclasing or resorting to libraries of static methods.  Unfortunately this pattern is overkill for minor object extensions or use with value types.  I commonly use this pattern to create read-only versions of objects without having to change the functionality of the underlying object.  Another great example are the various stream objects in the System.IO namespace.

Subclassing

This option is self explainatory.  Simply create an object that inherits from the object you want to extend and add additional functionality.  Unfortunately if your object to extend is sealed you’ll need to use a decorator or the dreaded “helper”.

The “Helper” Object

Nearly every piece of software that I’ve ever supported has one or fifty of these objects.  I’ve seen string helpers, integer helpers, business object helpers, User Interface helpers, and ADO.NET helpers to name just a few.

Personally I don’t care for this technique, though it can be extremely effective for minor object extension or use with value types.  It is susceptible to abuse through massive overloading, lack of commenting and documentation and poor overall design.

Enter the Extension Method

Essentially, these methods are similar to the static methods used in the helper object with one very important distinction; they exist as methods defined as part of the contract of the defined type.

public static class Extensions {
    public static bool InRange<T>(this T value, T lower, T upper) where T : struct, IComparable<T> {
        if(value.CompareTo(lower) >= 0 && value.CompareTo(upper) <= 0) {
            return true;
        }
        return false;
    }
}

In this example I’ve illustrated a very powerful generic method that allows a developer to see if a value falls into a range of acceptable values.  Because it is generic and constrained by the IComparable<T> interface we have the ability to perform a comparison using the CompareTo(T) method exposed by the interface.  Syntactically, this is nearly identical to a standard static method with the exception of the this keyword that decorates the first argument of the method.  The this keyword tells the compiler that this method should be added to structs of type T (the generic type identifier).Using this new method is simple.

decimal price = 12.99;
if(price.InRange<decimal>(1, 49.95)){
    Console.WriteLine("The price specified is within the specified range.");

}else{
    Console.WriteLine("The price specified is not within the specified range.");
}

This particular extension method is configured using the decimal type, though it will work for any struct that implements the IClomparable interface.  What’s important is that visual studio.net 2008 will display this method using intellisense on objects that match both the this (generic) declaration as well as the interface constraint.There are countless applications for extension methods.  They provide a more intuitive method of extending objects without resorting to other techniques that might require extensive design consideration.Enjoy!

As most people are aware the .NET 2.0 framework supports nullable value types.  There are many articles on this topic and a few that address the issues of using nullable types in combination with your ado.net code.  However, most of these discuss the issue of using nullable types in combination with the DbDataReader objects, though few address the conflicts that arise when using a nullable type to set or get an ado.net parameter value.

Prior to .net 2.0 you’d run into this issue when attempting to pass a null string to the value of an input parameter.  In this case most of us would have written conditional code that looked something like this:

string firstName = null;
if(firstName == null) {
    Command.Parameters["FirstName"].Value = DBNull.Value;
} else {
    Command.Parameters["FirstName"].Value = firstName;
} 

Or you could have used a ternary operation: 

string firstName = null;
Command.Parameters["FirstName"].Value = firstName == null ? (object)DBNull.Value : firstName;

With the inception of nullable types you now have to perform the same logic for all parameters that will use a nullable type to set its value.  This isn’t a huge deal really, though it will start to get a bit tedious with stored procedures that have a lot of parameters to assign and downright egregious over the lifecycle of your project.  Fortunately there is a little known (and used) operator that we can use to solve this issue cleanly; the null coalescing operator “??”.  This operator specifies that if the argument on the left evaluates to null then the argument on the right will be substituted.

int? age = null;
Command.Parameters["Age"].Value = age ?? (object)DBNull.Value;

This code is far more readable than the previous conditional statement.  Alternatively you could write a simple method that takes the parameter and the value that you want to assign to it and have the value set using the conditional method above (reusability, huzzah!), but that would either involve an inline method call or a loop over the parameters collection.  These approaches while certainly valid aren’t nearly as compelling as using the coalescing operator.Unfortunately vb.net programmers don’t have a comparable operator and so they’ll have to resort to either the conditional, the ternary or the inline method techniques.

Dim age As Integer? = Nothing
Command.Parameters("Age").Value = IIf(age Is Nothing, DirectCast(DBNull.Value, Object), age)

So far I’ve explained how to handle input parameters, but whats the best way to handle output parameters?  Working from my previous post on system.nullable vs. tryparse we can use the new NullableParser static object and its TryParse methods to set the value of a nullable variable properly from a stored procedure output parameter.

int? age = null;
NullableParser.TryParse(Command.Parameters["Age"].Value.ToString(), out age, true);

Asside from being easy to read and support, this code provides a robust and efficient method for setting the nullable age variable to the value of the Age output parameter using the familiar T.TryParse(string s, out T result) syntax.Enjoy!

I’ve been working on some code tonight and needed to use the trusty struct.TryParse methods available in the core framework.  Unfortunately, the built in TryParse methods choke on nullable types.  After a frightfully short google search I ran across a blog entry from Steve Michelotti describing his approach to writing his own TryParse object for nullable types.  Its pretty sweet though it didn’t meet a specific need that I had, specifically the ability to have the result parameter have its value set to null in cases where the string passed in is in fact null (or empty).

I’ve modified his basic concept with an overloaded method that allows you to specify how the result parameter value will be set.  Passing true to the alwaysNull parameter will always set your value to null if the string sent to the function is null or empty (which is what I’m using for my code problem).  Conversely, passing false will result in the default behavior expected from the TryParse methods.

public static class NullableParser {
    private delegate bool TryParseDelegate(string s, out T result) where T : struct;
    private static bool TryParseNullable(string value, out Nullable result, TryParseDelegate tryParse, bool alwaysNull) where T : struct {
        if(string.IsNullOrEmpty(value)) {
            if(alwaysNull) {
                result = null;
                return false;
            } else {
                result = default(T);
                return false;
            }
        }
        T tempResult;
        bool success = tryParse(value, out tempResult);
        result = tempResult;
        return success;
    }

    public static bool TryParse(string value, out DateTime? result, bool alwaysNull) {
        return TryParseNullable(value, out result, DateTime.TryParse, alwaysNull);
    }
    public static bool TryParse(string value, out DateTime? result) {
        return NullableParser.TryParse(value, out result, false);
    }
} 

Clearly this needs to have the rest of the native value type methods completed, i.e. TryParseInt, TryParseDouble, TryParseBoolean, etc. though it illustrates the basic concept well.

Enjoy!