Evolving ASP.NET Apps–Updating Pop3 Integration

This post is a continuation of the Evolving ASP.NET series:

Evolving ASP.NET Apps - Introduction
Evolving ASP.NET Apps – Evaluating the Code
Evolving ASP.NET Apps – Moving to a Web Application
Evolving ASP.NET Apps – Dealing with Dependencies
Evolving ASP.NET Apps – Updating Search
Evolving ASP.NET Apps – Updating jQuery

This post is originally written by Dave Paquette

In this post, we will update the libraries used to retrieve and parse email from a Pop3 server.

SharpMimeTools and Pop3

SharpMimeTools is an open-source MIME parser / decoder. BugTracker uses this library to parse information from incoming emails and to format email messages when sending bug notifications.

It is unclear if BugTracker is referencing the latest version of ShareMimeTools because assembly is version SharpMimeTools is not available in NuGet and according the the SharpMimeTools website, the latest news was in 2006. This is probably a good time to start looking for an alternative, more actively supported library.

After a quick search on NuGet, we found that OpenPop.NET seems to be a popular option. In fact, we can also use OpenPop.NET to replace a large block of Pop3 code that was downloaded from CodeProject in 2003.

After further review of the usage of POP3Client and SharpMimeTools has revealed a serious design problem. BugTracker is attempting to run a recurring background task in the web application that polls for email in a pop3 account. This type of polling code would be better suited as a Windows Service, Scheduled Task or Azure Web Job. It is the type of work that should run out-of-process as it is dangerous and difficult to consistently run background tasks in a web application.

Luckily, there is already a Windows Service and Console Application that also implements this email polling logic. Let's include these existing projects in the BugTracker.NET solution.

View the commit >>

Next, let's delete the experimental code in BugTracker.Web and move the inlined C# code in insert_bug.aspx code to a code-behind file.

View the commit >>

The code in the console application polls for email using Pop3Client, then from any new email found it creates new bugs by posting the raw email message to insert_bug.aspx. Insert_bug.aspx then uses SharpMimeTools to parse the email message and create a new bug. Let's refactor the code in the console application to use OpenPop.NET.

We will need to install the OpenPop.NET package in the btnet_service and btnet_console projects:


Install-Package OpenPop.NET

View the commit >>

Now we can refactor the polling code in POPMain.cs to use OpenPop.NET and delete Pop3Client.cs.

Testing the pop3 functionality is a little tricky as we need a pop3 server to talk to. I followed the instructions on Peter Kellner's blog to setup a local test instance of hmailserver.

The code is still a little messy, but we have managed it clean it up a lot by getting rid of the custom Pop3 implementation. We deleted about 600 lines of code in this commit and have moved to a Pop3 implementation that is likely more standard and is definitely more trustworthy.

View the commit >>

Now, the last step is to replace any use of SharpMimeTools from BugTracker.Web. Let's add a reference to OpenPop.NET to the BugTracker.Web project, then remove reference to SharpMimeTools. Since this was the last reference to SharpMimeTools, we can delete the file from the references folder.

Again, the code is not as clean as it could be but we have made a major improvement. We deleted over 200 lines of rather obscure mime parsing code from Mime.cs.

View the commit >>

While we are in the mood to delete some code, it looks like we had the source code from SharpMimeTools hanging around. We won't be needing that anymore so let's delete it.

View the commit >>

Skip to main content