2013-09-11 2 views
2

Я работаю над типичным веб-приложением, используя облачные сервисы, чтобы узнать, как использовать windows azure. В моем развертывании у меня есть две роли: веб-роль, выполняющая приложение ASP.NET MVC, и роль рабочего, которая предоставляет некоторые вспомогательные службы.Роль рабочего не будет подключаться к SQL Azure

База данных размещена на SQL Azure (в той же подписке и центре обработки данных) и управляется с использованием Entity Framework Code First. Строка соединения - это один доступный Azure.

Странно, что в роли веб-сайта Entity Framework успешно связывает и выполняет запросы к базе данных SQL Azure. Но когда тот же код выполняется в Worker Role, он падает со следующим исключением:

System.Data.SqlClient.SqlException: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified)

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

EDIT: Выполненная роль с использованием Compute Emulator и строки подключения SQL Azure (с уже настроенным корректным исключением брандмауэра), и код не сработал. По-видимому, это происходит только тогда, когда код запускается в Cloud.

EDIT 2: Брандмауэр SQL Azure настроен правильно, чтобы разрешать соединения с Azure Datacenter, о чем свидетельствует успешное соединение веб-роли.

ответ

3

У меня был этот выпуск. Моя веб-роль заключалась в получении строки подключения к базе данных из файла Web.config (потому что преобразования XSLT работают хорошо). По сути, я передавал имя моей строки соединения в конструктор контекста, а не сама строка подключения.

Моя рабочая роль использовала конфигурацию Azure, используя RoleEnvironment.GetConfigurationSettingValue(), чтобы получить строку подключения и передать строку соединения непосредственно в конструктор контекста. Это работало в эмуляторе против производственной базы данных, но не в самом облаке Azure.

Мое решение состояло в том, чтобы прекратить использование конфигурации Azure и вместо этого вставить строку подключения в мой App.config и передать имя строки подключения в конструктор контекста, как это делалось в роли в Интернете. Это решило мою проблему, и рабочая роль смогла подключиться к базе данных без каких-либо проблем.

Конечно, App.config файлы не могут иметь преобразования из коробки, в отличие от файлов Web.config (потому что, эй, кто бы нужно что?), так что я должен был следовать инструкциям here, чтобы это произошло ,

+0

Это было действительно то, что случилось со мной –

0

Убедитесь, что в разделе «Настройка» для базы данных на Azure Portal в разделе «Разрешенные службы» установлены службы Windows Azure = YES. Это специальное правило брандмауэра (0.0.0.0) для служб Windows Azure. Включите этот параметр, чтобы службы Windows Azure подключались к вашим базам данных SQL.

1

Проверьте свои различные конфигурации облаков. (В шаблоне проекта по умолчанию у вас, вероятно, есть один для локального & One for Cloud)

Также проверьте свою другую конфигурацию выпуска, если вы используете Config Transforms. то есть в App.Config/Web.Config, вы можете увидеть App.Debug.Config/App.Release.Config.

Проверьте, не перезаписана ли строка подключения в режиме деблокирования.

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