How asynchronous is SmtpClient.SendAsync?

In a previous role, I was tasked with writing a newsletter email sender. How hard can this be, I thought to myself, and set off to complete my mission.

Initial Thoughts

We were probably going to be sending tens of thousands of emails at a time so although I figured I’d need to use some threading, I thought I’d start by using the asynchronous version of the SmtpClient.Send method, SmtpClient.SendAsync instead of the blocking SmtpClient.Send. I figured that way I’d be able to send batches of emails asynchronously and that way we’d be able to get through all the emails super fast.

The Test

I wrote some basic prototype code using SmtpClient.SendAsync and ran a test to send a couple hundred emails in it. Although my test ran without errors, I pretty quickly discovered that I wasn’t receiving all the emails that I was apparently sending by calling SmtpClient.SendAsync! At first I wondered if I’d somehow overflowed my inbox or something but that didn’t seem to be the problem. Then I started doing a bit more research and discovered something which explained the behaviour I was seeing…

The Findings

From the ‘remarks’ section of the MSDN documentation on SmtpClient.SendAsync:

After calling SendAsync, you must wait for the e-mail transmission to complete before attempting to send another e-mail message using Send or SendAsync.

And…

To receive notification when the e-mail has been sent or the operation has been canceled, add an event handler to the SendCompleted event.

OH! So in order to successfully send multiple emails asynchronously, I must add an event handler to the SmtpClient.SendCompleted event and wait until the first SmtpClient.SendAsync has completed before triggering the next one. Hmm… this does not seem all that asynchronous to me! I realize that there must be good reasons why it was implemented this way but in theory, using SmtpClient.SendAsync to send multiple emails really isn’t all that much more asynchronous than lining up a bunch of synchronous calls to SmtpClient.Send.

Conclusion

I guess it all comes down to your interpretation of what ‘asynchronous’ means – in this case, SmtpClient.SendAsync is indeed asynchronous in that it allows the program to carry on executing without blocking. This is great in most cases, unless what you want to do next is send another email.

So to sum up, it seems the only way to send multiple emails at the same time using .NET’s SmtpClient is to use threading after all. Spawn up a few worker threads with a separate instance of the SmtpClient in each and just send the emails using SmtpClient.Send.

Read More

ASP.NET Response.Redirect

In ASP.NET web applications, the Response.Redirect(string url) method is often used to control the flow of an application (both user browsing and logic) by redirecting the client to a different URL. For example, on a page that requires an authentication user, it is quite standard to first check if the user is logged in and if they aren’t, call Response.Redirect(“login.aspx”). This is all great, except that many developers probably don’t know what’s actually going on under the covers.

Under the covers

Internally, Response.Redirect (and Server.Transfer for that matter) calls Response.End to end the page’s execution (rather abruptly) and then shifts the execution to the Application_EndRequest event in the application’s Global.asax. We rely on this behaviour to bail out of wherever we were when we decided to call Response.Redirect. What most people probably don’t realize is that Response.End raises a ThreadAbortException exception. Exceptions are expensive, and if you’re calling Response.Redirect often, you might find this particular behaviour detrimental to the performance of your site.

So, how do I avoid these exceptions?

Well, Response.Redirect actually has an overload that takes two parameters – Response.Redirect(string url, bool endResponse). If you use this overload instead and pass false to the endResponse parameter, the internal call to Response.End will be suppressed and as such, no ThreadAbortException exceptions will be raised.

Great! But wait, there’s more…

There is a side effect! Using this overload and passing false so that Response.End doesn’t get called means that any code after the call to Response.Redirect will now be executed where it wouldn’t have previously. This makes perfect sense – if Response.End isn’t called then the execution isn’t shifted to the Application_EndRequest event and if the execution isn’t shifted, then it will carry on executing wherever it currently is. That’s right – although you no longer get ThreadAbortException exceptions being thrown, Response.Redirect no longer controls the flow of your logic.

This is fine if you are calling Response.Redirect at the end of a method at the bottom of your call stack because there was probably no more code to be executed anyway. On the other hand, if you are calling this from inside a method that isn’t at the bottom of your call stack, you have to be careful with the remaining stack calls. Even if you call return straight after you call Response.Redirect, where are you ‘returning’ to? Another method that executes more code? Eeek!

In conclusion

None of this is news – it’s all explained in this Microsoft Support article. However, I really don’t feel that it emphasizes enough the negative effects that switching over to the Response.Redirect overload may have on your application. You simply can’t go through your application and replace every Response.Redirect with it’s overload without thinking carefully about what this might do to the logic of your application. The ‘flow’ may still look like it’s working as it should because the user will still be redirected to another page, but under the covers you might find that you’re now executing code that you weren’t before and that may have some pretty nasty unwanted effects.

Read More

Localization and skinning in ASP.NET MVC 3 web applications

Working in Europe has introduced me to the world of localization and skinning web applications. Not only do we have to support several different locales for the same web application, but in some cases, depending on the host url, the site should be skinned completely differently. A common reason for needing to do this is if your e-commerce website also sells products under the guise of a different company in certain locales. Obviously, skinning sites involves a lot of css styling, but you may also need to provide different values for titles, labels, urls, etc, for each skin. You really don’t want to have to build and deploy several copies of your website to do this, and luckily, you don’t have to!

