Hey .Net Experts,

i want to discuss a scenario. what is the best way to send bulk emails with asp.net. like reminder emails. emails to all members of forum. or send news letters like that also send scheduled emails.

i have three scenarios in my mind. i need experts suggestions for these.

1) Run a loop  in code to send number of email

like: 

 for (i=0; i<= table.Rows.Count ; i++)

{

    SendEmail(to, from, subject, body); 

} 

2) Write an .EXE file using desktop applications and run this .EXE file through SQL Jobs ETC, We have our own vps for this

3) Write a window service to send emails

please let me know about the best scenario for both efficency and speed. may be other than above three

Thanks
 

I would recommend either method 2 or 3. Doing it in an asp page is pointless, since this action should not be user-driven. It should rather work as a service or a scheduled task, operating once in a while.

Personally, I don't like to build these kind of things as windows services, so I'd go for second option. Simply because I think you have less control over a service, and also developing and debugging a service can be very painful as compared to developing an exe.

Good luck!

Thanks johram for you value able comments. your personal is very good.

my main consideration is speed . i wants to know the advantages and disadvantages b/w 2 and  3 option.  because in future our application is going to be very large. so there will be many kind of emails in huge amount to sent. that's why i looking for the best option for the future point of view.

 

AFAIK, there is little or none performance difference between the two. You develop both 2 and 3 in almost the same manner with the same tools. The difference is more conceptual as to how the process is to be deployed and scheduled. Another benefit from choosing second option is that you have better control of when the process should run (either by windows scheduled tasks or by SQL tasks). With a service, you'd have to write this kind of scheduling yourself.

Either way, I doubt performance is really such a big problem in this case. Would it really be a problem if the batch took 5 minutes instead of 1 minute? After all, there's no user in the other end that requires immediate answer :)

>3) Write a window service to send emails

Option 1 is simply not a good idea. All the web site action should do is to submit the request to a queue.

Option 2 is not a good idea for production deployment.

Option 3 can can have monitoring problems, however it is by far the best option. The problem with most windows services is that they are written as a single project. Instead there should be at least 3 are arguably 4 projects.

• A class project that encapsulates all the mail sending functionality plus a sanity check action. All messages should be written to a custom event log.
  
• A window service that calls the above project to do the sending.
• A class project that allows NUnit testing of the first class project.
• A thin windows application that allows the first class project to be run interactively.  The application should also be able to view the custom event log.

It is vital to have proper logging of problems to a custom event log. Logging should also include a periodic heartbeat message and any no abnormalities detected from the sanity test. The sanity test must assert connectivity to database, mail server and any other resources required.

A windows service allow a restricted domain service account to be used to run it. It is unwise to grant this sort of privilege to the an ASP.NET application. A windows service can restrict its rate of sending - you should ask you exchange team just what wait period is required before sending the next email.

TATWORTH:

Option 2 is not a good idea for production deployment.

 

With all do respect, but I can't see why you couldn't build an exe (option 2) as 3-4 projects? It's a design decision, it's not something that's enforced when you go for a service. I'd like to learn why you don't think scheduling an exe is as good solution when compared to service?

 Thanks to you johram & TATWORTH for kind suggestions. i really learned good ideas. but i want to know  one more thing will there be any security issue while running  window application as .EXE file ?

 

TATWORTH:

Option 2 is not a good idea for production deployment.

I also wonder why this is not a good idea. Sure, I wouldn't use SQL Server to perform the scheduling, but with a less invasive scheduler I think it's a very good solution.

 

Write a windows service is a good practice, I have used this way to send 700k emails per hour.

the other hand, MSMQ is a good solution to keep the mail quere

blodfox777:

Write a windows service is a good practice, I have used this way to send 700k emails per hour.

You seem to have many members ;-)

You should write Windows Service by example. Hooking bulk e-mails sending to ASP.NET is a bad idea. Although you can run e-mail sending on another thread you are not the one who controls the web application. Web application is controlled by IIS and IIS decides when application must be closed and when it must be loaded up again. If you are running Windows Service you don't have a such problem.

DigiMortal>Web application is controlled by IIS and IIS decides when application must be closed and when it must be loaded up again. If you are running Windows Service you don't have a such problem.

Well said!

A windows service can be stopped and restarted if necessary by an operator. Each windows service can can have a separate account which allows minimal necessary access for each services function. Occasionally it is advantageous to program variable polling by the service - running say every 2 minutes during the business day and less frequently out of hours.

A plain command line exe (a service is of course also an exe) should of course not be run by ASP.NET/IIS. It should be run by a scheduler (the built in, or a third party, such as nnCron). This gives almost all the benefits of a service, but simpler development and deployment.

Plain command line exe + Windows Task Scheduler is also one option. I prefer windows services because it is always possible that after server maintain or upgrade works some admin just forget to restore schedules. Not a good practice, but a thing that may happen. It not hard to debug services. I have always used one little trick. Debug build of my windows service contains also code that checks command line options and if I give one specific argument then windows service code is run like command line app's one. This makes debugging very easy and comfortable. Stable build doesn't have this options and it can be started as service only.

One of practical features of a good windows service is for it to maintain a heartbeat. This heartbeat may simply be to update a date-time column of specified row of a date/time parameter table to the UTC date. Thus the web site can readily detect if the service is running or not.