How asynchronous is SmtpClient.SendAsync?

Posted by Annie on Jan 30, 2012 in .NET, Coding | 3 comments

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.

ASP.NET Response.Redirect

Posted by Annie on Jan 23, 2012 in Coding | 1 comment

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.

Localization and skinning in ASP.NET MVC 3 web applications

Posted by Annie on Jan 11, 2012 in ASP.NET MVC, Coding | 0 comments

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:

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

A generic implementation of the Repository Pattern for LINQ to SQL

Posted by Annie on Oct 6, 2011 in Coding | 0 comments

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

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…

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…

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 :)

CLR Versioning and Side-by-Side Execution – .NET 2.0 to .NET 3.5 and .NET 3.5 to .NET 4.0

Posted by Annie on Sep 16, 2011 in Coding, Technology | 0 comments

The other day at work I spent some time investigating an OutOfMemoryException being thrown by third-party component being used in a .NET 3.5 application. After a closer look and weighing up some options on how to fix it, we realized that the problem went away if the application was recompiled in .NET 4. This ended up causing some discussion among the team – how could simply recompiling the application that the .NET 3.5 third-party library was being used in fix the problem in the library itself?

One of our team members was convinced that if the third-party library had been built using .NET 3.5 and it was then used in an application that targeted .NET 4, that the third-party library would continue to run under the context of .NET 3.5. To that end, he was sure that recompiling the application in .NET 4 couldn’t have actually solved the problem.

Of course this triggered a Google search frenzy which lead us to this article on msdn:

Excerpt #1:

Add-in Problems:

To give all add-ins the best chance of working, we always choose the latest runtime for managed COM activation. Even if you only have older add-ins installed, there is no way for us to know that when that add-in gets activated, so the latest runtime still gets loaded.

An unfortunate side effect of this activation policy is that when a user installs a new application with a new version of the runtime, completely unrelated applications that use managed COM add-ins, built against older versions, suddenly start running on a newer runtime and can fail.

For the .NET Framework 3.0 and 3.5, we solved this problem through an extremely strict policy: each release was additive and only added new 
assemblies to the prior version with the same runtime underneath. This prevented any compatibility issues when installing them on a machine running the .NET Framework 2.0.

This means that when you are running an app on the .NET Framework 3.5, you are really running it on the 2.0 runtime, with a few extra assemblies on top of it.

What the above implies is that the update from .NET 2.0 to .NET 3.5 was only ‘additive’, that is, Microsoft added some new functionality (dlls) but kept existing functionality the same for backwards compatibility. Actually, if you take a look in the v3.5 folder under Microsoft.NET in the Windows directory, you’ll see that there are a handful of new dlls but no new core libraries to replace the .NET 2.0 versions.

Therefore, if the application we were dealing with had been using a .NET 2.0 third-party component and we were rebuilding the whole application in .NET 3.5, all core types would still be exactly the same under the covers and our colleague would have indeed been correct in his conclusion that rebuilding the application couldn’t have solved the problem.

However, this doesn’t seem to be the case from .NET 3.5 to .NET 4… if one reads on:

Excerpt #2:

Add-in Problems:

This means that when you are running an app on the .NET Framework 3.5, you are really running it on the 2.0 runtime, with a few extra assemblies on top of it. However, it also means that we couldn’t innovate in the .NET 2.0 assemblies, which include key functionalities, such as the garbage collector, just in time (JIT) and base class libraries.

With the .NET Framework 4 we have implemented an approach that allows high compatibility, including never breaking existing add-ins, and also lets us innovate in the core. We can now run both .NET 2.0 and .NET 4 add-ins in the same process, at the same time. We call this approach In-Process Side-by-Side, or In-Proc SxS.

So the .NET Framework 4 allowed Microsoft to ‘innovate in the core’ – in other words, there are new versions of the core libraries. Fair enough, Microsoft do need to be able to make improvements to existing code after all, otherwise we’d still be using .NET 1.0 at the core! But hang on, doesn’t this mean that if you re-build your application in .NET 4.0 that you’ll have to regression test the whole lot because who knows what core type implementations may have changed under the covers? Well no, not really, because of this new approach that Microsoft have adopted called In-Process Side-by-Side execution!

This all sounds great, until you read…

What Does In-Process Side-by-Side Mean to You? > Library Developers and Consumers:

In-Proc SxS does not solve the compatibility problems faced by library developers. Any libraries directly loaded by an application—either via a direct reference or an Assembly.Load*—will continue to load directly into the runtime and AppDomain of the application loading it. This means that if an application is recompiled to run against the .NET Framework 4 runtime and still has dependent assemblies built against .NET 2.0, those dependents will load on the .NET 4 runtime as well. Therefore, we still recommend testing your libraries 
against all version of the framework you wish to support.

Yup, that’s right. If you’re either developing or consuming a library (and really, what developer isn’t doing at least one of those two?) and you decide to upgrade your application to .NET 4, Microsoft actually recommend that you test, test, test!

This tweaked my interest – how different could these new core libraries really be?. I installed dotPeek and opened up both the .NET 2.0 and .NET 4.0 mscorlib.dll assemblies. I drilled down to the Dictionary class and found that there were in fact quite a few, albeit minor, differences between the two implementations!

Anyway, the moral of the story is – upgrading from .NET 2.0 to .NET 3.5 really isn’t a big deal – it’s always wise to do some regression testing, just in case, but you really shouldn’t find many issues with this migration. Upgrading from .NET 2.0 or .NET 3.5 to .NET 4.0 is a different story though. If you’re lucky, In-Proc SxS will help you with backwards compatibility, but if you’re developing or consuming libraries then you’d better have some regression test plans up your sleeve for this migration.

So at the end of the day, it seems like our third-party component bug could well be resolved by rebuilding the whole application in .NET 4 – who would’ve thought!