Send Mail Out of Context

[jwynveen]

I'ved added the ability to send email outside of HTTPContext by mocking one up with just the BaseUrl. I didn't run unit tests as they weren't immediately working for me, and I only did it for StringResult (don't know if it's needed anywhere else). I only tested for my specific situation, so it might be able to be optimized.

Now all that you need to do if sending outside of context is specify the BaseUrl of the MailerBase and it if HttpContect.Current is null, it will mock out an HTTPContext object to be able to render the view.

[smsohan]

Thanks for your pull request. I am on the go these days and hopefully get your code before I release a new version early May. Really appreciate your interest.

[TylerBrinks]

I'm sure there are plenty of people waiting for this feature, myself included. Looking forward to it (since it's early May already)!

[jwynveen]

Is this ready to pull down and use? I updated it in my project but it gives an exception that httpContext is null. And when I looked at your commit, I don't see anything that's generating the context if it's null.

[smsohan]

Nope, its not ready to pull. But I will keep you posted when its ready.

[xiaobao]

I just came here to ask what I think is the same thing as this. Are you working on a solution that will allow us to call a controller through code and generate emails? Since right now If I make my email controller through code and the original request is not coming from a user I get "System.ArgumentNullException was unhandled by user codeMessage=Value cannot be null.Parameter name: httpContext". If I had like a form and submit to my email controller then I have no problems.

[smsohan]

The catch is without the httpContext the MVC framework becomes almost useless. For example, HTML helpers, URL helpers, view engines and view finding - everything depends deeply on HttpContext. I would love to make it independent of the context but that said, its gonna be considerable work to guarantee that it will work that way. For now, I would suggest expose a REST/HTTP end point from your web app and hit that from the offline app. This will make a httpContext available and things will be just fine.

[chobo2]

@smsohan - could you give an example. For instance I need to pass in a collection of viewmodels. how would I send it to this "Http end point"?

[daniel-sim]

I'm very interested in using MVC mailer + Quartz.net

[smsohan]

Any idea how this can be used?

On Sat, Jun 11, 2011 at 8:54 AM, daniel-sim < reply@reply.github.com>wrote:

I'm very interested in using MVC mailer + Quartz.net

Reply to this email directly or view it on GitHub: https://github.com/smsohan/MvcMailer/pull/12#issuecomment-1349568

[daniel-sim]

I have the Quartz scheduler initializing in Application_Start of my asp.net web (which of course is subject to recycling), calling my method to get subscribers from an entity. But: HttpContext.Current is null, so this is where it falls down.

I'm loathe to take this fork as I've found the core to be stable for my interactive email sending. Will jwynveen's fork go in soon, or are there issues with the approach?

[smsohan]

I think there are multiple issues with trying to make email sending offline workable while using the MVC framework. For example, all your http and url helpers will be uncertain. Also things like partials/master pages/stylesheets are all dependent on the http context - which is possible to fake only upto a certain level with a limiting confidence. I will wait and see it I have a robust solution, or it will break at some of the use cases.

Thank you for your time.

On Sat, Jun 11, 2011 at 9:05 AM, daniel-sim < reply@reply.github.com>wrote:

I have the Quartz scheduler initializing in Application_Start of my asp.net web (which of course is subject to recycling), calling my method to get subscribers from an entity. But: HttpContext.Current is null, so this is where it falls down.

I'm loathe to take this fork as I've found the core to be stable for my interactive email sending. Will jwynveen's fork go in soon, or are there issues with the approach?

Reply to this email directly or view it on GitHub: https://github.com/smsohan/MvcMailer/pull/12#issuecomment-1349797

[daniel-sim]

Yes, I can see that so hesitated pulling the fork. I'm going to look at going through an asmx.

[smsohan]

Hmm, going through a web service is likely the best alternative, that way you have the full stack on your hand. I would suggest going RESTful, so you have a simplified API.

Sohan http://smsohan.com skype:smsohan | gtalk:sohan39 | cell: 403-714-2673

On Sat, Jun 11, 2011 at 9:45 AM, daniel-sim < reply@reply.github.com>wrote:

Yes, I can see that so hesitated pulling the fork. I'm going to look at going through an asmx.

Reply to this email directly or view it on GitHub: https://github.com/smsohan/MvcMailer/pull/12#issuecomment-1350430

[daniel-sim]

REST is best

[daniel-sim]

Okay, I have a good solution that allows me to schedule email sending using Quartz and MvcMailer. Currently I have but one scheduled email type, so it's a very simple service.

A SendScheduledEmail controller contains the guts:

• Check if there's a scheduled email to send
• Attempt to send it using MvcMailer
• Log the result of the send attempt
• Return true if there was one eligible to send, false if none eligible (a JsonResult is overkill at the moment, but will be useful as it expands)

I could invoke this service from anywhere of course. As I'm in Azure, with a single web role, I've decided to do it all in this role.

The Quartz scheduler is kicked off in Application_Start. Every minute it calls a method which makes a WebRequest to the SendScheduledEmail controller.

This is a do...while the WebRequest.Response returns true (true being it has found and attempted to send, there may be more).

As I have two web instances, the controller is thread safe.

[Korayem]

This is discussion is great

I had exactly the same case as @daniel-sim. We're using Quartz.NET with MvcMailer

We will probably implement @daniel-sim's solution until @smsohan solves this in the next release

[dvdstelt]

I'm using messaging and a process running as a Windows Service. It's a real shame using this framework outside of ASP.NET isn't working. I'd use Postal, who supports this scenario, but it doesn't support changing headers and some other stuff... :unamused:

[salmankhann]

I also have the same problem, I'm using scheduling in my Mvc app to send emails at regular intervals. I've defined this code in Application_Start. I'm unable to use MVCMailer because the context is null.

I guess as a workaround, I'll write another action and then from my scheduled task, I'll make an http request to that action.

[gzurbach]

I'd love to see that feature too! :+1:

[molinjinyi]

什么时候可以邮件在后台发布？Email sending from a background process？Time?

[ghost]

Any plan to merge this pull request soon?

[Jogai]

It seems possible with Hangfire. It would send the mails in the background, but still within context. See http://docs.hangfire.io/en/latest/tutorials/send-email.html