Localization in .NET using resource files

In .NET, localization is generally done via resource files. For each language / locale you wish to support, you should have a SiteA.resx file, e.g.

  • SiteA.resx (This is the fallback resource file, in case no other more specific resource files match the current culture)
  • SiteA.es.resx (Spanish)
  • SiteA.de.resx (German)
  • SiteA.nl.resx (Dutch)
  • SiteA.nl-BE.resx (Belgian Dutch)

If this is all you need, then .NET makes localization pretty straight forward. When you build your solution, .NET automatically creates a strongly-typed resource class with the same name as your resource files (without the extensions). In my example above, .NET would have created a class called SiteA in the Resources namespace, with public readonly string properties for each key in my resources files.

When you access one of the properties in this resource class, as long as you have set your current culture correctly, .NET will take care of picking exactly which resource file to read the values from. How it picks which resource file to use is done via a fallback mechanism which is handled by the convention-based naming. Scott Hanselman provides a pretty good explanation of how this works here.

Localizing skinned sites using resource files

If you also want to use resource files to provide different localized values for each of your skinned sites, you’ll need to create a set of resource files for each skin, e.g. SiteB.resx and SiteC.resx:

  • SiteA.resx
  • SiteA.es.resx
  • SiteA.de.resx
  • SiteB.resx
  • SiteB.es.resx
  • SiteB.de.resx
  • SiteC.resx

From these resource files, .NET creates three separate strongly-typed resource classes for you to use:

Auto generated resource classes

However, you cannot edit these classes manually, they do not inherit from a common base class nor do they implement a common interface, so how do you elegantly switch between skins without having some massive switch statement everywhere you need to read a value from the resource files?

As with any programming problem, I’m sure there are many ways to do. I’m going to explain how I solved this particular problem in an ASP.NET MVC 3 web application.

ActionFilterAttributes and a LocalizedResourceManager

First of all, I needed something to intercept every action in my application and figure out which culture to use. In my application, I allow the user to change the language of the site by setting a ‘lang’ parameter in the querystring. If that parameter isn’t set, then I look in the user’s browser languages for the main supported language. If you wanted to, you could also read and write a user’s chosen culture from a cookie, but I didn’t need to implement this. I also needed to figure out which skin to display based on the host url that the user requested.

I was able to do this by sub-classing the ActionFilterAttribute class and overriding it’s OnActionExecuting method:

ActionFilterAttribute.cs

You’ll see that on line 18 of the LocalizationAttribute, I resolve the site that the user has requested. I do this by reading the host url. Once I know which site the user has requested, I initialize my LocalizedResourceManager by setting it’s CurrentSiteName property.

LocalizedResourceManager.cs

The LocalizedResourceManager is very simple – it only exposes one method, GetResource(string), to which you pass the name of the resource key that you wish you read out of your resource files. Internally, this method calls HttpContext.GetGlobalResourceObject(string, string) to actually read the property out of the resource files. This method here is really the crux of my solution.

HttpContext.GetGlobalResourceObject(string, string) takes two string parameters: className and resourceKey. In essence, this method allows you to pick which resource class to use and then uses the normal fallback mechanism to figure out which localized resource file to actually read the value from based on which culture is currently set.

All that’s left to do now is to register the LocalizationAttribute as a global filter in the Application_Start() method of Global.asax.cs. I also provide a new route which takes a lang parameter so that the user can change which language they wish to see the site in.

Global.asax.cs

And finally, to make use of this setup, all I have to do is call the static LocalizedResourceManager.GetResource(string) method from within my controllers or views, passing it the resource key name for which I would like to get a localized (both locale and skin-wise) value. By this time, the ActionFilterAttribute will have done it’s magic by setting a current culture and the LocalizedResourceManager.CurrentSiteName property, thereby telling the LocalizedResourceManager which resource class to use and letting .NET use it’s fallback mechanism to pick the right localized resource file as per the current culture.

Index.cshtml

Read More

A generic implementation of the Repository Pattern for LINQ to SQL

Back in 2008 I started working on a project at home which never really went anywhere. It’s still lingering around in the back of my mind but I just gotta find the time to work on it. At the time I figured I could use the project as a learning experience.

It was going to be an ASP.NET site using .NET 3.5 and SQL Server 2008, all tools which I use everyday and know pretty well. To get something more out of it, I chose to use LINQ to SQL as an ‘ORM’, something I hadn’t used before. Then one of my work colleagues recommended that I read up on Domain Driven Design and pointed me in the direction of the ‘Repository Pattern’, so off I went!

The Repository Pattern

Microsoft's vision of the Repository Pattern

Image sourced from http://msdn.microsoft.com

According to Microsoft, a repository should be used to separate the logic that retrieves the data and maps it to the entity model from the business logic that acts on the model. In essence, the repository acts as a mediator between the data source layer and the business layers of the application. It serves several purposes – it retrieves data from data source, maps it to business entities and persists any changes back to the data source. Sounds pretty useful, doesn’t it?

My generic repository class

