2

I'm using MVCMailer which depends on an HttpContext to send out mail.

In some cases I'm sending mail from a WebJob, or in an async task that is used in a flow that calls ConfigureAwait(false) so I lose the context before I hit the MVCMailer code.

My options seem to be:

  • Never use ConfigureAwait(false) (so many of my services use Mailing at some point, so one instance of this will remove the context I need)
  • New up an HttpContext if needed so that I can mail despite not having one
  • Not use MvcMailer and use a third party

I'm looking for the fast and easy solution - newing up an HttpContext if needed. Is this possible?

This is the code I'm using now that depends on the HttpContext:

 public class UserMailer : MailerBase {
    public UserMailer() {
        MasterName = "_Layout";
    }

    public virtual MvcMailMessage Message(MailMessage message, string unsubscribeLink = null) {
        ViewBag.Body = message.Body;
        ViewBag.Subject = message.Subject;
        ViewBag.UnsubscribeLink = unsubscribeLink;
        return Populate(x => {
            x.ViewName = "Message";
        });
    }
}
SB2055
  • 12,272
  • 32
  • 97
  • 202
  • If you have code that's removing the request's context *when you still intend to be in that request's context* then that's a bug, and not just for the purposes of this one class, but in general, as it needs to be fixed. The code should only be removing the current context when it really is sure that that method, and anything it calls, is conceptually unrelated to a request. – Servy Nov 01 '16 at 19:05
  • @Servy This is why I've listed the first option, something I'd like to avoid. – SB2055 Nov 01 '16 at 20:53
  • Trying to avoid fixing bugs that are going to end up causing all sorts of problems for all sorts of aspects of your application, not just this portion, isn't going to end well. If your program is inappropriately running code outside of a necessary context, that's something you should fix. – Servy Nov 01 '16 at 20:59
  • @Servy "avoid fixing bugs" in this case would mean never letting go of the context. I'm looking for a way to remove my dependency on a particular context since a particular context is not needed. "all sorts of problems" - you're assuming that other parts of my application depend on context. In cases where they do, I do not let go of the context. I think you're making a few too many assumptions. – SB2055 Nov 01 '16 at 21:16
  • But the context *is* needed. This operation is clearly conceptually related to a particular request. It would be *wrong* to execute it outside the context of that request. If the operation didn't actually interact with the request at all, *then* it would be okay to run the operation outside of the requests context. – Servy Nov 01 '16 at 21:19
  • @Servy sorry to beat this to death, but MVCMailer needs *a* context, not *the* context - none of the information from a user's visit is necessary here. For all I care, MVCMailer could be off in a console app sending out messages after the user signs off. I'm trying to *remove the dependency* that MVCMailer has on the particular request, because it's irrelevant. – SB2055 Nov 01 '16 at 21:26

1 Answers1

0

If MvcMailer has to have an HttpContext reference, I would abstract it. Create a common mail interface or base class (looks like you have that now with MailerBase) which if you have:

public class WebJobMailer : MailerBase { .. }

Then you can have the webjob use this implementation, but your MVC app the MvcMailer implementation... WebJob mailer could fall back to System.Net.Mail then, or use something else.

Brian Mains
  • 50,520
  • 35
  • 148
  • 257
  • But then I can't use MVCMailer - which is what I'm trying to do. – SB2055 Nov 01 '16 at 20:54
  • 1
    I wouldn't recommend trying to make a fake HttpContext just to make MvcMailer work - that's the problem sometimes with HttpContext-based services... You never know which API methods it calls, which are often highly dependent on a web environment.... Unless the web job invokes a webpage on an IIS server that sends the message (obviously that many moving parts can be problematic). – Brian Mains Nov 02 '16 at 00:31