Невозможно подключиться к удаленному серверу через System.Net.FtpWebRequest.GetRequestStream ()

Я могу подключаться к серверу по FTP и загружать файлы во время работы VS2013 в отладке, но когда я компилирую как Release | x86 Я получаю сообщение об ошибке «Не удается подключиться к удаленному серверу» в строке, вызывающей System.Net.FtpWebRequest.GetRequestStream (). Я могу получить доступ к FTP и загрузить файлы с помощью WinSCP. Я запустил WireShark и вообще не видел пакетов из версии Release моего кода, но видел все соответствующие пакеты, когда выполнял из режима отладки в VS2013. У меня нет брандмауэра, и он действительно поставил меня в тупик. Любая помощь будет принята с благодарностью. - Чак

    public bool UploadToFtp(string sFtpServer, string sFtpUserName, string sFtpPassword, string sSourceLocationPath, string sFtpDestinationPath, StringBuilder sbLogMessage)
    {
        bool bUpload;
        try
        {
            var oFile = new FileInfo(sSourceLocationPath);
            var oUri = new Uri(sFtpServer + sFtpDestinationPath + oFile.Name);
            var oFtp = (FtpWebRequest)WebRequest.Create(oUri);
            oFtp.Credentials = new NetworkCredential(sFtpUserName, sFtpPassword);
            oFtp.KeepAlive = false;
            oFtp.UseBinary = true;
            oFtp.UsePassive = true;
            oFtp.Timeout = 10000000;
            oFtp.ReadWriteTimeout = 10000000;
            oFtp.Method = WebRequestMethods.Ftp.UploadFile;
            oFtp.ContentLength = oFile.Length;
            var arrContent = File.ReadAllBytes(oFile.FullName);
            using (var oFileStream = oFile.OpenRead())
            {
                using (var oStream = oFtp.GetRequestStream())
                {
                    int iReadBytes;
                    do
                    {
                        iReadBytes = oFileStream.Read(arrContent, 0, int.Parse(oFile.Length.ToString(CultureInfo.InvariantCulture)));
                        oStream.Write(arrContent, 0, iReadBytes);
                    } while (iReadBytes != 0);

                    bUpload = true;
                    oStream.Flush();
                    oStream.Close();
                    oFileStream.Close();
                }
            }
            File.Delete(sSourceLocationPath + oFile.Name);
        }
        catch (Exception ex)
        {
            LogMessage(ex.Message);
            bUpload = false;
        }
        return bUpload;
    }

***** РЕДАКТИРОВАТЬ ***** Я создал журнал сетевой трассировки, как было предложено, и получил следующий результат (ПРИМЕЧАНИЕ: я изменил фактический IP-адрес и имя файла в этом листинге):

