System.Net.Mail: Method Clear() of MailAddressCollection leaves 1 element unremoved
Visual Studio 2005 Version 8.0.50727.42
The task is to send an email to every recepient that is contained in a DataTable. AfterMailAddressCollection.Clear()MailAddressCollection.Countchanges to zero, but the next message sentstill contains the first MailAddressadded to the MailAddressCollection. This can be seenonlyif there will benonew MailAddress added to the MailAddressCollection - see below if column "EmailCC" is empty.
Very strange. Any idea except from creating a newMailMessagefor every recepient?
privateSystem.Net.Mail.MailMessage _Msg;
foreach (System.Data.DataRow rowin table.Rows)
{
this._Msg.To.Clear();
this._Msg.CC.Clear();
...
this._Msg.To.Add (newMailAddress (row["Email"].ToString(), row["Name"],Encoding.Default));
if (!string.IsNullOrEmpty (row["EmailCC"].ToString ()))
{
this._Msg.CC.Add (newMailAddress (row["EmailCC"].ToString (), row["Name"],Encoding.Default));
}
...
smtp.Send (this._Msg)
}
[3125 byte] By [
nbnb] at [2007-12-18]
Hmm, I just tried, but I can't reproduce the problem: no matter how many To/CC recipients are in the message, the .Clear method always works as expected, and when I subsequently add new recipients (To and/or CC, in any order), only those new addresses show up.
Do you have a small piece of code that's actually runnable and that demonstrates the problem? I use System.Net.Mail.MailMessage and SmtpClient in various apps, and have never seen anything like this...
'//mdb
Sure I have, here you are:
public void Send () { System.Net.Mail.MailMessage Msg = new System.Net.Mail.MailMessage (); Msg.From = new System.Net.Mail.MailAddress ("from@123.com"); for (int i = 0; i < 10; i++) { Msg.To.Clear (); Msg.CC.Clear (); Msg.Bcc.Clear (); Msg.To.Add (new System.Net.Mail.MailAddress ("mailto@" + i + ".com", "name " + i, Encoding.Default)); if ((i % 2) == 0) { Msg.CC.Add (new System.Net.Mail.MailAddress ("mailcc@" + i + ".com", "name " + i, Encoding.Default)); } if (Msg.To.Count > 0 || Msg.CC.Count > 0) { System.Net.Mail.SmtpClient smtp = new System.Net.Mail.SmtpClient (); smtp.DeliveryMethod = SmtpDeliveryMethod.SpecifiedPickupDirectory; smtp.PickupDirectoryLocation = @"C:\Temp"; smtp.Send (Msg); } } } Now with i==0 will result in a mail with one To- and one CC MailAddress in the message. But with i==1 only the To MailAddress should appear, right?
But this is not the case:
First eml file produced:
x-sender: from@123.com x-receiver: "=?iso-8859-1?Q?name 0?=" <mailto@0.com> x-receiver: "=?iso-8859-1?Q?name 0?=" <mailcc@0.com> mime-version: 1.0 from: from@123.com to: "=?iso-8859-1?Q?name 0?=" <mailto@0.com> cc: "=?iso-8859-1?Q?name 0?=" <mailcc@0.com> date: 3 Jan 2006 21:34:03 +0100
Second eml file produced - please also note only 1 line starting with x-receiver:
x-sender: from@123.com x-receiver: "=?iso-8859-1?Q?name 1?=" <mailto@1.com> mime-version: 1.0 from: from@123.com to: "=?iso-8859-1?Q?name 1?=" <mailto@1.com> cc: "=?iso-8859-1?Q?name 0?=" <mailcc@0.com> date: 3 Jan 2006 21:34:17 +0100
Any hints highly appreciated 8-)
Ah, interesting... I see it's a bit of a Heisenbug too: if you single-step through the code in the debugger, and look at the Msg object prior to the smtp.Send call, everything will seem OK (Msg.CC.Count == 0 on the second iteration of the loop). On a normal run, though, even with a breakpoint on smtp.Send, the Msg.CC collection definitely contains an address. The erroneous CC is in the output message in both cases (!).
I'll look into this a bit further tomorrow, but this seems like a genuine framework bug. Moving the MailMessage object instantiation into the loop fixes the issue, but there may be a workaround that has less perfomance implications.
'//mdb
By chance I found a better workaround for this issue than to re-instantiate the MailMessage with all its implications. Just adding the following pairs will do the "real clear":
MailMessage.To.Clear();
MailMessage.Headers.Remove("to"); MailMessage.CC.Clear();
MailMessage.Headers.Remove("cc");
MailMessage.Bcc.Clear();
MailMessage.Headers.Remove("bcc");
Cheers!