Expiring Today—Celebrate National IT Professionals Day with 3 months of free Premium Membership. Use Code ITDAY17


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

Posted on 2004-08-25
Medium Priority
Last Modified: 2007-11-27
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:

            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)
                ' Make sure the process has completed
                ' Dump all the output from the process into the file
                'outfile.Write(DOS.StandardOutput.ReadToEnd)   'original line and location
            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.
                BadAttemptCnt += 1
                If BadAttemptCnt < 4 Then
                    SendFTPEmail(Localtitle, BadAttemptCnt)
                    GoTo FTpLabel
                End If
            End If
Question by:bigsplash
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 3
  • 2

Expert Comment

ID: 11898050
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.

Author Comment

ID: 11905750
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.

Accepted Solution

ehammersley earned 2000 total points
ID: 11906013
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.

Author Comment

ID: 11934354
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.

Expert Comment

ID: 11934417
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.

Featured Post

Get free NFR key for Veeam Availability Suite 9.5

Veeam is happy to provide a free NFR license (1 year, 2 sockets) to all certified IT Pros. The license allows for the non-production use of Veeam Availability Suite v9.5 in your home lab, without any feature limitations. It works for both VMware and Hyper-V environments

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Learn about cloud computing and its benefits for small business owners.
ADCs have gained traction within the last decade, largely due to increased demand for legacy load balancing appliances to handle more advanced application delivery requirements and improve application performance.
Video by: ITPro.TV
In this episode Don builds upon the troubleshooting techniques by demonstrating how to properly monitor a vSphere deployment to detect problems before they occur. He begins the show using tools found within the vSphere suite as ends the show demonst…
In this video, Percona Solution Engineer Dimitri Vanoverbeke discusses why you want to use at least three nodes in a database cluster. To discuss how Percona Consulting can help with your design and architecture needs for your database and infras…

719 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question