System.Net Verbose: 0 : [27252] WebRequest::Create(ftp://1.2.3.4//file.zip)
System.Net Information: 0 : [27252] FtpWebRequest#28316044::.ctor(ftp://1.2.3.4//file.zip)
System.Net Verbose: 0 : [27252] Exiting WebRequest::Create()    -> FtpWebRequest#28316044
System.Net Verbose: 0 : [27252] FtpWebRequest#28316044::GetRequestStream()
System.Net Information: 0 : [27252] FtpWebRequest#28316044::GetRequestStream(Method=STOR.)
System.Net Information: 0 : [27252] Current OS installation type is 'Client'.
System.Net Verbose: 0 : [27252] ServicePoint#39974954::ServicePoint(1.2.3.4:21)
System.Net.Sockets Verbose: 0 : [27252] Socket#24230272::Socket(AddressFamily#2)
System.Net.Sockets Verbose: 0 : [27252] Exiting Socket#24230272::Socket() 
System.Net.Sockets Verbose: 0 : [27252] Socket#16745860::Socket(AddressFamily#23)
System.Net.Sockets Verbose: 0 : [27252] Exiting Socket#16745860::Socket() 
System.Net.Sockets Verbose: 0 : [27252] DNS::TryInternalResolve(1.2.3.4)
System.Net.Sockets Verbose: 0 : [27252] Socket#24230272::Connect(1.2.3.4:21#1294145406)
System.Net.Sockets Error: 0 : [27252] Socket#24230272::UpdateStatusAfterSocketError() - TimedOut
System.Net.Sockets Error: 0 : [27252] Exception in Socket#24230272::Connect - A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 1.2.3.4:21.
System.Net Error: 0 : [27252] Exception in FtpWebRequest#28316044::GetRequestStream - Unable to connect to the remote server.
   at System.Net.FtpWebRequest.GetRequestStream()
System.Net Verbose: 0 : [27252] Exiting FtpWebRequest#28316044::GetRequestStream() 

person Chuck B    schedule 02.01.2015    source источник
comment
Включите сетевую трассировку, чтобы увидеть, что на самом деле делается. Инструкции здесь   -  person user957902    schedule 03.01.2015
comment
Как вы используете версию Release | x86 за пределами Visual Studio?   -  person user957902    schedule 03.01.2015
comment
@ user957902 Я запускаю Release | x86, дважды щелкнув файл .exe в каталоге bin \ x86 \ Release ... Включение сетевой трассировки сейчас даст вам знать, что я нашел.   -  person Chuck B    schedule 03.01.2015
comment
@ user957902 Трассировка показала: System.Net.Sockets Error: 0: [9296] Exception in Socket # 39974954 :: Connect - Попытка подключения не удалась, потому что подключенная сторона не ответила должным образом через определенный период времени, или установленное соединение не удалось из-за подключенный хост не смог ответить ----- Для меня это не имеет особого смысла, потому что он работает в режиме отладки --- Почему он истекает в режиме выпуска?   -  person Chuck B    schedule 05.01.2015
comment
Вы пробовали запустить сборку DEBUG | x86 вне Visual Studio?   -  person user957902    schedule 05.01.2015
comment
@ user957902 Да, я запустил exe прямо из bin \ x86 \ Debug, и он отлично работает.   -  person Chuck B    schedule 05.01.2015
comment
@ user957902 Я только что запустил отладочную версию, и теперь у нее те же ошибки, что и в версии Release --- у них обоих: Не удается получить настройки прокси для Uri '...'. Код ошибки: 12180. Примерно в середине журнала трассировки сети - я изучу это и посмотрю, связано ли это с тайм-аутом.   -  person Chuck B    schedule 05.01.2015
comment
Хорошо, решена первая проблема в трассировке, касающаяся настроек прокси ... Я сделал это, отключив прокси по умолчанию в файле конфигурации следующим образом: 'code' ‹system.net› ‹defaultProxy enabled = false useDefaultCredentials = false› ‹proxy /› ‹Список обхода /› ‹модуль /› ‹/defaultProxy› ‹/system.net›   -  person Chuck B    schedule 05.01.2015
comment
Несколько очевидных вещей, которые стоит проверить. Совпадает ли содержимое App.Config в каталогах Release и Debug? Трассировка показывает правильный IP-адрес целевого FTP-сервера правильно? Если проводная акула не показывает, что пакеты не выходят, то при условии, что уровень IP работает правильно, вероятно, используется адаптер обратной связи. Убедитесь, что в вашей таблице маршрутизации нет ничего странного. Вы можете просмотреть его с помощью route PRINT в командной строке. Вы также используете 32-битную или 64-битную ОС Windows?   -  person user957902    schedule 05.01.2015
comment
@ user957902 Хорошие предложения - 1. app.config идентичен в Release и Debug. 2. Трассировка показывает правильный IP-адрес целевого сервера. 3. WireShark показывает пакеты, когда я выполняю в VS2013 или вручную FTP с помощью WinSCP, но не показывает никаких соответствующих пакетов, когда я запускаю приложение из каталога bin \ x86 \ Release. 4. Я просмотрел таблицу маршрутизации с помощью route PRINT, и мне все это показалось странным. 5. Я использую 64-разрядную версию Win 8 в качестве ОС, но собираю ее для x86. --- Я попробую удалить BitDefender и посмотрю, повлияет ли это на результат ...   -  person Chuck B    schedule 05.01.2015
comment
Проверьте настройки исполняемого VS-проекта. Они могут быть разными для отладки и выпуска. Ваш исполняемый файл создается явно для x86 или ANY_CPU в настройках проекта VS?   -  person user957902    schedule 05.01.2015
comment
@ user957902 Я думал об этом, но Debug и Release - это 32-битные сборки. Я удалил Bit Defender, и все мои проблемы исчезли. По словам нашего системного администратора, оказывается, что в Bit Defender включен брандмауэр, но конечному пользователю не передается никаких уведомлений или указаний. Похоже, что он блокирует некоторые приложения от связи через FTP, он просто не знает, какие из них настроены для блокировки. Спасибо за вашу помощь в этом вопросе - по крайней мере, я узнал о возможности сетевой трассировки - отличный инструмент, который я буду часто использовать. С наилучшими пожеланиями, Чак.   -  person Chuck B    schedule 05.01.2015


Ответы (1)


Отличным предложением было использовать возможность сетевой трассировки (спасибо user957902!) Однако виновата была «безопасность конечных точек» Bitdefender, управляемая системным администратором. Я считаю, что это был какой-то брандмауэр, работающий в скрытом режиме, блокирующий FTP-трафик от одних приложений (мои скомпилированные файлы) и позволяющий проходить другим (VS2013). Всегда смотрите на свое программное обеспечение безопасности и спрашивайте своих системных администраторов при устранении неполадок такого рода, особенно если трафик работает в некоторых случаях, но не в других - если это не имеет для вас смысла, попробуйте включить или отключить этот тип утилиты .

С уважением, Чак

person Chuck B    schedule 05.01.2015