I am using SmtpClient and MailMessage to send emails from ASP.Net code.
I want to be able to delay the delivery of emails based on business logic.
I will be able to generate a DateTime object about when the email should actually be delivered.
I am aware that I can create a Windows Service to schedule email delivery using Sql Server database as an email storage. But I do not want to deploy an extra service on the hosting server.
I am also aware that I can create a SQL Server job to achieve this, but I would not like to, until and unless, this cannot be achieved using pure ASP.NET
A point to note is that, my code checks whether MSMQ is enabled on the server. If it is, MessageQueue class is used for email delivery. So any pointers on achieving this using queues will be helpful.
By the way, the solution should work in both cases (i.e. with SmtpClient as well as MessageQueue.
I have already reviewed this and this questions and its accepted answers. I do not want to use 3rd party products until and unless this cannot be achieved using pure ASP.NET
P.S. .Net Framework version : 3.5, IIS 7 and Sql Server 2008 should be the environment.
Some information about keeping a timer running in asp.net including a great comment about an always on scenario:
Start timer on web application start
You can use the following to keep asp.net from shutting down:
Can you prevent your ASP.NET application from shutting down?
You can simply use the timer to check a database and send all pending mail.
After some research and clarifications from client, it was decided that I should create a long running background thread, which will handle sending of emails at pre-defined times and need not bother about whether the application pool has been shut down due to inactivity.
Related
I have my software(.NET) running on clients. I need to push the updates to the clients whenever available.
I thought to implement a web service which is running on the main server which broadcasts the update notifications to the client. For dat, CLient has to register their identity over the web to the server.
Server will send the notification on availability of the update. Client has to download the update from the server.
Will WCF would be the good option? .. Is that possible to implement? .. I know there are so many constraints in the networked environment. Suggestions are welcome...
You can make a table for application details including version and in application loading check the version of the application against last version number in database via a webservice if the versions are different fire error method to notify the client there is a new version of his application
but that I think valid from the start but you says the application is already running so I think you have to add this feature to the application and reinstall it on client machine.
check the following posts it may help you to find what you looking for
http://www.installsite.org/cgi-bin/frames.cgi?url=http://www.installsite.org/pages/en/tt_patch.htm
Is there a standard way for .NET Winforms apps to auto-upgrade?
http://www.devx.com/dotnet/Article/10045/1763
http://www.codeproject.com/KB/install/DDayUpdate_Part1.aspx
Maybe "long polling" is a solution. Consider this scenario: Your clients connect to a server using a timeout of lets say 60 minutes. If your server has an update it sends the data and closes the connection causing your client to reconnect and wait for the next update.
Wikipedia: Comet (Programming)
Since you provided details regarding infrastructure and communications I'll go with long polling again. Here is an example (first hit for "WCF long polling" on Google):
Simple Long Polling in WCF - Server
Write a windows service which runs on the clients and periodically checks the update server for new version of your software.
I am working on one Asp.Net application and need to send mails periodically based on some event. First I thought of creating a thread in global.asax and start thread in application_start. But that becomes a bit of problem when application pool crashes or something. So I implemented a windows service and started thread in that and log any errors in windows event log. This works fine. But I need to know whether I am implementing it correctly or is there a better way of doing it?
I think you are moving (or moved already) to the right direction.
We have similar architectures as well, in some cases we used MSMQ to queue outgoing notifications from the ASP.NET application then the Windows Service, usually called Messaging Manager, can grab asynchronously the incoming messages and send the emails or alerts out.
this proves to be effective and robust, if anything crashes after the message has been queued, nothing will be lost because the windows service will always process the messages in the queue, so you can have ASP.NET recycling or the machine with the windows service being rebooted, nothing is lost ever. And in fact in normal production mode, messages are sent out instantly, the decoupling or loose of sync is mostly hidden when everything is working smooth and servers are not overloaded or suffering anything.
In a later project we are now implementing something similar using TIBCO technologies, EMS for the queues and Business Works for queue subscribers.
Using a Windows Service for this kind of tasks is the preferred way instead of doing it in the ASP.NET application. You may also take a look at Quartz.NET which could simply your code for scheduling the task execution and dealing with threads. But if you don't want to write Windows Services probably the simplest would be to have a console application that will do the job of sending emails and then simply use the Windows Task Scheduler to run it at regular intervals.
Another option is a message-based approach. You could have a Windows Service/Console Application reading messages of a message queue (like msmq) and send email when a message is recieved. You can then have your ASP.NET application publish messages to this queue.
Minibuss is a lightweight client for msmq which is very easy to work with. Another options is NServiceBus.
Our e-commerce site requires the sending of email
Currently, for some odd reason, the server that is being used to do this is the database server... which clearly isn't ideal (i've just taken over here)
My idea is this -
to write a windows service that checks for new mails that need sending (these are all in a sql db) and then process the mails seperately...
I want to use a seperate mail server, to keep this efficient..
Has anyone had any experience of this?
Would it be sensible to (for example) set up a lightweight debian (or other distro) machine, with exim on?
Would i be able to use that as the host ip address when specifying my smtp server to send email?
I'm going to be using C#....
I've done this quite a bit, and sometimes I've used a windows server running the SMTP service, other times we've used a third party. In either case you set the host of the mail server in the configuration file and your application can pick it up and continue working.
A nice thing about using a third party service, is that you should have less concern about being black listed.
We did something very similar. We used the IIS SMTP server and wrote code in C# to pump messages directly into its pickup directory using SmtpDeliveryMethod.PickupDirectoryFromIis. systemnetmail.com has some sample code that may help you.
One thing to be careful of is race conditions in the database, especially if you are sending messages with more than one thread (which we were doing). We implemented a queue in the database and used the UPDLOCK and READPAST hints in SQL Server for maximum performance. I think we got it up to over 10,000 emails a minute this way.
You can use the Windows SMTP server wich you can access and use from your web or console application using the CDOSYS or CDO object. You can use this link about configuring the SMTP server on Windows 2003
I have the need from an asp.net web site to send out many SMS messages at once, and also poll a POP3 account for an incoming mail, and then SMS that out to many recipients, one at a time.
The way I am thinking of doing this is a windows service that would connect to my sql back-end to see if there are SMS messages to be sent out, like every 10-20 seconds or so. If so, get all the messages in a list, delete them from the table, and then proceed to send them out.
Same way with the pop account.
Any ideas on how to best provide this service without causing blocking in the asp.net web page when it is kicked off (e.g. messages added to sql server)?
Platform is windows server 2003 R2, sql 2008 standard, asp.net 3.5 SP1.
Thanks for your advice.
We have implemented similar scenarios using SQL Server service broker's Queueing mechanism. The idea is that every inserted SMS record is caught by a trigger which inserts a message containing the SmsID into the service broker Queue.
You then need a stored procedure which receives messages from the Queue. If there are no messages, your procedure will run until the next entry is inserted. That's OK, since it does not take up resources to listen to the Queue.
Next you'll need a Windows service who continuously (recursively) calls the STP, assembles the SMS and sends it.
The Advantage of the Service Broker Queue over a flag in a table is thread safety. This way you could have as many instances of your Service as you want w/o having to worry too much about concurrency issues.
You can find a nice Service Broker tutoial here: http://www.developer.com/db/article.php/3640771
Instead of using an Sql Server for the queuing you could use MSMQ (Microsoft Message Queuing) for this.
MSMQ is quite easy to set up and once it is up and running it is more scalable than Sql Server.
So what you could do was to setup a new queue in MSMQ that would receive the messages you wanted to send. The message would normally be some sort of Message object that describe the message, the sender and the recipient.
Then you would either setup a service that would poll the queue at a regular interval or you could setup MSMQ to start a class of your choice each time a new Message was sent to the queue.
If you need a log of the messages you could have the service / sender object write to a log in sql server when the message was sent.
What are some ideas (using .NET and SQL 2005) for implementing a service that sends emails? The emails are to be data-driven. The date and time an email is to be sent is a field in a table.
I have built several high volume email notification services used to send data driven emails in the past. A few recommendations:
Look into using a high quality email service provider that specializes in managing bounces, unsubscribes, isp and black list management, etc. If sending email is critical to your business, but not your main business it will be worth it. Most will have an api for sending templated messages, click tracking, open rates and will have provide triggers etc.
Look into the SQL Server Service Broker to queue the actual messages, otherwise you can consider Microsoft Message Queuing Services. There is no need to build your own queuing service. We spent too much time dealing with queing infrastructure code when this was already solved.
Develop a flexible set of events on your business tier to allow for the triggering of such messages and put them in your queue asynchronously, this will save you alot of grief in the long run as opposed to polling on the DB or hacking it in with Database triggers.
You can use triggers to send emails on UPDATE/DELETE/INSERT. The triggers can be implemented with .Net, just send mails from there using the classes in System.Net.Mail namespace.
Here is a good article how to implement CLR (.Net) triggers in .Net.
For a light-weight SMPT server, and to minimize the delays, you can use the one, recommended in Kenny's answer.
Thanks everyone for the feedback. For simplicity's sake I've started out with a SP that looks up the reminders to be sent and uses sp_ send_ dbmail (SQL Database Mail) to send the emails. This runs on a job every minute. I update the record to indicate the reminder was sent with the MailItemId sent back from sp_ send_ dbmail. The volume of reminders expected is worst case in the 10^2 range per day.
I'd love to hear feedback about any shortcomings people think this solution may have.
By the way, I can't believe Vista doesn't come with a local SMTP server! Luckily Google is more generous, I used Gmail's server for testing.
Usually, I just spin up a process such as http://caspian.dotconf.net/menu/Software/SendEmail/
I was going to suggest SQL Server Notification Services, which will handle the job nicely. But I see that's been dropped from SQL Server 2008, so you probably don't want to go there.
Data Driven SSRS Subscriptions? Just a thought.