.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

.NET, Archive, C#

Silverlight Progress Bar

Jason / October 13, 2008

Silverlight 2 provides an attractive platform for creating Rich Internet Applications, however when first getting started both the oddities of the layout model and the strange absence of certain controls and class and be puzzling.

One such puzzling absence from the Silverlight tool chest is a progress bar control. WPF has a progress bar, WinForms has a progress bar, but not Silverlight. Fortunately implementing one is not that hard and provided a great introduction to Silverlight’s layout model.

Silverlight and layers

Unlike ASP.NET, and many other forms technologies, Silverlight uses a multiple layer positioning system. The Canvas control is especially useful for allowing multiple controls to be layered.

Take for example this simple block of XAML:

<Canvas x:Name="LayoutRoot" Background="WhiteSmoke"> <Rectangle Width="60" Height="60" Fill="Green" /> <Rectangle Width="60" Height="60" Fill="Gray" /> <Rectangle Width="60" Height="60" Fill="LightBlue" /> </Canvas> read more

.NET, Archive, ASP.NET, aspNETserve, C#

Community Coding Contest

Jason / October 1, 2008

Developing an open source project is a very rewarding experience. But sadly (as an open source developer that is) open source projects rarely get the feedback they deserve. Often the developers only hear feedback from their users when their software is broken, because of this it is often difficult to know when an author’s work is truly appreciated. read more

.NET, Archive, ASP.NET, aspNETserve, C#

aspNETserve 1.3: What’s New

Jason / August 19, 2008

As I mentioned in my last post, aspNETserve 1.3 has just been released. And with it comes some exciting changes. Here is an outline of some of the most notable changes:

HTTP Persistent Connections

aspNETserve’s goal is to target version 1.1 of the HTTP protocol, and prior to version 1.3 of aspNETserve it had an obvious shortcoming in that goal. It did not even attempt to keep “Keep-Alive” (aka, persistent) connections around. The server naively closed the connection after each request.

The new aspNETserve.Server object in version 1.3 has full support for persistent connections, and with it introduces a couple of new properties:

MaxConnections

This property represents the maximum number of simultaneous connections allowed. Once the maximum amount has been reached additional requests will be declined.

KeepAliveRequestTimeout

A period of time (in milliseconds) that aspNETserve will wait for subsequent communications on a previously established connection.

Windows Service Server

A Windows service called aspNETserve.Ice (pun intended) allows aspNETserve to process requests in the background. Additionally, this allows request processing without a user having to first login and launch the SimpleServer UI.

aspNETserve.Ice reads it configuration from an XML file whose schema is define on the wiki page ConfigSchemaOverview.

Here is a simple example of what the XML file looks like:

<?xml version="1.0" encoding="utf-8"?>
<server xmlns="http://aspnetserve.googlecode.com/svn/tags/Release%201.3/aspNETserve/Configuration/Xml/aspNETserve.config.xsd">
        <application physicalPath="c:\temp">
                <domain name="www.example.com" virtualPath="/" />
                <endpoint ip="127.0.0.1" port="80" />
                <endpoint ip="127.0.0.1" port="443" secure="true" />
        </application>
</server>
read more

Archive, ASP.NET, C#, Visual Studio

ASP.NET MVC: A Guided Tour

We’ve all read about what MVC is, but how does it really work? What are the nuts and bolts that make that MVC magic happen? Fortunately Microsoft has released the source code to ASP.NET MVC and we can read the details in all their glory. But if you are like myself reading source code is something far different than truly understand how an application works. Luckily since the source code has been released we can do much more than read it, we can use the debugger to step through it.

The debugger in Visual Studio is an extremely helpful tool for the modern developer. I often use the debugger as my first debugging route for development code. Interestingly enough we can put that same debugger to use to walk through ASP.NET MVC to get a better feel for how it operates.

The first thing we need to do is download the source code to ASP.NET MVC and compile it with debugging enabled. The source code can be downloaded from it’s CodePlex page. The download contains a Visual Studio 2008 project. Simply open the project and do a rebuild. Once completed you should see four files in the bin directory located directory in the folder you extracted the downloaded source code into.

Of those files we are only interested in two of them. System.Web.Mvc.dll and System.Web.Mvc.pdb.  Make note of where those files are located on your computer, because we will need to add a reference to those shortly.

In a new instance of Visual Studio lets create a new ASP.NET MVC application. The first thing we need to do is to delete the reference to System.Web.Mvc. Expand the references folder, and right-click System.Web.Mvc and select remove.

