This project is read-only.

Active FTP Connection and OpenWrite gives NullReferenceException

May 1, 2013 at 3:45 PM
Hi All,

I have an FTP Host.

I am connecting to it with the following
_client = new FtpClient();
                _client.Host = Host;
                _client.Port = Port;
                _client.Credentials = new NetworkCredential(Username, Password);
                _client.DataConnectionType = FtpDataConnectionType.AutoActive;
                _client.Connect();
                _client.SetWorkingDirectory(Directory);
This connects fine.

I am then attempting to upload a file using this code
 Stream ostream = _client.OpenWrite(filename, FtpDataType.Binary);

                if (ostream != null)
                {
                    const int buffer = 2048;
                    byte[] contentRead = new byte[buffer];
                    int bytesRead;
                    using (FileStream fs = new FileInfo(sourceFile).OpenRead())
                    {
                        do
                        {
                            bytesRead = fs.Read(contentRead, 0, buffer);
                            ostream.Write(contentRead, 0, bytesRead);
                        } while (!(bytesRead < buffer));
                        fs.Close();
                    }
                    ostream.Close();
                }
                else
                {
                    throw new Exception();
                }
I have tried OpenWrite with Binary and ASCII and they both produce a NullReferenceException

Herre is full stacktrace:
System.NullReferenceException: Object reference not set to an instance of an object.
   at System.Net.FtpClient.FtpClient.OpenActiveDataStream(FtpDataConnectionType type, String command, Int64 restart) in <sniped>System.Net.FtpClient.1.0.4863.16216\source\FtpClient.cs:line 988
   at System.Net.FtpClient.FtpClient.OpenDataStream(String command, Int64 restart) in <sniped>System.Net.FtpClient.1.0.4863.16216\source\FtpClient.cs:line 1082
   at System.Net.FtpClient.FtpClient.OpenWrite(String path, FtpDataType type) in <sniped>System.Net.FtpClient.1.0.4863.16216\source\FtpClient.cs:line 1318
   at FtpSyncroniser.FtpManager.FtpHost.UploadFile(String sourceFile, String file) in <snipped>FtpSyncroniser\FtpManager\FtpHost.cs:line 76
Line 76 in FtpHost.cs (my .cs file) is the _client.OpenWrite() call;

Can anyone advise what I'm doing wrong?

I've uploaded a file via FileZilla and using Binary transfer type and ACTIVE connection the file uploads.

Thanks!
Coordinator
May 1, 2013 at 3:54 PM
Can you set a break point on line 988 and see which part of the if condition is null?
May 1, 2013 at 4:26 PM
What I can see is that m_stream is the null object when the exception gets thrown.

I noticed that there are Debug logs being written and I noticed that this gets logged when m_stream is null
250 CWD command successful.
TYPE I
200 Type set to I.
SIZE Filename.ext
550 The system cannot find the file specified. 
EPRT |1|192.168.0.254|16019|
501 Server cannot accept argument.
QUIT
221 Goodbye.
(Note: I am checking if Filename.ext exists before I attempt to upload)
Coordinator
May 1, 2013 at 6:31 PM
I've added a check that should avoid the null reference exception, question now is why is it closing the connection after a failed EPRT call when you're using AutoActive. Try out the latest source revision and let me know where things stand for you.
Coordinator
May 1, 2013 at 6:54 PM
Bug should be fixed in the latest revision. When EPRT fails it should fall back to PORT as described by the AutoActive XML documentation. Don't have a way to test it off hand so please let me know the results.
May 1, 2013 at 9:52 PM
Can confirm it's fixed. Works perfectly now thank you!

Here is the console output
250 CWD command successful.
TYPE I
200 Type set to I.
SIZE Global.asax
550 The system cannot find the file specified. 
EPRT |1|192.168.0.254|21170|
501 Server cannot accept argument.
PORT 192,168,0,254,82,179
200 PORT command successful.
STOR Global.asax
125 Data connection already open; Transfer starting.
226 Transfer complete.
Thanks again!
Coordinator
May 1, 2013 at 9:57 PM
Not a problem