# Sunday, November 1, 2009

Back To Basics

I remember how excited I was in the early days of .Net when I discovered how easy it was to write a Windows Service. I probably wrote a half dozen services that first year. But I hadn't written one in years and (oddly) hadn't even heard anyone talking about writing a Windows service in as long.

Perhaps the reason one hears so little about Windows Services is because the way we write them has changed so little since .Net 1.0.

A Windows Service is not dependent on a particular user being logged in. In fact, a Windows Service can run if no one is currently logged onto the machine on which it is running. This makes a Windows Service inherently more secure than a Windows Forms application or a Console application because you can run it on a server, set credentials and log out of the console.

To create a Windows Service, open Visual Studio and select File | New Project. In the Project Types tree of the New Project dialog, expand either Visual C# or Visual Basic node and select the Windows node. In the Templates area of the dialog, select Windows Service. Set the Name, Location and Solution as you would any other project and click OK to create the project.

By default, a Windows service contains one class named "Service1". The name of this class isn't really important because it isn't called externally, so I always leave this default name. If you double-click this class in the Solution Explorer, it opens in a Design view. Select View | Code to switch to a code view of the class. Notice that the class inherits from ServiceBase and that it contains overrides of two methods: OnStart and OnStop.

As you might guess, OnStart contains code that runs when a service starts and OnStop contains code that runs when a service stops. I put setup code into OnStart, such as initializing variables that my service will need. I generally put very little code in the OnStop method, but this is where cleanup code goes.

Services are designed for long-running processes and are meant to stay in memory for a long time -sometimes months or years. Most of the services I've written use a timer object to periodically wake up and perform some check and respond if that check finds something. For example, you might check the contents of a folder every 10 minutes and, if an XML file is found in that folder, move it to a new location and parse it appropriately.

For example I  recently wanted a program that would check an error log every few minutes and automatically attempt to correct any errors found there. I had already written a class to read the error log, retry each error found and remove from the log any errors that were retried successfully. So my service only needed to call this class every 5 minutes. I used a timer class to do this. A partial code listing is shown below.

protected override void OnStart(string[] args)
    // Every 30 seconds, a timer will do some work
    timer1.Elapsed += new ElapsedEventHandler(timer1_Elapsed);
    timer1.Interval = 30000; 
    timer1.Enabled = true;


protected override void OnStop()
    timer1.Enabled = false;

private void timer1_Elapsed(object sender, EventArgs e)
    // Wake up and perform some action.
    // [Cpde omitted]

I prefer to keep the code in the service to a minimum and abstract complex logic to a separate assembly. This makes testing and debugging easier. So the omitted code in the above example would call out to another assembly to do the hard work.

Installing a Service
In order to install a service, you will need to add an Installer class. Select Project | Add New Item; then select the Installer Class template. This class also opens in the designer by default. Select View | Code to see the code. The Installer class inherits from Installer, but you don't need to override any methods.

You can set some attributes of the service to make it easier to find. The Installer class's constructor is the place to do this. Instantiate a new ServiceInstaller and ServiceProcessInstaller, set properties of these objects, and add these objects to the Installer Class to affect the Windows Service when it is installed. Common properties that I like to set are

Class Property Description of property
ServiceInstaller ServiceInstallerServiceName The name of the service. This must match the ServiceName specified in WindowsService1.
ServiceInstaller DisplayName A name displayed in the Services Manager applet.
ServiceInstaller Description A description displayed in the Services Manager applet
ServiceProcessInstaller Account A built-in account under which the service will run.
ServiceProcessInstaller Username The name of the user account under which the service will run.
ServiceProcessInstaller Password The password of the user account under which the service will run.

For the ServiceProcessInstaller, you will set either the Account property or the UserName and Password properties. Typically, I set the Account property to System.ServiceProcess.ServiceAccount.LocalSystem, so that it can be installed. This account probably won't have sufficient privileges to accomplish what my code is trying to do, so someone will need to open the Services Manager and change this to a valid account. I could hard-code the Name and Password of an account that I know has sufficient privileges, but this ties my application too tightly to a single domain or server or organization. I would rather keep it flexible enough that it can run anywhere. And besides, the account under which a service runs is really a deployment issue, so others should be making these decisions and they should be forced to think about this at deployment time.

