Re: Sending attachments with SMTP Client - C# Discussion Boards

musefan6-Dec-10 4:15

Re: Sending attachments with SMTP Client [modified]

6-Dec-10 4:15

After a bit more playing the answer to send using a file path is as follows...

using (System.Net.Mail.Attachment attachment = new System.Net.Mail.Attachment(filename))
{
   message.Attachments.Add(attachment);
}
smtp.Send(message);

...I guess I was holding a handle on an System.Net.Mail.Attachment instance in my first code sample (somehow!). Though I would have liked to think this would not have keep a file open anyway!

this however does not work...

using(Stream stream = new MemoryStream(File.ReadAllBytes(filename)))
{
   message.Attachments.Add(stream, "myfile", null);
}
smtp.Send(message);

...because the Send() call is out of scope of the stream. Why this doesn't work but the above does I do not know.

EDIT: Actually I forgot to recompile - neither work (which I would suspect not to)

Life goes very fast. Tomorrow, today is already yesterday.

PIEBALDconsult6-Dec-10 4:16

6-Dec-10 4:16

Why are you opening the file? Didn't you read my response to ~~your~~ (whoops it wasn't yours, sorry) the earlier post? Confused | :confused:

modified on Monday, December 6, 2010 10:37 AM

musefan6-Dec-10 4:20

6-Dec-10 4:20

PIEBALDconsult wrote:
Why are you opening the file? Didn't you read my response to your earlier post?

I am not opening the file. What in my posts gave you that idea?

Life goes very fast. Tomorrow, today is already yesterday.

PIEBALDconsult6-Dec-10 4:24

6-Dec-10 4:24

new MemoryStream(File.ReadAllBytes(filename));

musefan6-Dec-10 4:30

6-Dec-10 4:30

File.ReadAllBytes() closes the file after creating a byte[] - this is not the issue

Life goes very fast. Tomorrow, today is already yesterday.

PIEBALDconsult6-Dec-10 4:40

6-Dec-10 4:40

It is to me -- I send large XML and EDI files.

Oh, and PDFs generated by Crystal. ::shudder::

musefan6-Dec-10 4:57

6-Dec-10 4:57

So then you mean the issue is loading file in memory? I agree with that, its not ideal but I am working with relatively small files and they should stay that way

Life goes very fast. Tomorrow, today is already yesterday.

PIEBALDconsult6-Dec-10 5:32

6-Dec-10 5:32

You don't want your code crash the email server if you can help it. (Been there, done that. Blush | :O

)

I prefer a more general solution whenever I can find one. I don't follow YAGNI -- I always stop to think, "How can this come back to bite me on the backside? I can't foresee all possible problems, but what steps can I take now to alleviate the future problems that I can foresee?"

Also, its easier to allow for very large files today than it will be in a few months.

And if the files are very small, why attach them? Why not use them as the message text?

On the other hand... why not avoid the files entirely? Generate the "file" in memory, store it in the database, read it from there, attach it, and then delete the record. Maybe have the delete postponed until after a database backup.

musefan6-Dec-10 5:46

6-Dec-10 5:46

PIEBALDconsult wrote:
You don't want your code crash the email server if you can help it.

If file sizes start to get to large for emailing then we will prevent sending by email and force users to use the FTP option.

PIEBALDconsult wrote:
I don't follow YAGNI

I agree with regards to potential problems down the line. But I am not going to waste time implementing functionality that is not needed.

PIEBALDconsult wrote:
And if the files are very small, why attach them? Why not use them as the message text?

They are data exports. XML files, MDB files - not very usable as just email body content

PIEBALDconsult wrote:
On the other hand... why not avoid the files entirely?

Because one of the file types if MDB then a file must be created on disk

PIEBALDconsult wrote:
Generate the "file" in memory, store it in the database, read it from there, attach it, and then delete the record

Why would I want to create a file in memory, store in DB and then read it straight back into memory?

Life goes very fast. Tomorrow, today is already yesterday.

PIEBALDconsult6-Dec-10 5:57

6-Dec-10 5:57

musefan wrote:
Why would I want to create a file in memory, store in DB and then read it straight back into memory?

Separation of responsibilities: one (or several) process(es) creates, another sends. Maybe another archives. Who knows?

musefan6-Dec-10 6:08

6-Dec-10 6:08

PIEBALDconsult wrote:
Separation of responsibilities: one (or several) process(es) creates, another sends. Maybe another archives. Who knows?

In some requirements, yes maybe so. But mine is much more just 'Create and Send' - its wasted effort to split the process

Life goes very fast. Tomorrow, today is already yesterday.

