|
Thank you for your help. Acctually, as you mentioned it might be containg a protocol header, because I got the stream binary and I found somthing like the TTL value.
|
|
|
|
|
1. Print the bytes as numbers. You can use those to determine what character set it is.
2. Get a telnet client from somewhere else, not one you wrote, and connect to the server so you have some idea what it is supposed to be sending to you.
|
|
|
|
|
Thank you for help. I realy got the Microsoft Telnet.exe and tryed to see what the expected result but it's not seems the same result that I got.
But Actually a new massage displayed to me when I tryed to connect my TP-Link router:
"?? "followed with a lot of empty lines,
then "??:;??username".
I enternet the username but no more happened.
when I used Microsoft Telnet.exe I found the username is the first required, that may means I recive somthing for the protocol header in the first and my sent massage not clear also to the server.
|
|
|
|
|
I humbly suggest you try it with my code and step through with the debugger.
|
|
|
|
|
I'm having trouble understanding, or rather some confussion with when to return error codes(User-Defined), true or false, when to throw an exception or handle as another path of logic. In some cases I may be making thing overly complex... I don't know.
For instance.. here is a code snippet where I'm I have a function that gets the correct WMI Namespace. If it returns a valid WMI Namespace, it continues on. In cases like this, is returning false the correct way to do this or should I be returning a user-defined error code? I understand the concept of the Try...Catch as well.. but it's what is supposed to be returned or thrown that makes me confused. 
string correctNamespace = GetCorrectWmiNameSpace();
if (string.Equals(correctNamespace, string.Empty))
{
return false;
}
|
|
|
|
|
you choose how you define your methods. The convention in .NET is when they can't do what they are supposed to do, they throw an exception. As a result:
1. File.Exists() returns true or false, as the purpose of the method is to see whether the file exists; both true and false are valid results, both are to be expected, nothing is failing, so no exception.
2. File.Delete() either succeeds or throws an exception, as not deleting the file is considered a failure.
|
|
|
|
|
Luc Pattyn wrote: you choose how you define your methods.
Hi Luc, Thank you for your reply.
|
|
|
|
|
Excellent answer Luc 
|
|
|
|
|
Thanks Dave. It took me quite some time to understand it myself, but that was long ago, and now it all seems so obvious...
|
|
|
|
|
This doesn't answer the question, but....
if ( correctNamespace.Length == 0 ) ...
|
|
|
|
|
hi
i have 2 dataset's in my C# program
dataset1 holds table A and dataset2 holds table B
i need to create excell (xls file - not csv file) with 2 sheets
one for table A and one for table B
how to do it in C# ?
thank's in advance
|
|
|
|
|
|
|
Hi All,
My requirement is... Generate a file, send that file as attachment using SMTP client and then delete the generated file.
I have generated the file fine.
I have implemented SMTP client usage fine.
first attempt error - file in use when trying to delete after sending email...
message.Attachments.Add(new System.Net.Mail.Attachment("FILEPATH"));
smtp.Send(message);
...OK, so SEND is for some reason still using the file. I have just removed another load of almost posted text as I have figured out the answer. Which is basically...
Collection<Stream> streams = new Collection<Stream>();
foreach(string filename in filenames)
{
System.IO.FileInfo fileInfo = new System.IO.FileInfo(filename);
Stream stream = new MemoryStream(File.ReadAllBytes(filename));
message.Attachments.Add(new System.Net.Mail.Attachment(stream, fileInfo.Name, null));
streams.Add(stream);
}
smtp.Send(message);
foreach(Stream stream in streams)
stream.Close();
So I have solved my problem, but have still posted as may be useful for others but also, does anybody know why adding an attachment via a file path keeps the file locked after sending?
Life goes very fast. Tomorrow, today is already yesterday.
|
|
|
|
|
WQithout seeing the code you used to create the file, it's diificult, but yes.
When you created the file, did you close and dispose the file before you tried to send it? If not, and it just went out of scope, then the file is in use until the garbage collector disposes of it. That could be next Tuesday...
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
The generated file is handled correctly. Hence the clean up code (deleting the generated file) works when I use a stream to add an attachment (as in my second code sample).
The only time the clean up fails is if I use my first code sample - if I comment the sole line of smtp.Send then the clean up does not fail. for some reason the Send function is still using the file. I cannot even manually delete the file after the failed clean up for the same reason. Only when I kill the program (which is a windows service) does the file become free again
Life goes very fast. Tomorrow, today is already yesterday.
|
|
|
|
|
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.
|
|
|
|
|
Why are you opening the file? Didn't you read my response to your (whoops it wasn't yours, sorry) the earlier post? 
modified on Monday, December 6, 2010 10:37 AM
|
|
|
|
|
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.
|
|
|
|
|
new MemoryStream(File.ReadAllBytes(filename));
|
|
|
|
|
File.ReadAllBytes() closes the file after creating a byte[] - this is not the issue
Life goes very fast. Tomorrow, today is already yesterday.
|
|
|
|
|
It is to me -- I send large XML and EDI files.
Oh, and PDFs generated by Crystal. ::shudder::
|
|
|
|
|
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.
|
|
|
|
|
You don't want your code crash the email server if you can help it. (Been there, done that.  )
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.
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
