9

Я видел несколько сообщений об этом, ни одна из них не решила мою проблему.VS to Azure Ошибка публикации: Ошибка сокета 10054

Я пытаюсь выполнить веб-развертывания в Azure сайте, но в то время обновления файлов я получаю предупреждения:

MSBuild\Microsoft\VisualStudio\v12.0\Web\Microsoft.Web.Publishing.targets(4270,5) Warning : Retrying the sync because a socket error (10054) occurred Retrying operation 'Serialization' on object sitemanifest (sourcePath). Attempt 1 of 10.

В мастере веб-публикации соединение может быть успешно проверен.

Я видел где-то упоминание о том, что я должен включить ненадежные сертификаты, однако я не вижу эту возможность в настройках веб-развертывания в VS2013.

Важные примечания:

  • можно развернуть другие проекты (так что я не думаю, что это вопрос брандмауэра).
  • Мой коллега может выполнить развертывание в Интернете с помощью старой версии моего проекта (так Azure работает нормально).
  • Я не могу выполнить развертывание в Интернете с использованием той же старой версии проекта.

Он также не работает с публикацией FTP, хотя он не дает мне предупреждения об ошибке сокета. Что бы это могло быть?

JK

+1

У меня была та же проблема, и это [ссылка] [1] решил мою проблему [1]: http://stackoverflow.com/questions/5841370/cant-get-my-ec2-windows -server-2008-web-stack-instance-to-receive-publishings –

+1

Спасибо за ответ .... Я видел это, и к сожалению, это не помогло. Ошибка сокета 10054, по-видимому, такая общая, что невозможно правильно диагностировать, не травля через сетевые трассы. Поддержка Microsoft помогла мне диагностировать ее, и моя проблема была что-то в моих рабочих зданиях Wi-Fi, на которые у меня нет доступа к следам, поэтому теперь мне приходится делать большие публикации из дома и из небольших офисов. – JonnyKnottsvill

ответ

12

Для любых других лиц, которые имеют эту проблему, я связался со службой поддержки Azure и инженер схватил следы от их конца сети и шахты для оценки.

Все, что он смог сделать, заключалось в том, что пакеты данных перехватывались где-то между моей машиной и услугами Azure, что приводило к ошибкам таймаута с обоих концов.

Проблема заключается в моей рабочей сети, и я могу успешно публиковать из других сетей после тестирования ...

Обратитесь к сети провайдера и у них расследовать этот вопрос, и в то же время, если это , убедитесь, что вы проверяете возможности публикации в других сетях, поскольку это сработало для меня.

+1

У меня было это в результате чего-то, что делал мой интернет-провайдер. Пробовал в другой сети, и все работало нормально. Я знаю, что не у всех есть несколько широкополосных подключений для переключения между ними, но знание этого может помочь, если вы не можете найти причину этой проблемы. –

+0

В моем случае иногда Pubish работает сразу, иногда требуется несколько попыток, иногда это ошибки после 10 попыток. Weird. –

1

Наша очень похожая проблема с тем же сообщением об ошибке «Повторная попытка синхронизации, поскольку ошибка сокета (10054) произошел» оказался системы в предотвращения вторжений (IPS)

Создание правила исключения на том, что исправили проблему ,

+0

Это интересно. У меня больше нет этой проблемы. Я никогда не нашел для него решения, так как сетевая команда в офисе, в котором я работаю, была очень смущена этим. Я запомню это для любого повторного появления. – JonnyKnottsvill

4

Я знаю, что это старый. Но это может помочь кому-то.

Для меня это были процессы синхронизации для One Drive и Drop Box. Как только я приостановил всю синхронизацию, проблема была решена.

+1

Спасибо! Я прошел через обновления Azure SDK, бесчисленные потоки, просмотрел строки конфигурационных файлов и никуда не денусь.Я отключил синхронизацию OneDrive (бизнес и личность), а затем сразу же смог опубликовать слот Azure Deployment после паузы. В моем случае у меня были несинхронизированные изменения, которые, возможно, были виновниками. – Solo812

+0

То же самое здесь. Как только я приостановил синхронизацию OneDrive (деловую и личную), я смог опубликовать. – user1862876

1

Я бы окончательно сказал, что это проблема с сетью. У меня была такая же проблема при публикации с VS 2015 на Azure Web Sites. Пробовал 10 раз без какой-либо удачи. Отключенный защитник Windows, не повезло. Подключенные из другой сети (через VPN) и бум, все было опубликовано хорошо.

Даже если я отключил свой локальный антивирус, я знаю, что у парней сети есть устройство, которое «очищает» трафик, отправленный из офиса, что означает, что трафик с моей машины на Azure может быть определенно затронут каким-то образом. При подключении через VPN я пропустил это.

Мораль истории: проверьте свою сеть, проверьте свой антивирус и проверьте свою ИТ-команду, если у них есть какое-либо устройство (Gateway antivirus, системы предотвращения вторжений, межсетевые экраны с фанковыми правилами и т. Д.), Возиться с вашим трафиком.

Приветствия

S

+0

Проверял все это. Ничего плохого. Я в полной темноте с этим. –

+0

Хостинг горячей точки на моем телефоне, и загрузка удалась. Я могу порекомендовать это как быстрое решение. – Laurens

0

В моем случае ошибка произошла после слота подкачки и переиздайте к исходному целевому слоту. Решено путем повторной загрузки профиля публикации целевого слота. Причина может быть: а) Слот подкачки влияет на профиль б) Слот подкачки вызывает некоторые за обработку сцен, которые помешали опубликовать в течение периода времени, пока я не получил новый профиль

0

В моем случае, ответ был еще проще : У меня была версия приложения AngularJS v1.21, работающего в Visual Studio через IIS Express. Я начал с него. Как только я «остановил все веб-сайты IIS Express», загрузка пошла так, как ожидалось.

0

я не мог найти ответ в этой теме, но это другой поток, казалось, ответ, который работал для меня: Using WebDeploy (MSDeploy) to deploy to a Microsoft Azure Website target doesn't work

Решение там было:

Microsoft имеют довольно много подтвердил, что это ошибка. Они борются , чтобы воспроизвести проблему.

Чтобы обойти эту проблему, чтобы поставить новую установку приложения в веб-приложение на Azure Portal, называется WEBSITE_WEBDEPLOY_USE_SCM и установите значение ложной. Затем развертывание отлично работает.

Я сделал это, перезапустил веб-приложение, сбросил профиль публикации, затем перезагрузил его, а затем он работал для меня. Я заметил, что URL, который они автопопулируют для публикации, был другим и более случайным, но он сработал!

0

В моем случае это была проблема с ISP, скорость загрузки и стабильность были серьезно затронуты.

Смежные вопросы