This article is going to use some simple techniques to analyse an existing .NET framework class and to extend it in a way the original developers did not intend.
I’ve been recently working on a project related to batch generating large numbers of emails for sending at a later stage. The MailMessage class appeared to provide the functionality I needed. It allowed me to add both plain text and HTML content, and using the DeliveryMethod == SmtpDeliveryMethod.SpecifiedPickupDirectory of SmtpClient, I could generate the emails to a file folder. However, when using this approach, I ran into a problem ...
One of the requirements of my project specified that I needed to control the filename used to output the email so that multiple jobs could be run concurrently and the filename could in some way relate the email to the job that run it. I also wanted to append a sequence number so that I could use this as a way for jobs to continue from where they left off if they failed.
The SmtpClient class has a Send(MailMessage Message) method which, when the PickupDirectoryLocation is specified and DeliveryMethod == SmtpDeliveryMethod.SpecifiedPickupDirectory, generates the email in that directory. However, the file name used by SmtpClient appeared to be a random Guid. No where does the standard SmtpClient or MailMessage expose a way for me to choose the filename used for output or even feedback the filename that was used.
Not choosing to give up on using MailMessage and therefore opt for a third party component outside of the .NET framework, I embarked on finding a way of extending MailMessage and SmtpClient to provide the functionality I needed.
First, I used the excellent Reflector tool to analyse the MailMessage and SmtpClient classes to find out what they were really doing ‘under the hood’. You can download this free from RedGate.
Pointing Reflector at the SmtpClient.Send() method told me two things. When a pickup directory is specified, SmtpClient.Send() creates a MailWriter object called fileMailWriter using the GetFileMailWriter(string Path) method.
To actually generate the email, it then calls a Send() method on the MailMessage object, passing the newly created MailWriter object.
To investigate further, I looked at what was happening in the SmtpClient.GetFileMailWriter() method.
As expected, the disassembled code shows that this method creates a random filename with Guid.NewGuid() + “.eml”. It then creates a MailWriter object, passing it a standard FileStream.
So, at this stage, I knew what was happening when I called SmtpClient.Send(message). But, how could I change this behaviour so that I could generate an email with my own specified filename?
I basically wanted to create a MailWriter object with my own FileStream and then pass it to MailMessage.Send(). However, Microsoft has not exposed this functionality to me. The MailWriter class, GetFileMailWriter(), and MailMessage.Send() methods are all marked as internal, so I couldn’t construct or invoke these methods in the standard way.
This is where Reflection stepped in. I could use Reflection to construct an internal MailWriter and then again to invoke the internal Send() method on MailMessage.
MailWriter object to be able to construct it. We can use the exposed SmtpClient class to do this indirectly. First, I obtained the assembly that SmtpClient is contained in, and then used GetType() to get a reference to the MailWriter type.Assembly _assembly = typeof(SmtpClient).Assembly;
Type _mailWriterType = _assembly.GetType("System.Net.Mail.MailWriter");
MailWriter type to create a MailWriter object. I created my own FileStream object and passed this in.// Create FileStream object
FileStream _myFileStream = new FileStream(_myFileName, FileMode.Create);
// Get reflection info for MailWriter contructor
ConstructorInfo _mailWriterContructor =
_mailWriterType.GetConstructor(
BindingFlags.Instance | BindingFlags.NonPublic,
null,
new Type[] { typeof(Stream) },
null);
// Construct MailWriter object with our FileStream
object _mailWriter =
_mailWriterContructor.Invoke(new object[] { _myFileStream });
Send() method of a MailMessage object passing in my MailWriter object.// Get reflection info for Send() method on MailMessage
MethodInfo _sendMethod =
typeof(MailMessage).GetMethod(
"Send",
BindingFlags.Instance | BindingFlags.NonPublic);
// Call method passing in MailWriter
_sendMethod.Invoke(
Message,
BindingFlags.Instance | BindingFlags.NonPublic,
null,
new object[] { _mailWriter, true },
null);
And that was it – the generated email was created to the filename specified when constructing my FileStream class. By using Reflection, I had reused internal classes and methods in the System.Net.Mail namespace to save a mail to the file system with my own filename – exactly what I needed.
For a final nice touch, I could now wrap this up by using a new feature of C# 3.0 called extension methods. By using an extension method, you can add a Save(string FileName) method to the MailMessage class as if it was put there in the first place.
Shown below is the complete extension method:
public static class MailMessageExt
{
public static void Save(this MailMessage Message, string FileName)
{
Assembly assembly = typeof(SmtpClient).Assembly;
Type _mailWriterType =
assembly.GetType("System.Net.Mail.MailWriter");
using (FileStream _fileStream =
new FileStream(FileName, FileMode.Create))
{
// Get reflection info for MailWriter contructor
ConstructorInfo _mailWriterContructor =
_mailWriterType.GetConstructor(
BindingFlags.Instance | BindingFlags.NonPublic,
null,
new Type[] { typeof(Stream) },
null);
// Construct MailWriter object with our FileStream
object _mailWriter =
_mailWriterContructor.Invoke(new object[] { _fileStream });
// Get reflection info for Send() method on MailMessage
MethodInfo _sendMethod =
typeof(MailMessage).GetMethod(
"Send",
BindingFlags.Instance | BindingFlags.NonPublic);
// Call method passing in MailWriter
_sendMethod.Invoke(
Message,
BindingFlags.Instance | BindingFlags.NonPublic,
null,
new object[] { _mailWriter, true },
null);
// Finally get reflection info for Close() method on our MailWriter
MethodInfo _closeMethod =
_mailWriter.GetType().GetMethod(
"Close",
BindingFlags.Instance | BindingFlags.NonPublic);
// Call close method
_closeMethod.Invoke(
_mailWriter,
BindingFlags.Instance | BindingFlags.NonPublic,
null,
new object[] { },
null);
}
}
}
Basically, we have created a static method in a static class. The thing that marks this method out to be an extension method is the first parameter, this MailMessage Message. The first parameter when marked with this <ObjectType> says that this method is to extend the <ObjectType> class, in this case the MailMessage class.
Now, we can call our extra functionality like so:
MailMessage _testMail = new MailMessage();
_testMail.Body = "This is a test email";
_testMail.To.Add(new MailAddress("email@domain.com"));
_testMail.From = new MailAddress("sender@domain.com");
_testMail.Subject = "Test email";
_testMail.Save(@"c:\testemail.eml");
What we have achieved here is:
Of course, as with most things, there is a downside to the approach I have taken.
One of the major things is that because we are using Reflection to get around the original restrictions put in place by Microsoft in this case, they are free to change their ‘internal’ implementation of System.Net.Mail in future framework releases, which could break our implementation. For example, what is to stop them changing the name of the MailWriter class to something else as it wasn’t exposed to us in the first place.
| You must Sign In to use this message board. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