Below is sample code for the installer class

public partial class Installer1 : Installer
    public Installer1()
        ServiceInstaller si = new ServiceInstaller();
        ServiceProcessInstaller spi = new ServiceProcessInstaller();

        si.ServiceName = "DGWinSvc"; // this must match the ServiceName specified in Service1.
        si.DisplayName = "DGWinSvc"; // this will be displayed in the Services Manager.
        si.Description = "A test service that takes some action every 30 seconds";

        spi.Account = System.ServiceProcess.ServiceAccount.LocalSystem; // run under the system account.
        spi.Password = null;
        spi.Username = null;

After your code is tested and compiled, you can deploy it to a server. Copy to a location on the server the service EXE and any associated DLLs, Config files or other objects required for it to run. The server must have the .Net framework installed. If it has the framework, it should have a program called InstallUtil.exe. You can find this program in the Windows folder under Microsoft.NET\Framework in the subfolder corresponding to the .Net CLR version under which you compiled the service. On my server, I found InstallUtil.exe in c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727. Open a command prompt, change to the location of InstallUtil.exe and run the following command
INSTALLUTIL <full path of Windows Service Executable>

You can later uninstall the service with the following command

INSTALLUTIL /u <full path of Windows Service Executable>

Now open the Services Manager applet (under Windows Administrative Tools) and refresh the list of services. You should see your service listed with the DisplayName you assigned in the Installer class. Right-click this service and select Properties to display the Service Properties dialog. Click the "Log On" tab, select "A particular user" and enter the name and password of the user under which this service should run. You may need to create this user. It should have permission to access all resources that the service needs to access. Click the OK button to save these changes and close the dialog.

Of course, you can also write a setup project to your solution if you want to automate the deployment process. This article does not cover that.

To start the service, right-click the service in the Services Manager and select Start.  You can use the same applet to stop the service. Right-click its name and select Stop. Alternatively, you can stop and start the service from the command line with the following commands

NET START <ServiceName>
NET STOP <ServiceName>

where <ServiceName> s the ServiceInstaller ServiceName property specified in our installer class. For our example, we would type. This is a useful if you want to script the starting and stopping of your service.

Windows Services are something that .Net got right very early and hasn't needed to change. Creating useful services is easy with the .Net framework.

You can download a simple Windows service at DGWinSvc.zip (28.05 KB).


Sunday, November 1, 2009 4:40:13 AM (GMT Standard Time, UTC+00:00)
# Thursday, October 29, 2009

Many computers today ship with multiple processors and with multi-core processors.

In order for programs to take advantage of multiple cores, application developers need to write code that runs in parallel - that is that runs simultaneously on two or more cores. The upcoming .Net 4.0 provides tools to make it easier for developers to write such code.

The Parallel Extensions library eases the pain of building multi-threaded applications. Enhancements include a set of APIs to abstract away the complexity of parallel processing; a set of thread-safe collections appropriate for use with parallel processing; and enhancements to the System.Threading namespace.

Stephen Toub of the Microsoft's Parallel Computing team is touring the Midwest this week speaking about this new technology. Friday October 30, Stephen will be at the Microsoft office in Southfield, MI at a special meeting of the Great Lakes Area .Net User Group.

You can get more information and register for this event at http://migang.org/NewsItem/09-10-16/special_user_group_meeting_oct_30_parallel_computing_with_stephen_toub.aspx

Thursday, October 29, 2009 4:33:43 AM (GMT Standard Time, UTC+00:00)
# Wednesday, October 28, 2009

Microsoft ASP.Net MVC (aka "MVC") is a new framework from Microsoft designed to encourage loose coupling between the user interface and the data layer of a web application. With MVC, an application is logically divided into the Model (the data), the View (the user interface) and the Controller (code to retrieve and manipulate data before passing it to the View). This framework makes it nearly impossible to add business logic (or any code for that matter) to the UI layer; Business logic in an MVC application belongs in either the Model or the Controller. MVC allows for greater separation of concerns, more control over the HTML output and easier unit testing of a greater percentage of your code.

Professional ASP.NET MVC 1.0 by Rob Conery, Scott Hanselman, Phil Haack and Scott Guthrie describes the framework, how to use it, and how to exploit these advantages.

