Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 341
  • Last Modified:

Any gotchas with using StandardOutput of ftp with VB.NET? 'Cause I'm missing some info.

I have a VB.NET application that does an FTP and redirects the Standard Output to a file. All is well when run from a Windows XP box, but when run from a 2003 server, I only get partial data from the StandardOutput. The missing contents are the actual FTP replies (like "150 Open...." and "226 Transfer....."). When run from the command line on the 2003 box, the desired responses appear.

I've scoured this site and the internet, and have seen several others ask this same question but have not come across any answers.

Here's a code snippet:

FTPLabel:
            Dim FixedLiteral As String = FileParam4
            Dim DOS As New Process
            Dim pinfo As New ProcessStartInfo("ftp.exe")
            pinfo.Arguments = "-n -d -s:"
            pinfo.Arguments += FixedLiteral
            pinfo.RedirectStandardOutput = True    ' set to "true" to enable logging
            pinfo.RedirectStandardError = False
            pinfo.UseShellExecute = False     ' set to true to make silent/background

            ' Execute the process
            DOS = Process.Start(pinfo)
            If DOS.Start() Then
                ' Create the file for storing the output of the process
                Dim outfile As New System.IO.StreamWriter(FileParam5)
                outfile.Write(DOS.StandardOutput.ReadToEnd)
                ' Make sure the process has completed
                DOS.WaitForExit()
                ' Dump all the output from the process into the file
                'outfile.Write(DOS.StandardOutput.ReadToEnd)   'original line and location
                'outfile.WriteLine(DOS.StandardOutput.ReadToEnd)
                outfile.Close()
            End If
            'After the FTP process is done, I must open up the log file and check for the string "226 File received ok". If I don't find it, then I will have to try the FTP again.
            mySRftp = New StreamReader(FileParam5)
            mySRText = mySRftp.ReadToEnd()
            If InStr(mySRText, "226 Transfer completed") > 0 Then
                'Remove the concatenated ftp'ed file.
                File.Delete(Localtitle)
            Else
                BadAttemptCnt += 1
                If BadAttemptCnt < 4 Then
                    SendFTPEmail(Localtitle, BadAttemptCnt)
                    mySRftp.Close()
                    GoTo FTpLabel
                End If
            End If
0
bigsplash
Asked:
bigsplash
  • 3
  • 2
1 Solution
 
ehammersleyCommented:
I just created a console app based on your code and it works perfectly on both XP and 2003 Server.  The only idea I have is could FileParam4 be passing '-v' in?  If I pass -v into the app I get the same result as above.  I assume these are either command line args or var. from a calling module or function.

-v is bad, check for it.  That's the only show stopper I can find here, the code works as advertised.
0
 
bigsplashAuthor Commented:
Thank you, ehammersley.  The -v switch is to indeed supress the server responses, and that is exactly what seems to be happening. However I do not have this switch present anywhere.

I got the idea that it may be the 2003 box itself when a colleague said that StandardOutput can be handled differently on various platforms. So whatever it is, I suspect that it is indeed a configuration symptom rather than the code itself.

Do you know much about "Rexec.exe"?  I came accross something on Msdn I think (I failed to bookmark it) that mentioned something about this program handling Sdoutput differently.
0
 
ehammersleyCommented:
RemoteEXECutition client, yes... when used in conjunction with the Rexec service it will allow you to remotely execute commands on a remote machine running the Rexec service.  While I don't know for sure I imagine it could cause a problem with stdout.  I myself have never used it so that's the extent of my knowledge on it.

Using your code above it is safe to say that if the response is generated via manual methods (which it is) then the box is not at fault.  The code says(in a nut shell):

ftp.exe -n -d -s:'commandfile' > logfile.txt

My test of course was different in the fact that I'm not calling or implementing the solution is the same manor as you are.  If you are indeed remotely executing this command in some fashion then it's possible the stdout problem is caused by this.  Since the code above alone in it's own console assembly can execute correctly and provide the proper results I would have to say it's definitely an implementation issue, how the code is called or executed, that's causing the issue.  Try changing the method at which the code is called.  Hard code some of the parameters etc.... you never know.

The only thing we can be sure of is that when run from a local console on 2003 Enterprise it functions as written.
0
 
bigsplashAuthor Commented:
Thanks for your assistance. I have tried several different variations of things, but unfortunately no go yet.  I have another discovery however; when I perform the FTP using a different IP (opening a connection to completely different mainframe) I have success.

SO......  there must be something being handled differently between my code and these two mainframe machines. All is well everywhere else (console and VB using XP and 2003).  I at least have it pinpointed down to a behavioral difference using VB.NET and talking to a Unisys mainframe.

I'll award points to you since you were very helpful in troubleshooting, and isolating the problem down to VB.NET.  I'm going to re-post this question in the VB.NET topic area with this new info.
0
 
ehammersleyCommented:
Very interesting.  Please post a link to your new question here so we can follow it through to the other TA.  This is a very interesting issue.  The consideration was unnecessary considering, but I appreciate the thought.  I'll be following this as well to see where it leads.
0

Featured Post

Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now