With the reference to System.Web.Mvc removed you will now need to add it back. Only this time instead of referencing the DLL that shipped with the ASP.NET MVC we will reference the DLL that we just compiled. By right clicking on the references folder and selecting “Add Reference…” you will be given the option to browse for the reference. Simply navigate to the path I asked you to remember earlier and select the System.Web.Mvc.dll file and click “OK”.

Now we are all ready to start debugging the innards of ASP.NET MVC. For starters navigate to the pre-generated HomeController and put a break point on the first line of the Index method.  Now start the site with debugging enabled.

Once everything gets done compiling and the application starts your Visual Studio instance should immediately stop at your break point.

At this point in your Call Stack window you should see entries for System.Web.MVC.DLL, and those entries should be in black (not gray). This means that Visual Studio has the debugging information that it needs to show us source code for those methods. This is precisely what we were trying for, Visual Studio will now all us to step through the ASP.NET MVC code in a very similar fashion to our code. Lets start by analyzing the call stack in detail.

In the call stack we see the following:

MvcApplication1.DLL!MvcApplication1.Controllers.HomeController.Index() System.Web.Mvc.DLL!System.Web.Mvc.ControllerActionInvoker.InvokeActionMethod(...) System.Web.Mvc.DLL!System.Web.Mvc.ControllerActionInvoker.InvokeActionMethodWithFilters.AnonymousMethod(...) System.Web.Mvc.DLL!System.Web.Mvc.ControllerActionInvoker.InvokeActionMethodFilter(...) System.Web.Mvc.DLL!System.Web.Mvc.ControllerActionInvoker.InvokeActionMethodWithFilters.AnonymousMethod() System.Web.Mvc.DLL!System.Web.Mvc.ControllerActionInvoker.InvokeActionMethodWithFilters(...) System.Web.Mvc.DLL!System.Web.Mvc.ControllerActionInvoker.InvokeAction(...) System.Web.Mvc.DLL!System.Web.Mvc.Controller.Execute(...) System.Web.Mvc.DLL!System.Web.Mvc.Controller.System.Web.Mvc.IController.Execute(...) System.Web.Mvc.DLL!System.Web.Mvc.MvcHandler.ProcessRequest(...) System.Web.Mvc.DLL!System.Web.Mvc.MvcHandler.ProcessRequest(...) System.Web.Mvc.DLL!System.Web.Mvc.MvcHandler.System.Web.IHttpHandler.ProcessRequest(...) read more

.NET, Archive, ASP.NET, aspNETserve, C#

aspNETserve Update

It has been a while since I have mentioned anything about aspNETserve, so I figured it was due time for an update. Since the last update in December of 2007 there wasn’t any activity until recently. Between being distracted with a plethora of personal and professional obligations the project took a back seat. read more

Archive, C#, Software Design

Testing Software Contracts Using ContractTest

Contracts, both explicit and implied, are key in designing a working software system. An example of an explicit contract in C# would be the implementation of an interface, while an implied contract would be something along the lines of all business objects have default constructors. Contracts of both types are critical to the success of a software system, but how do you test for and enforce these contracts?

Explicit contracts are often enforced by the compiler and are not nearly as fragile as implied contracts. Using the ContractTest testing framework you can write test cases for many common implied contracts. You can incorporate ContractTest assertions directly into your existing unit tests. For the following examples I will be using NUnit syntax, but you could use most any other unit test framework.

For example, assume you want to test for the presence of a publicly accessible default constructor on one of your business objects. Such a test using ContractTest would look like.

using ContractTest.Assertions; using NUnit.Framework; using MyNamespace.BusinessObjects; [TestFixture] public class SampleTests{ [Test] public void Test1(){ ContractAssert.Type.HasPublicDefaultConstructor<BizObjectA>(); } } read more

Archive, C#, NHibernate

NHibernate Formula Properties

Jason / February 19, 2008

One often overlooked feature of NHibernate is the use of formula properties. Formula properties are properties that do not map to columns in the database, but instead are mapped using raw SQL queries.

The formula is mapped in the NHibernate mapping file using the same property element that normal properties use, just replacing the column keyword for the formula keyword.

<property name="FormulaPropertyName" formula="SQL STATEMENT" /> 

The basic idea is that when NHibernate loads your object it will issue your custom SQL at the same time, allowing for complex read-only properties to offload their work to the database.

For example, assume you have an class representing an order on an e-commerce website. An order is typically composed of line items, and a common question to ask the order as a whole is “what is your subtotal?”. Without weighing the pros and cons of such a decision assume that you do not want to store the subtotal as a field on the order table.

A perfectly acceptable solution would be to have a read-only property as such:

public decimal SubTotal{ get{ decimal subTotal = 0; foreach(LineItem li in this.LineItems){ subTotal += li.ExtendedPrice; //i.e., units ordered times unit price. } return subTotal; } } read more