A significant part (about 40% of the text) of this book can be downloaded free. Chapter 1 - the free download written by Microsoft VP and cyber-celebrity Scott Guthrie - describes an ASP.NET MVC application called 'Nerd Dinner'.  This is the chapter I spent the most time on. I used Nerd Dinner as a model to build my own MVC application, striving to understand why the code was written as it was and how the framework was used. For me, this was the most useful part of the book.

This is not to say that the rest of the book is useless - It was very informative. I especially liked the chapters that dove deeper into explaining the Routing Engine, the Controllers and the Views. These chapters weren't comprehensive enough to be a definitive reference, but they were clear and concisse and I learned the flexibility of this framework and alternative ways to use it.

Other chapters describe how to use JQuery and Ajax to make MVC applications more dynamic and visually appealing. The authors devoted two chapters to testing because this is one of the major benefits of MVC.

The final chapter describes how to integrate MVC and the traditional web forms framework into a single application. I appreciated this because so much of my work is modifying existing systems.

My recommendation is to download and read the free chapter of this book before deciding whether to invest the 50 bucks on the larger dead tree version. This will give you a better perspective on the framework and you will make the rest of the book more relevant. If your goal is simply to evaluate this framework or get exposure to it, this chapter may be sufficient.

But if your interest is piqued by Nerd Dinner, the remainder of this book is a good start in learning MVC.

books | MVC
Wednesday, October 28, 2009 11:05:28 AM (GMT Standard Time, UTC+00:00)
# Saturday, October 24, 2009

Check out this video I produced and edited for Microsoft Architect Evangelist Brian Prince. Brian approached Windows 7 users and asked them to give their favorite feature of the new operating system.

Saturday, October 24, 2009 2:08:27 PM (GMT Daylight Time, UTC+01:00)
# Tuesday, October 20, 2009

Think big; act small; fail fast; learn rapidly.

These are some of the lessons from Tom and Mary Poppendieck’s book Lean Software Development – An Agile Toolkit.

The Poppendiecks take what they learned from Lean Manufacturing (many of which were originated with the pioneering work of Toyota Motor Company) and apply these lessons to software development.

They deliver advice in the form of 22 “tools” that can make a team or project more lean. Related tools are grouped together into chapters.

The authors recommend that organizations define, find and eliminate waste wherever it occurs in a process. Examples of waste in software development include defects, waiting, extra features or processes, and any non-essential activity. To assist finding waste, they recommend Value Stream Mapping - a technique in which one lists in sequences all the steps from customer request to delivery and estimates the time to completion of each step and the wait time between each step. This technique often makes bottlenecks obvious so that they can be reduced or eliminated.

Many of the tools in this book overlap. For example, iterations and feedback are listed as separate tools, but shorter iterations allow for more frequent feedback to the development team. Short iterations also expose design problems more quickly sot that the can be corrected early in the development cycle at a lower cost.

Much of the authors’ advice seems counter-intuitive. For example, they recommend against detailed planning at the start of a project and attempting to optimize every part of a multi-part project.

A popular approach among software project managers is to create in advance a detailed plan of every step in the design, development and deployment process and to estimate each step. To do so, you need to know a specific scope of everything you will build. This makes sense as a risk-reduction strategy, until you consider that environments, requirements, priorities and people often change while software is being developed. A rigid plan created up front often requires an aggressive change control process to alter that plan in any way. And for long-term projects, the changing landscape almost always forces changes to the design. Also, when users know they will only get one chance to request features, they tend to ask for far more, so scope tends to get bloated when projects are planned in this way. A better approach is to re-evaluate priorities periodically throughout the development process and keep focused on the top priority features that have not yet been implemented.

Complex project can and often should be split into a number of smaller phases or tasks. This helps to simplify the complexity. Many managers then strive to optimize each phase of the project, assuming that this goal will lead to overall optimization of the project. The Poppendiecks advise against this goal because optimizing some phases may cause a bottleneck in your overall project, thus slowing down the project as a whole. A buildup of code waiting to be tested, for example, represents waste that should be eliminated. It is best to look at the system as a whole when setting optimization goals. Optimizing each part ignores the interaction between these parts.

