D
dbeavon
Guest
I'd probably use an out-of-process SMTP client (write the mail body and attachment files to SESSION:TEMP-DIRECTORY and then send those file paths over to the other process to do the emailing). If the other process was already up-and-running, eg. as a local windows service, then you could send emails in minimal time (probably in under ~10 ms). If you choose to launch another, fresh .Net process and use command line arguments to send the email then that would probably add a second. I found that one thing leads to another, and it is likely that you will need other types of .Net functionality to be hosted out-of-process as well. If you already have a windows service process which hosts these "micro services", then you can add to them whenever your requirements expand beyond just sending emails. (Note that if you have ever used the Progress "JMS generic adapter" you are essentially offloading all the java-JMS-related work to another "symbiont micro-service" as well.) We currently use the standard SmtpClient, and send emails from directly within the ABL client-session. They say it is deprecated because it was designed poorly, but for very simple SMTP operations, it probably doesn't matter much (unless they ever remove it from the framework). And if we ever needed to do some more advanced stuff, then we would probably invest in creating an out-of-process option. Alternatively you hinted about using the GAC. It would be fairly easy to create a installer package from a "setup project" in VS that will put your nuget dependencies into the GAC. But they would need to be signed. You could run it on the development workstations as well as your deployment machines.
Continue reading...
Continue reading...