Соединение с удаленным SQL-сервером прерывается при обновлении веб-сервера до .net framework 4.6.1

В настоящее время мы работаем над обновлением нашего веб-приложения asp.net(размещенного на IIS 7.5) с .net framework v4.5 до v4.6.1. В небольших более низких средах/локальном развитии, в которых SQL-сервер работает в том же поле, что и IIS, это обновление отлично работает и ничего не сломает. Однако, как только мы обновляем наши веб-серверы в наших тестовых средах, которые удаляют сервер SQL удаленно с наших веб-серверов, наше приложение больше не может устанавливать соединение с базой данных. Мы получаем эту ошибку:

Connection Timeout Expired. The timeout period elapsed while attempting to
consume the pre-login handshake acknowledgement. This could be because the
pre-login handshake failed or the server was unable to respond back in time.

Сервер SQL работает с версией CLR версии 4.0.30319. Мы используем Entity Framework версии 6.0.0.0 для доступа к данным, а все строки подключения используют интегрированную защиту. Нужно ли обновлять ящики с сервером SQL Server.net 4.6.1? Я не понимаю, почему это необходимо для нашего приложения, чтобы установить соединение с базой данных, но я не смог найти никаких указаний в MSDN об этом.

EDIT:

После этого сбоя мы понизили наши веб-серверы до .net v4.5, и нам удалось восстановить соединение с SQL-сервером. повторное обновление до версии 4.6.1 снова вызвало поломку. Поэтому мы относительно уверены, что обновление является проблемой, а не изменением кода приложения и/или настроек IIS.

Ответ 1

Обновление - похоже, мы нашли (по крайней мере, решение) проблему. Оказывается - как было предложено исключение - что, увеличивая свойство тайм-аута соединения на нашей строке соединения (по умолчанию - 15 секунд, мы установили его на 60 секунд), мы смогли установить соединение с нашей базой данных через наше веб-приложение. Однако открытие этого соединения занимает очень много времени, поэтому мы начали искать решения, чтобы быстрее открыть наше соединение. Мы обнаружили, что на нашем сервере базы данных мы имеем Netbios через TCP/IP, и что, открыв порты UDP (137, 138) в нашей сети для доступа Netbios, нам удалось быстрее открыть соединения с базой данных, при < 1 секунда вместо > 15 секунд. Мы все еще не уверены, почему обновление .net выявило эту проблему. Путем тестирования с UDL файлом мы смогли установить, что сетевое подключение к нашей базе данных примерно одинаково на наших веб-серверах на .net 4.5, как на наших веб-серверах на .net 4.6.1. Таким образом, кажется, что наши связи открываются так медленно, что мы уже очень близки к тайм-ауту, и какая-то дополнительная логика/трещина в 4.6.1 поставила нас на край. Я обновлю, если мы найдем больше ясности в этом вопросе.

Ответ 2

Прежде всего - эта проблема возникает только при использовании проверки подлинности Active Directory.

Я справился с грязным исправлением: добавьте свой сервер MSSQL в свой локальный (компьютер, который не может подключиться к серверу MSSQL), файл hosts (% windir%\system32\drivers\etc\hosts).

Например: 192.168.0.5 mssqlserver

Это действительно не имеет значения. Он также хорошо работает, если у вас несколько серверов SQL на одном IP-адресе (подключение через NAT).

Это грязное исправление также устранит медленную загрузку с помощью проблемы с SQL Management Studio.

Ответ 3

В следующей статье описывается новая строка строки подключения по умолчанию для соединений SQL Server в .net 4.6.1.

https://blogs.msdn.microsoft.com/dataaccesstechnologies/2016/05/07/connection-timeout-issue-with-net-framework-4-6-1-transparentnetworkipresolution/

Это должно было решить одну проблему в некоторых средах, но также вызвало проблему, с которой вы столкнулись в других средах.

В принципе, вам нужно добавить следующую строку подключения:

TransparentNetworkIPResolution=False;

Ответ 4

вы можете проверить файлы machine.config и web.config в папках windows\micorsoft.net\framework64\v######\config. каждая версия .NET работает в разных конфигурационных файлах. Поскольку тот же код используется в обеих средах, он должен быть из унаследованной от конфига. Я предполагаю, что в 4.6.1 установлено значение по умолчанию для строки подключения для localhost, и поскольку SQL в локальном и dev находятся на одном сервере, это не проблема. Вероятно, вы обнаружите, что конфигурация в версии .NET 4.5 имеет строку подключения, отличную от локального.

если 4.5 и 4.61 используют одни и те же файлы конфигурации, тогда убедитесь, что вы определяете строку подключения по умолчанию, которая будет использоваться инфраструктурой сущности в этом web.config.