|
I was wondering...you could you a message queue for this kind of scenario...which could make the code more simpler...
Moim Hossain
R&D Project Manager
BlueCielo ECM Solutions BV
|
|
|
|
|
I've encountered this exception with the code below. Clearly the stream hasn't been disposed, and Microsoft have acknowledged this as a bug and released a hotfix, but when I run the hotfix, I get an error saying the program to be updated may be missing or the wrong version. Does anyone know anything about this?
using (FtpWebResponse response = (FtpWebResponse)ftpRequest.GetResponse())
{
StreamReader sr = new StreamReader(response.GetResponseStream(), Encoding.UTF8);
string fileName;
do
{
fileName = sr.ReadLine();
Console.WriteLine(sr);
}
while (sr != null);
|
|
|
|
|
Hi Brady,
I am not familiar with this problem, I do have some comments/questions:
- how often does it fail and under which circumstances?
- there are several 100 Google hits for your subject line
- you did not mention at what line the exception gets thrown
- you did not provide any info/link regarding the Microsoft acknowledgement
- are you aware StreamReaders need disposed of too? you might consider a second using statement.
Hope you'll get a solution.
|
|
|
|
|
Apologies.
1. It always fails, under all circumstances. There aren't really many circumstances.
2. That's how I found the MS patch.
3. The exception gets thrown on sr.ReadLine();
4. KB918462.
5. Thanks. This is server side and a leak could be expensive.
|
|
|
|
|
OK,
based on "...The HttpWebRequest class automatically tries to reopen a connection to the Web server to complete the transfer. When the transfer is successful, the EndGetRequestStream method incorrectly returns the Stream object from the first failed connection attempt, instead of the Stream object from the successful connection attempt..." from here[^] my best guess is you are systematically getting the same error on the first attempt, possibly a timeout (that is assuming your request is correct of course). Can you try and allow a larger timeout? or is there a huge amount of data involved?
You might try to validate your web response before calling on its stream? Maybe the StatusDescription property might shed some light.
|
|
|
|
|
Luc Pattyn wrote: Maybe the StatusDescription property might shed some light.
226 Transfer completed.  StatusCode: Closing Data.
This is a listing of my personal web site, not too many files. When I run LS in a console I get:
1751 bytes received in 0.07Seconds 25.75Kbytes/sec.
|
|
|
|
|
First impression is the FTP server has a bug!
You might want and test:
1. your client code on a different FTP server;
2. other FTP clients on your current FTP server.
|
|
|
|
|
Luc Pattyn wrote: First impression is the FTP server has a bug!
My first impression is that the framework has a bug and that Microsoft have even issued a hotfix for it. I will nonetheless perform your suggested tests.
|
|
|
|
|
Yes, I believe Microsoft admitting to a bug that the wrong stream gets returned; but there should
not consistently be a need for a retry in the first place, (the internals of) GetRequestStream should succeed right away, of course a failure might happen but not all the time, so your code should work most of the time. Since it doesn't, I would suspect the server side.
|
|
|
|
|
Pick an FTP site I can rely on for this investigation.
|
|
|
|
|
Whatever public server you like, a software or hardware vendor's, Microsoft ("ftp.microsoft.com"), Intel ("ftp.intel.com"), whatever offers access without an account (i.e. anonymous);
or a site you have an account for, e.g. your own ISP if you have your own site.
All servers and all clients are slightly different, so no test is definitive, but performing both
tests (cross-testing: suspected client+known good server, and known-good client+suspected server) gives a good indication whether the problem is probably in the server or in the client.
|
|
|
|
|
Luc Pattyn wrote: whatever offers access without an account
I just tried the below code on "ftp.microsoft.com" and got the same exception, but not before some console output, i.e:
deskapps
KBHelp
MISC1
Products
ResKit
Softlib
FtpWebRequest req = (FtpWebRequest)FtpWebRequest.Create("ftp://ftp.microsoft.com");
req.Proxy = null;
req.Method = WebRequestMethods.Ftp.ListDirectory;
using (FtpWebResponse res = (FtpWebResponse)req.GetResponse())
{
StreamReader sr = new StreamReader(res.GetResponseStream(), Encoding.UTF8);
string fileName;
do
{
fileName = sr.ReadLine();
Console.WriteLine(sr.ReadLine());
}
while (fileName != null);
}
|
|
|
|
|
Hi,
I ran the code below, which is basically yours (I now count the lines, and I fixed your Console output which was reading another line):
log("start");
FtpWebRequest req = (FtpWebRequest)FtpWebRequest.Create("ftp://ftp.microsoft.com");
req.Proxy = null;
req.Method = WebRequestMethods.Ftp.ListDirectory;
using (FtpWebResponse res = (FtpWebResponse)req.GetResponse()) {
StreamReader sr = new StreamReader(res.GetResponseStream(), Encoding.UTF8);
int count=0;
for( ; ; ) {
string fileName = sr.ReadLine();
if (fileName==null) break;
log(fileName);
count++;
}
log("Received "+count+" lines");
}
and got what I was expecting:
23:46:20.277 CPTest.log-42 start
23:46:25.932 CPTest.log-42 bussys
23:46:25.945 CPTest.log-42 deskapps
23:46:25.958 CPTest.log-42 developr
23:46:25.970 CPTest.log-42 KBHelp
23:46:25.983 CPTest.log-42 MISC
23:46:25.996 CPTest.log-42 MISC1
23:46:26.009 CPTest.log-42 peropsys
23:46:26.037 CPTest.log-42 Products
23:46:26.050 CPTest.log-42 PSS
23:46:26.063 CPTest.log-42 ResKit
23:46:26.077 CPTest.log-42 Services
23:46:26.086 CPTest.log-42 Softlib
23:46:26.281 CPTest.log-42 Received 12 lines
So that tells me the Microsoft server and your client code are rather compatible, so there might be
something wrong with your Internet connection, although I can't begin to understand what it might be.
Is it special in any way? maybe extremely slow? I suggest you try with a well established FTP client so you can feel how it reacts, and maybe see some errors/warnings.
FYI: I did try Microsoft's site with FileZilla 3.1.2, and my Internet is a 3Mb/s ADSL.
|
|
|
|
|
Luc, for you, I keel dee bool! ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
It was that extra read that swung it.
|
|
|
|
|
Brady Kelly wrote: I keel dee bool
I don't know that bull, but you're welcome.
|
|
|
|
|
Come to think of it, since you where reading two lines per iteration, you only showed six,
and you might (did) try and read a line after you tested for null. That must be why the stream objected.
BTW: the code you showed originally was incorrect in a different way, and would not have compiled.
I guess you are better of showing actual code right from the start.
|
|
|
|
|
Yes, I just didn't have the original code at hand. BTW, why wouldn't it compile? The only reason I can see is that it's incomplete, but I just posted an excerpt.
This one was a nasty. The original code was getting an FTP 550 error, file not found or no access, because the directory I was trying to create already existed. It made no check of this, and almost ignored the FTP error by only catching and logging the exception. Because I was breaking when thrown, I noticed an exception that is actually often expected, but I suspected my changes, adding authorization, had introduced the problem. Because another developer had broken the function I needed to execute the code, I extracted it into a separate project to experiment, beginning my troubles.
[Edit]
Ah, I see in the original code that I was trying to write the StreamReader, not the filename, which results in System.IO.StreamReader appearing in the console, just before the same disposed object exception.
[/Edit]
|
|
|
|
|
Brady Kelly wrote: Ah, I see ...
right.
Brady Kelly wrote: I just didn't have the original code at hand
Which is a pity. The original post didn't show a double ReadLine (the extra one without null-test);
if it had, I guess some one would have noticed earlier.
Anyway, the detour with the Microsoft server allowed me to run your code and compare results.
Glad I could be of help.
|
|
|
|
|
|
You're welcome.
|
|
|
|
|
Luc Pattyn wrote: I use ListBoxes for line-oriented text (not TextBoxes)
Just curious. How do you handle editing? Superimpose a TextBox on the edited line?
|
|
|
|
|
I changed my sig to the textbox/picturebox stuff since too many people get into trouble,
they either start drawing on top of a picturebox and complain an image.save doesn't capture the drawing,
or they have trace/log output in a (rich)textbox and they don't get it to work properly and/or it starts to slow down dramatically as the number of lines increases.
Most of my listboxes are for output only; I have done some editing though, just handling all the key/mouse stuff myself. I don't like (rich)textboxes, they don't scale well. I basically did my own editor based on a Panel; I can teach it every trick I want without constantly fighting RTF troubles.
Brady Kelly wrote: Superimpose a TextBox on the edited line?
Have done that too (single-line textbox on top of label), it works rather well. Solves some of the read-only problems.
|
|
|
|
|
I am kind of asking a general question here. When you use the focus function in winforms, it takes the cursor away. What I mean is id I have a control called uxTxtbox and another one called uxBtnSubmit and I go with uxBtnSubmit.focus();, it will then remover my cursor from the textbox and highlight the button but the user needs to type something in. That is I could call the text changed event of the text box but that of course would mean each time the user typed something in, he would have to click the text box again to add another character. Now I know I could easily just call a keypress event of enter and do a uxBtnSubmit.PerformClick() but I kind of think that would just be avoiding the whole thing. Plus, a smart user will see that the submit button isn't highlighted and will think that they have to click the button or tab over to it. Is there a way that the button can be highlighted the while user is typing?
|
|
|
|
|
The button being highlighted means that it has focus. The textbox being highlighted means that the textbox has focus.
If the button is 'highlighted' (if it has the focus) then the cursor is standing on that button. (You can't see it, but if you press the spacebar, you'll interact with the control that has focus - the button).
Only one control can have the input-focus at a time.
I are troll
|
|
|
|
|
I knew there was a solution. You are not supposed to mess around with the focus for the submit button. If you set the acceptbutton property of the form to the button you want, then it will always be highlighted and when you press enter it will be pressed.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