The book finishes with practical advice to get started making your team and process more lean.

Lean Software Development - An Agile Toolkit is a clearly-written, thoughtful book and anyone involved in software development projects can benefit from reading it.

Agile | books
Tuesday, October 20, 2009 11:17:26 AM (GMT Daylight Time, UTC+01:00)
# Monday, October 19, 2009

Episode 59

In this episode, Chris Woodruff discusses how to use RIA Services to separate concerns in a Silverlight application.

Monday, October 19, 2009 3:15:45 AM (GMT Daylight Time, UTC+01:00)
# Friday, October 9, 2009

I will be presenting technical talks in Kalamazoo, MI and Grand Rapids, MI. My schedule is below.

Date Topic Event Location  
Oct 22 An Introduction to Object-Oriented Programming Microsoft Developers of Southwest Michigan October meeting WMU College of Engineering Building,
Rm C-123
Kalamazoo, MI
Dec 3
Oct 29
Build Better Software with TFS and VSTS 2010 Sogeti-New Horizons - Microsoft event New Horizons
28th St. Court SE
Suite B
Grand Rapids, MI

Also, my colleague Jesse Murray will be speaking about "SharePoint - The Right Way" at the Great Lakes Area .Net User Group Wednesday October 21 in Southfield, MI. This event is sponsored by Sogeti (so food will be provided). You can get more information here.

Edit: My VSTS 2010 / TFS 2010 talk scheduled for October 29 has been postponed to December 3.
    -Dave, 10/24


Friday, October 9, 2009 3:52:02 PM (GMT Daylight Time, UTC+01:00)
# Thursday, October 8, 2009

HopeMongers is attempting to connect people together via charitable donations. The web site HopeMongers.org allows individual contributors to donate small amounts of money (they use the term "Microgiving" to describe this) to individual projects that help the poor of the world.

By doing so, they eliminate much of the bureaucracy and cost that burdens many other charitable institutions. The projects that HopeMongers supports tend to be small in size and focused on an individual community. Examples include digging a well to provide clean drinking water for a village in Haiti; construction of a building to house an orphanage in Uganda; and a computer education center in South Africa.

"All the money that's donated to HopeMongers goes to the project" said lead architect Phil Japikse.

On the web site, each project lists the amount needed to fully fund it and the amount raised so far.

Sam Henry of Microsoft is the driving force behind this site and he has traveled around the world seeking, vetting and overseeing projects to show on the site.

But many others are involved in the development of the web site.

DiscountAsp.net donated the web hosting; SAAS hosts TFS and the build servers for free; and most of the development time was donated by dozens of talented developers. Those who didn't volunteer worked on the project at a discounted bill rate.

The development team was spread across the US and worked part-time, which presented a number of challenges. For instance, most of the collaboration took place between 10PM and 1AM Eastern time, via LiveMeeting. For those interested in the technology, the site is built using ASP.Net web forms built with JQuery, C# and NHibernate.

The site is now live and accepting donations. Visit http://www.HopeMongers.org  to learn about the projects and to give a little. You can even donate to the HopeMongers project itself from the site.

I gave $10 to help provide clean drinking water to a village in Uganda and I feel better for having done so.

Thursday, October 8, 2009 12:17:30 PM (GMT Daylight Time, UTC+01:00)
# Wednesday, October 7, 2009

Episode 58

In this interview, Sai Naik describes the advantages of SharePoint and where it is a recommended solution.

Wednesday, October 7, 2009 2:43:04 PM (GMT Daylight Time, UTC+01:00)
# Tuesday, October 6, 2009

The ASP.NET MVC framework (which I will refer to as "MVC" in this article) encourages greater separation of concerns than the older ASP.NET web forms framework.

Some key differences between web forms and  MVC are

  • ASPX pages in MVC have no code-behind files. This discourages developers from putting any business logic in the view.
  • By default, URLs in MVC do not point to a file on disc. Rather, they point to an Action in a Controller.

A controller is a class that inherits from System.Web.Mvc.ControllerBase.

MVC uses several conventions to find this class. First, it expects controller classes to be in the Controllers folder. Also, it expects a controller class name to end with "Controller".  So if we tell MVC to look for a Product controller, it will look for the file Controllers\ProductController.cs or Controllers\ProductController.vb.