After setting up the basics and creating a few tables in my database, I started off on my quest to use the Repository Pattern. I started implementing strongly-typed Repository classes for each table in my database and quickly came to the conclusion that this didn’t feel right… I already had half a dozen tables in my database and all my Repository classes were almost identical. It seemed what I actually needed was a generic repository class!

I used my mega-searching-skills on the Google but couldn’t find anyone who had written a generic repository class for LINQ to SQL that returned interfaces of entities at the time. So I got my hands dirty and wrote my own…

?View Code CSHARP
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
using System;
using System.Collections.Generic;
using System.Linq;
using MyProject.DataContexts;
 
namespace MyProject.Repositories
{
    public class Repository<T, K> : IRepository<T>
        where T : IEntity
        where K : class, T
    {
        protected MyProjectDataContext DataContext;
 
        public Repository()
        {            
            DataContext = new MyProjectDataContext();
        }
 
        public List<T> All()
        {
            return GetTable.Cast<T>().ToList();
        }
 
        public virtual T CreateInstance()
        {
            return Activator.CreateInstance<K>();
        }
 
        public void Save()
        {
            try
            {
                DataContext.SubmitChanges();
            }
            catch (Exception ex)
            {
                throw ex;
            }
        }
 
        public virtual T Save(T entity)
        {
            try
            {
                if (entity.Id == 0)
                    DataContext.GetTable<K>().InsertOnSubmit((K)entity);
 
                DataContext.SubmitChanges();
            }
            catch (Exception ex)
            {
                throw ex;
            }
 
            return entity;
        }
 
        public virtual T Retrieve(int id)
        {
            return GetTable.Cast<T>().Single(e => e.Id == id);
        }
 
        public virtual T Single(Func<T, bool> exp)
        {
            return GetTable.Cast<T>().Single(exp);
        }
 
        public T First(Func<T, bool> exp)
        {
            return GetTable.Cast<T>().First(exp);
        }
 
        public virtual void Delete(T entity)
        {
            try
            {
                GetTable.DeleteOnSubmit((K)entity);
            }
            catch (Exception ex)
            {
                throw ex;
            }
        }
 
        public virtual List<T> Find(Func<T, bool> exp)
        {
            return GetTable.Cast<T>().Where(exp).ToList();
        }
 
        public virtual List<T> Find(Func<T, bool> exp, Func<T, IComparable> order, bool desc)
        {            
            if (desc)
                return GetTable.Cast<T>().Where(exp).OrderByDescending(order).ToList();
            else
                return GetTable.Cast<T>().Where(exp).OrderBy(order).ToList();
        }
 
        private System.Data.Linq.Table<K> GetTable
        {
            get { return DataContext.GetTable<K>(); }
        }
    }
}

That’s all! One generic repository class for all my tables… I love it!

Using the repository

As it’s supposed to, the repository pattern makes it really easy to access your data in a standardized way. Below is a snippet out of my UserService class…

?View Code CSHARP
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
namespace MyProject.Services
{
    public class UserService
    {
        Repository<IUser, User> userRepo;        
 
        public UserService()
        {
            userRepo = new Repository<IUser, User>();
        }
 
        public IUser CreateUserInstance()
        {
            return userRepo.CreateInstance();
        }
 
        public IUser InsertNewUser(IUser user)
        {
            try
            {
                user = userRepo.Save(user);
            }
            catch (Exception ex)
            {
                // Logging
            }
 
            return user;
        }
 
        ...
    }

And so on and so forth…

Conclusion

I’m not saying that LINQ to SQL is awesome, nor am I saying that the Repository Pattern is the way to go. This was just a cool piece of code I wrote a long time ago which I thought I might blog about :)

Read More

A new year, a new app – CountDown for Windows Phone 7

2010 was a busy year for me. I spent a lot of time at mflow, learning lots and working hard. I spent 4 weeks on the back of a motorbike touring 5 countries in Europe and 2 weeks riding the Shinkansen up and down Japan. I saw Billy Connolly live, watched Cirque du Soleil in awe at the Royal Albert Hall, ice skated outside the Natural History Museum.

However, today is 1/1/11 which means I’ve got a whole new year ahead of me to fill up with more fun stuff, and I’m excited :)

This morning, my first ever mobile app was published on the Windows Phone Marketplace! It’s not exactly rocket science, nor is it going to make me rich (it’s free) but I’m just happy to have published something. It’s called CountDown and if you have Zune installed, you can have a wee look here.

If you don’t have Zune installed, here’s an awesome screenshot of it in Zune:

My first Windows Phone 7 app - CountDown

As the descriptions says, this is a simple little app that allows you to keep track of various events and other important dates and counts the time remaining until or since each one. Nothing complicated, but it served it’s purpose as a learning experience. Developing for the mobile form factor is really quite different to developing for web or even desktop because the screens are so much smaller and less ‘usable’ than other mediums. The design, layout and usability of the app has to be very well thought through.

Anyway, this year I hope to develop a few more Windows Phone 7 apps as well as maybe try my hand at Android / iPhone / iPad. I do have a brand new MacBook Pro now so I have no excuses anymore :)

Read More