PIEBALDconsult6-Dec-10 6:22

6-Dec-10 6:22

I'll check back in a year. Big Grin | :-D

musefan6-Dec-10 6:39

6-Dec-10 6:39

don't forget now... maybe I will come crawling before then Laugh | :laugh:

Life goes very fast. Tomorrow, today is already yesterday.

PIEBALDconsult6-Dec-10 7:21

6-Dec-10 7:21

musefan wrote:
maybe I will come crawling before then

I don't think so... I'm sure you'll be able to handle it on your own. Thumbs Up | :thumbsup:

Luc Pattyn6-Dec-10 4:16

Luc Pattyn

6-Dec-10 4:16

I had the same experience; my guess is the attachment files remain locked by the mail system until it is done sending them. Your code is not to blame for any of that. Solutions would be to create:
- an attachment from the file contents;
- an attachment form a stream, as you did;
- a copy of the file (leaving even more garbage on the file system).

Smile | :)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum

Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.

PIEBALDconsult6-Dec-10 4:26

6-Dec-10 4:26

Or don't delete the file -- archive it at a later date. You never know when you may need a paper trail to CYA. Or to resend for some reason.

musefan6-Dec-10 4:41

6-Dec-10 4:41

Files are created purely for sending to users. There is no need for keeping the file - besides generated files could end up frequent and many so want to keep the file system tidy

Life goes very fast. Tomorrow, today is already yesterday.

PIEBALDconsult6-Dec-10 4:58

6-Dec-10 4:58

musefan wrote:
Files are created purely for sending to users

Aren't they all?

musefan wrote:
There is no need for keeping the file

"There will be." -- Murphy

musefan wrote:
keep the file system tidy

Create them in a directory specifically for them.

musefan6-Dec-10 5:08

6-Dec-10 5:08

PIEBALDconsult wrote:
Aren't they all?

No, I have many files on my computer that are not required to go anywhere. In my service the files being sent are exports of data at regular intervals

PIEBALDconsult wrote:
"There will be." -- Murphy

If I ever need to keep them, then I will start keeping them. But I don't now and cannot think of what they would be useful for

PIEBALDconsult wrote:
Create them in a directory specifically for them.

That's still a folder full of files I don't need or want. Plus they are already generated in a nice file structure to keep them unique

Life goes very fast. Tomorrow, today is already yesterday.

PIEBALDconsult6-Dec-10 6:18

6-Dec-10 6:18

musefan wrote:
I will start keeping them

I see no reason not to keep them now. Do you need plausible deniability?

musefan wrote:
I don't now and cannot think of what they would be useful for

Mostly as a paper trail and for resending when someone's system crashes and is rebuilt. But also in case sometime down the road someone asks about comparing current numbers with numbers from a year earlier -- it happens, and if you aren't already archiving (and perhaps summarizing) data, all you have are files, reports, extracts... or maybe you don't.

Don't throw anything away.

musefan6-Dec-10 6:38

6-Dec-10 6:38

If I need to resend I can generate the files again. These files are just data exports from a database, there is no lost data by deleting the files as they already will exist in the DB which itself will be backed up and archived.

These files are for users and they can do whatever they wish to with them. It is there data to control.. and to look after. We are not providing a file storage system for them.

Like I have already said if it wasn't for an MDB file being generated I probably woudln't even let them out of memory. In that instance would you be telling my to dump my RAM and keep copies of that 'just incase' - if requirements changes, then they change, and it can be handled then

You also said to plan for the future - but what if we look at this from the flip side. What if these generated files becomes thousands a day, even a TB of data a day (bit extreme, but you never know) - now the question will be 'what good reason is there to keep the files?'

Life goes very fast. Tomorrow, today is already yesterday.

PIEBALDconsult6-Dec-10 7:25

6-Dec-10 7:25

musefan wrote:
a TB of data a day

::gibbering:: Well... maybe a very pro-active archive regimen and compression? OMG | :OMG:

musefan6-Dec-10 4:28

6-Dec-10 4:28

Thanks for the reassurance. It would be nice if the was a function SendAndIWillWaitThankYou() but sadly not.

In this case I am happy to use a memory stream as I don't expect the generated files to be too large. I don't like the idea of loading in memory if they get too big so I may have to revisit this at some stage if they start growing

Life goes very fast. Tomorrow, today is already yesterday.

PIEBALDconsult6-Dec-10 4:42

6-Dec-10 4:42

musefan wrote:
SendAndIWillWaitThankYou()

The email server may not have an Internet connection... or only 56K... Sigh | :sigh:

musefan6-Dec-10 4:55