An Action is a method within a Controller class that returns a System.Web.Mvc.ActionResult. The ActionResult represents the View data that is available when MVC renders output to the client.

One way we can tell MVC to look for a controller is by typing a URL into the browser’s address bar. Doing this causes MVC to use the routing engine. I described the routing engine in a previous article. The default routing assigned to a new MVC project looks for a URL with the following format


When the routing engine encounters a URL formatted like the one above, it looks for a controller named after the first part of the URL; an action method within that controller named after the second part of the URL; and a parameter to pass to that method in the third part of the URL. For example, if the user typed the following URL into the address bar:


, MVC would look for a class named CustomerController in Controller\CustomerController.cs (assuming we are coding in C#). If it found this class, it would look in it for a method named "Details" that returns an ActionResult and that accepts a parameter. It would then call the Details method and pass it the parameter "1".

The ActionResult returned by this method is used by the MVC View engine to render output to the client. I described MVC views in a previous article.

The code below is for a Controller Action method. It assumes the existence of the GetCustomer method that returns a single customer object.

public ActionResult Details(Int32 id)
    Customer cust = MVCDemoRepository.GetCustomer(id);
    return View(cust);

The View method called in the code above returns a ViewResult – a class that inherits from ActionResult. By passing the Customer object to this method, the ActionResult’s Model property is populated with the Customer object. Properties of that object can then be used within the view.

Another way to pass data from the controller to the view is to populate the ViewData property. ViewData is a list of name-value pairs. You can populate this list in the controller and retrieve elements from it within the view. We can modify the Action method above to add to the ViewData list.

public ActionResult Details(Int32 id)
    ViewData["HelloMessage"] = "Good morning to you";
    Customer cust = MVCDemoRepository.GetCustomer(id);
    ViewData["GoodbyeMessage"] = "Good night. See you later";
    return View(cust);

By default, this controller routes the user to a view with the same name as the Action in a folder named after the controller. In this case, MVC will look in the \Views\Customer folder for a file named either Details.aspx or Details.ascx. If it cannot find either of these files in that folder, it will search in the Views\Shared folder. Here MVC is using configuration again to determine where to look for files.

You can change the view MVC looks for by using an overload of the View method as in the following example

return View("CustomerDetails", cust); 

The above line tells MVC to look for a view page named CustomerDetails.aspx or CustomerDetails.ascx in either \Views\Customer or \Views\Shared.

Here is a complete listing of a Controller class

using System;
using System.Collections.Generic;
using System.Web.Mvc;
using MVCDemoController.Models;

namespace MVCDemoController.Controllers
    public class CustomerController : Controller
        // GET: /Customer/
        public ActionResult Index()
            List<Customer> customers = MVCDemoRepository.GetAllCustomers();
            return View(customers);

        // GET: /Customer/Details/1
        public ActionResult Details(Int32 id)
            ViewData["HelloMessage"] = "Good morning to you";
            Customer cust = MVCDemoRepository.GetCustomer(id);
            ViewData["GoodbyeMessage"] = "Good night. See you later";
            return View(cust);

Below is a sample view to render the output from the Details controller action above

<%@ Page Title="" Language="C#" MasterPageFile="~/Views/Shared/Site.Master" Inherits="System.Web.Mvc.ViewPage<MVCDemoController.Models.Customer>" %>

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

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


    <%=Html.Encode(ViewData["HelloMessage"]) %>
            <%= Html.Encode(Model.ID) %>
            <%= Html.Encode(Model.FirstName) %>
            <%= Html.Encode(Model.LastName) %>
        <%=Html.ActionLink("Back to List", "Index") %>
    <%=Html.Encode(ViewData["GoodbyeMessage"]) %>



Good morning to you

ID: 1

FirstName: David

LastName: Giard

Back to List

Good night. See you later

The MVC Controller is used to retrieve data from the Model, to populate any extra data needed by the view and to determine which view to render. Understanding it is key to understaning MVC.

Download demo code for this article at MVCDemoController.zip (281.08 KB)


Tuesday, October 6, 2009 5:10:09 AM (GMT Daylight Time, UTC+01:00)