.NET Core doesn't support getting mail settings from web.config files.

[Priya91]

Desktop Full Framework supports parsing the <mailSettings> element from web.config files which provides smtp settings by using System.Net.Configuration. This contract is not available in netstandard2.0.

This issue tracks this feature difference and requires proposals.

[karelz]

.NET Core doesn't have general settings yet. Once we have it, we can re-evaluate.
This is not specific to Mail only.

[Quentinb]

I know this is an old topic but the situation appears to still be the same. Does .Net core 2.0 / 2.1 not support reading SMTP settings from either the Web.Config or the appsettings.json files yet? The web appears to say no... ?

[karelz]

@Quentinb I don't think it is a good idea to parse web.config. It is much higher layer. appsettings.json might be reasonable ...
Which settings do you find useful? Which do you think we should bring over?
Did you consider using your own configuration file and set the settings based on it?

[Quentinb]

@karelz thanks for the response. In my case, DB connection settings and SMTP would be the most used. I generally use the appsettings.json for .Net core projects and add required settings in there such as custom values etc.

In my case recently, I have a .Net core as well as .Net Full framework Web app that uses the same common assembly for sending email and I need to send emails from both apps using the common assembly. Injecting the SMTP server details iOptions custom type form .Net core and "auto loading" them from the Web.Config in the Web App proved a little tricky. I had to make a "nasty" plan to get it to work with native DI in .Net core and AutoFac in WebApp while reading both sets of config files.

It is really convenient that it loads from Web.Config and would make it super useful to load form app settings.json.

[karelz]

I understand that it would be convenient, however, it would also limit flexibility. Each application type can decide on its own how to handle configuration today, where to read it from - is it per app? Machine wide? Or per user?

.NET Core console apps traditionally use appsettings.json file, but it can be named or placed anywhere else. AFAIK same goes for ASP.NET Core app - there is not fixed config file name/place. "Full" .NET Framework (incl. ASP.NET) on the other hand have prescribed config structure.
Components which live in .NET Core (i.e. layer under ASP.NET Core) don't have visibility into higher levels. That is where SmtpClient is. It would be weird for SmtpClient to reach into higher (optional) layer of ASP.NET Core and grab configuration from there.

The model on .NET Core is that the app decides where configuration file is, reads it and applies stored information to SmtpClient (or your wrapper library). On "full" .NET Framework you can decide to use default settings and let SmtpClient grab values from standard config files.
Naively, it seems like little work for the app to read few values and pass them to SmtpClient constructor (you can store them in your library/app config, or hide them in SmtpClientFactory wrapper). The nice part is that it gives you lots of flexibility and extensibility (you can decide to store more values than the default few we decided to implement).
Can you tell me more about why you find it tricky / nasty? What am I missing?

[vivaladan]

I might take it upon myself to wade in on this one.

I've just been looking for the deliveryMethod and pickupDirectoryLocation options from mailSettings.
As you suggest there's nothing stopping me from reading them out of custom config and setting them myself, and I'm going to have to do this now.

The only reason I want this is for test cases in certain environments where I don't have email set up, or developers machines. Previously it would have been easy just to check this into the web/app.config and then remove it in deployments. Without this, I'm going to have to code for the test scenario and publish code for the feature I don't really care for in production.

[karelz]

@vivaladan either you implement that feature, or we make it part of the BCL/platform (while restricting it to specific config file names / app models, burning in policy, removing flexibility, etc.).
Maybe it could be a common package that people use? (MailSettingsReader)