DotNetNuke Tips and Tricks #14: Testing Emails in a Dev Environment
Sep
22
Written by:
Joe Brinkman
9/22/2009 4:47 AM
There are many times when doing DotNetNuke development that your module needs to send emails. You often have emails that need to go out to several different addresses i.e. an email to the user, one to the system administrator and maybe one to a fulfillment partner. You frequently have different emails that get sent based on specific configuration settings or that change based on the role of the user.
When developing for DotNetNuke I often create a custom installation devoted to the module under development. In the past I have not always had an easy method for configuring the SMTP server so that I could trap all the emails being sent out from the system. I would try to set all the emails to one of my many email addresses and set my SMTP settings to use one of my production email servers. The problem with my previous approach is that I often missed emails. Unless all the emails are directed to my personal email accounts, I had no way to trap the emails on my dev box to make sure they were correct. My previous method also did not make it easy to follow the entire email workflow.
All of these problems were solved recently when I discovered a simple little application called Papercut after reading a blog from Scott Watermasysk. Papercut provides a nice GUI that allows me to actually view the raw email content, the text content and an HTML view where appropriate. Neptune is not as nice in this The added bonus with Papercut, is that I can also forward emails to whatever email address I wish.

Now whenever I configure a new DotNetNuke test instance, I just set the SMTP server to localhost and startup Papercut. Every email is trapped and ready for me to inspect. When I think everything is working correctly, I can forward the appropriate emails off to my Marketing director for final approval. At no time did I clutter my inbox or worry about customers inadvertently receiving test emails.
While doing some research for this post, I also found another solution called Neptune which also traps emails during development. It works a bit differently and is designed for integration into the development environment with interfaces exposed for automated unit testing. You can trigger an email to be sent and then programmatically inspect the actual email that was sent.
Being able to easily inspect and test emails will greatly improve your email handling code. Tools which simplify this task make it more likely that you will run through more scenarios without worrying about filling your inbox or being worried about sending inadvertent emails to customers. This is a good thing. I will definitely be using both of these tools on all my future DotNetNuke development work.
11 comment(s) so far...
re: DotNetNuke Tips and Tricks #14: Testing Emails in a Dev Environment
Thanks -- Papercut works well -- just remmeber to shutdown any existing STMP service or use a different port.
This was a very timely post as I needed a method to test email without emailing them ... would be nice to add "email sent" as an event in the event log.
By paul scarlett on
9/22/2009 10:42 AM
|
re: DotNetNuke Tips and Tricks #14: Testing Emails in a Dev Environment
Do you have a Gemini # for that feature request ;)
By jbrinkman on
9/22/2009 1:29 PM
|
re: DotNetNuke Tips and Tricks #14: Testing Emails in a Dev Environment
Talking about emails. DNN needs to have a separate smtp setting for each parent portal. The parent portals we host are owned by different independent identities, Having all the portals funnel their emails through the same account (host's email account) on the mail server is a serious deficiency. A DNN instance can be a platform for hundreds of sites. They need to decoupled when sending out emails.
I hope you push to get this resolved in a DNN update.
By Tony on
9/22/2009 2:46 PM
|
re: DotNetNuke Tips and Tricks #14: Testing Emails in a Dev Environment
I would want to move more towards: DNN-1939 first.
http://support.dotnetnuke.com/issue/ViewIssue.aspx?id=1939
No reason why this enhancement can't happen though.
By Alex on
9/22/2009 2:53 PM
|
re: DotNetNuke Tips and Tricks #14: Testing Emails in a Dev Environment
Until now the best solution for this was the tip Phil Beadle did in the following post (and I use have used it a lot).
http://www.dotnetnuke.com/Community/Blogs/tabid/825/EntryId/1542/Checking-Email-works-with-no-SMTP.aspx
Now with Papercut no more web.config changes, awesome. I have used Neptune in the past and it is more for automated testing, and it works great for that use case. Thanks for pointing out this new tool, it makes testing emails manually a lot easier.
As far as the suggestion to smtp on a portal basis, please enter a Gemini issue at http://support.dotnetnuke.com
By S. Shawn Mehaffie on
9/22/2009 4:32 PM
|
re: DotNetNuke Tips and Tricks #14: Testing Emails in a Dev Environment
Did you have to do anything special to get this to work. Just installed on my work machine and have 2 issues.
1) When I go into options I get an error and the application closes. The changes to the options do save though.
2) Have set SMTP server to localhost and emails do not get sent to application.
I know this is probably something having to do with my work setup, but just wanted to make sure you did not have to do anything special to get this to work.
By smehaffie on
9/23/2009 3:26 AM
|
re: DotNetNuke Tips and Tricks #14: Testing Emails in a Dev Environment
Figured it out. The error I was getting in the smtp.log for Papercut was "System.Net.Sockets.SocketException: Only one usage of each socket
address (protocol/network address/port) is normally permitted:. If you get the same error in the log, it means another SMTP server is already running on your machine. This makes is so that Papercut cannot bind to the server. This is also the reason you cannot save the options.
The first thing to check is to make sure that the IIS Virtual SMTP server is not installed. If it is you will need to disable it for PaperCut to work or use another port for the Papercut SMTP Server. Depending on the tool you are using to send email, using a different port is not an option. I my case we use FreeSMTP and it does not allow you specify a port. So my only option was to disable the IIS Virtual SMTP server.
By smehaffie on
9/23/2009 6:13 AM
|
re: DotNetNuke Tips and Tricks #14: Testing Emails in a Dev Environment
Great tip.
By Jonathan Puddle on
9/23/2009 10:44 AM
|
re: DotNetNuke Tips and Tricks #14: Testing Emails in a Dev Environment
Thanks Joe, very useful for dev!
I had to turn off my Virtual SMTP server as smehaffie suggested, and also make sure that your Host SMPT setting says "localhost" and is not blank...
By Rodney Joyce on
9/25/2009 8:56 PM
|
re: DotNetNuke Tips and Tricks #14: Testing Emails in a Dev Environment
Having all the portals funnel their emails through the same account (host's email account) on the mail server is a serious deficiency.
By Kenali dan Kunjungi Objek Wisata di Pandeglang on
9/28/2009 9:58 PM
|
re: DotNetNuke Tips and Tricks #14: Testing Emails in a Dev Environment
The portal based SMTP settings is a known feature request. We'll be looking at this as one of several possible enhancements for inclusion in 5.3.
By jbrinkman on
10/1/2009 6:16 PM
|