.NET, Archive, Software Design

Software Design Tip of the Fortnight: Tip #2

Jason / December 20, 2008

For this second installment of Software Design Tip of the Fortnight I want to talk a little about exceptions. Exceptions in .NET provide an excellent means of handling errors. We all know not to use exceptions for flow control, but there are many other ways to abuse exceptions.

Abusing exceptions can be anything from throwing the base Exception class, to throwing more than just exceptions. But the most common abuse of exception handling is to simply suppress them. We have all seen applications that do something similar to:

SomeBusinessObject bo = SomeBusinessObject.LoadWithId(4);
try{
    bo.SomeIntValue = int.Parse(txtSomeTextField.Text);
}catch{
   //the value wasn't int... so ignore it.
}
bo.Save();

The problem with suppressing exceptions is that most components don’t just throw them for the fun of it, there is some underlying reason why the exception was thrown in the first place.

The above example appears innocent enough. Int32’s Parse method throws an exception if it cannot parse the input string. But what if in the future another developer decides that the business object’s SomeIntValue needs a certain business rules that limits the acceptable values.

public class SomeBusinessObject{ //other class code public int SomeIntValue{ get{ return _someIntValue; } set{ if(value < 0) throw new BusinessRuleException("Invalid value for SomeIntValue."); _someIntValue = value; } } } read more

Archive, ASP.NET

Comparing Deployed ASP.NET Sites With NDepend

Jason / December 15, 2008

Few things compare to the experience of inheriting an existing software project when (for whatever reason) none of the original developers are with the company. I have been in the situation a couple of times myself and it never fails, you inherit the code base just in time to fix a bug or implement a new feature.

One of my concerns whenever this happens is whether the deployed version of the website matches the latest version in source control. In an ideal world the source control system would have been tagged when the last deployment took place and their would be little guess work. But live is seldom this ideal. In reality their is often no indication of when and what was last deployed into production short of the binaries residing on the server.

Fortunately NDepend has a lot of powerful features that help with this exact predicament. For those of you who have never used NDepend it is a very powerful static code analysis tool for .NET, and contains more features than I could possibly do justice to here. For those interested Scott Hanselman wrote a great review here, and there are also several screencasts on the NDepend website.

Comparing Binaries

To demonstrate this I am going to compare my currently deployed blog (which I happen to know is running dasBlog version 2.3) to a known version of dasBlog 2.2. To get started make sure you have local copies of both sites you want to compare, and fire open your copy of NDepend.

To compare source files you do not need to even create a project file. You simply need to select “Choose Assemblies or Analysis to Compare” from the “Compare” menu of the Visual NDepend GUI.

For this demonstration I am going to compare only the newtelligence assemblies shipped with dasBlog, but you will want to compare the assemblies to represents you own custom code. For example, if you consumed the NHibernate ORM you wouldn’t want to necessarily compare NHibernate.dll.

Once you have selected the assemblies you want to compare and clicked “OK” NDepend will begin the process of analyzing the assemblies. Depending on the number and size of the assemblies this could take a few moments. But as a reward for your small wait you will be soon greeted by more than enough code metric to keep even the most scrutinizing of people happy.

Mining The Results

Once the code analysis has been performed we can begin the task at hand of finding the differences between the two versions of the site. For this task their are two areas of the main screen that are of concern. The Class Browser and the CQL Queries window.

The Class Browser is very intuitive for anyone familiar with Visual Studio and simply provides a high level overview of Assemblies, Namespaces, and Types. For instant gratification NDepend kindly provides via a context menu option. From the Class Browser right-click on one of the assemblies you compared and select “What was changed?” and then “SELECT METHODS FROM ASSEMBLIES … WHERE CodeWasChanged”. In place of the Class Browser you will see a list of methods that are different between builds.

Behind the scene NDepend issue what it calls a CQL (Code Query Language) query against its internal database it compiled during the code analysis. This database contains all kinds of helpful information about your source code. Using CQL we can do much more than just select methods that have changed. We can apply any number of constraints to what is returned. For example, you may not be concerned about unused methods even if they do differ. Using CQL you can word that like:

SELECT METHODS FROM ASSEMBLIES "newtelligence.DasBlog.Web" WHERE CodeWasChanged AND ( MethodCa > 0 OR IsPublic OR IsEntryPoint OR IsExplicitInterfaceImpl OR IsClassConstructor OR IsFinalizer ) read more

.NET, Archive, C#

.NET Extension Methods

Jason / December 1, 2008

New in .NET 3.5 is a feature called extension methods. Extension methods allow developers to extend classes with their own instance methods. This is a concept often called mix-ins in other languages.

Take for example the following piece of code.

public static class StringHelpers{
	public static bool IsShort(string s){
		if(s == null || s.Length < 10)
			return true;
		return false;
	}
}

In the above, trivial, example we see a helper class that has a static method to determine is a string is “short”. While the example is ridiculous, it is helpful in illustrating the root desire for extension methods. Often times our source code is littered with helper class very similar to the above one.

Also littered around your code is undoubtedly usages of such utility classes. So, for example, you would have usages such as:

string name = "Jason"; if(StringHelpers.IsShort(name)){ //do something } read more

Archive, Blog

Moving dasBlog to IIS7

Jason / November 17, 2008

Some of you may have noticed that several pages on this blog have been generating 404 errors for the past week or so. This was due, in part, to my recent migration to a Windows Server 2008 (IIS7) machine. Most of the blogs service interruption could have been avoided had I properly "test drove" the website after the migration. But in my haste I simply transferred the files to the remote server, hit the home page, and called it a night. Little did I know that most of the blogs content was unreachable. read more

.NET, Archive, Visual Studio

Acquiring a Public Key Before Compiling

Jason / November 17, 2008

In the past I have talked about the The Wonders Of InternalsVisibleTo and how such a simple attribute allows for internal components to be shared between different assemblies, opening the door to greater code separation and dependency control. In that previous article I illustrated how you can use the tool that ships with Visual Studio to get the public key signature from one of your existing dlls. read more

Archive, NHibernate

Migrating to NHibernate 2.0

Jason / November 8, 2008

The NHibernate documentation is often very handy when working on NHibernate based project. I keep PDF copies of the documentation to NHibernate 1.0 and 1.2 on my hard drive as I never know when I will need to reference them. Unfortunately the NHibernate team seems to have dropped the ball in regards to version 2.0. Not only does the NHibernate website lack any documentation on version 2.0, the website acts as if version 2.0 hasn’t even been released yet. Unlike previous updates to the framework, version 2.0 represents a complete refactoring of the code base with many namespaces and objects either removed or renamed. Despite the lack of official documentation there are still several resources to help you migrate your existing NHibernate 1.2 application to NHibernate 2.0.

List of breaking changes

The NHibernate forum has a thread discussing the breaking changes between version 1.2 and an alpha pre-release of 2.0. For the complete list check out the forum, however here are the ones you will be most likely to face.

Problem: The NHibernate.Expression namespace no longer exists.

Overview: Most notable of the items formerly kept in this namespace was the Expression object used when creating ICriteria. Fortunately the object still existing in the NHibernate.Criterion namespace.

Solution: Replace all “using” statements to reflect the namespace change.

//using NHibernate.Expression; //this line is no longer needed in NH 2.0
using NHibernate.Criterion;    //replace it with this line.

Problem: The nhibernate configuration section (most likely in your web.config or app.config) is no longer used.

Overview: NHibernate 2.0 no longer looks at the configuration section named nhibernate, instead it looks for a configuration section called hibernate-configuration (notice the lack of an “n” in hibernate). Moreover the configuration section wasn’t simply renamed, it bears and entirely different schema.

Solution: In short the entire configuration section is going to have to be reworked slightly.

For starters your configuration section declaration will have to change its name and type:

<configuration> <configSections> <section name="hibernate-configuration" type="NHibernate.Cfg.ConfigurationSectionHandler, NHibernate" requirePermission="false"/> </configSections> read more