System.Net.Mail.SmtpClient在4.7中是否已过时？
几天前我访问了一个博客 ，说System.Net.Mail.SmtpClient已经过时，开源库MailKit和MimeKit正在取代它。
我可以看到文档 ，但没有在参考代码和库中找到相同的文档 。 它是否过时了？
[System.Obsolete("SmtpClient and its network of types are poorly designed, we strongly recommend you use https://github.com/jstedfast/MailKit and https://github.com/jstedfast/MimeKit instead")] public class SmtpClient : IDisposable
建议使用像MailKit这样的开源解决方案而不是SmtpClient，是的。 它在库中没有被标记为过时的原因是.NET框架中没有替代品。
微软已正式将.NET类标记为由开源库取代。
SmtpClient的文档现在读取， “过时（”SmtpClient及其网络类型设计不佳，我们强烈建议您使用https://github.com/jstedfast/MailKit和https://github.com/jstedfast/MimeKit代替“）” 。
SmtpClient的主要问题是它具有令人困惑的连接生命周期。
连接到SMTP服务器可能非常耗时，尤其是在启用身份validation的情况下，因此每个SmtpClient对象都有一个内部连接池。
这是一个相当奇怪的设计。 考虑一下典型的数据库连接。 在SqlClient上调用Dispose时，底层连接将返回到池中。 创建新的SqlClient时，将检查池是否具有相同的连接字符串的活动连接。
使用SmtpClient，调用Dispose将关闭所有连接并清空该对象的连接池。 这意味着您不能将其与典型的“使用”块模式一起使用 。
像HttpClient这样的共享实例的众所周知的方法不能在SmtpClient中使用。
好吧，不。 ，与HttpClient不同，Send / SendAsync方法不是线程线程安全的 。 因此，除非您想要引入自己的同步方案，否则也不能以这种方式使用它。 事实上，SmtpClient的文档警告，
相比之下， MailKit中的SMTP客户端表示与单个服务器的简单连接。 通过消除内部连接池引起的复杂性，实际上可以更轻松地为MailKit的连接对象创建特定于应用程序的池。
参考： MailKit正式取代.NET的SmtpClient
它在.NET Framework 4.7中并不过时。 由于自动文档生成器中的错误 ，它在API浏览器中无意中被记录。 但是，它在Mono和Xamarin中已经过时了。