Как вызвать update-database из консоли диспетчера пакетов в Visual Studio против SQL Azure?

Question

Я использую EF 6.1.3. Я пытаюсь вызвать update-database из консоли диспетчера пакетов против SQL Azure. Все работает нормально с локальным SQL Express 2012. Я могу успешно подключиться к серверу с SQL Server Management Studio 2012/2014 и с Visual Studio Server Explorer с теми же учетными данными. Я сделал исключение на брандмауэре SQL Azure с портала управления уже, но я получаю сообщение об ошибке:

Номер ошибки: 18456, Состояние: 1, Класс: 14 Войти не удалось для пользователя «XXXXXXX». В этом сеансе был назначен идентификатор трассировки «xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx». Предоставьте этот идентификатор трассировки для поддержки клиентов, когда вам понадобится помощь.

Исключение:

System.Data.SqlClient.SqlException (0x80131904): Войти потерпело неудачу для потребителя 'ххххх'. В этом сеансе был назначен идентификатор трассировки «xxxxxx». Предоставьте этот идентификатор трассировки для поддержки клиентов, когда вам понадобится помощь. на System.Data.ProviderBase.DbConnectionPool.TryGetConnection (DbConnection owningObject, UInt32 waitForMultipleObjectsTimeout, булевой allowCreate, булевой onlyOneCheckConnection, DbConnectionOptions userOptions, DbConnectionInternal & соединение) в System.Data.ProviderBase.DbConnectionPool.TryGetConnection (DbConnection owningObject, TaskCompletionSource 1 retry, DbConnectionOptions userOptions, DbConnectionInternal& connection) at System.Data.ProviderBase.DbConnectionFactory.TryGetConnection(DbConnection owningConnection, TaskCompletionSource 1 повторных попыток , DbConnectionOptions userOptions, DbConnectionInternal oldConnection, DbConnectionInternal & соединение) на System.Data.ProviderBase.DbConnectionInternal.TryOpenConnectionInternal (DbConnection outerConnection, DbConnectionFactory ConnectionFactory, TaskCompletionSource 1 retry, DbConnectionOptions userOptions) at System.Data.ProviderBase.DbConnectionClosed.TryOpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory, TaskCompletionSource 1 повторных попыток, DbConnectionOptions userOptions) на System.Data.SqlClient.SqlConnection.TryOpenInner (TaskCompletionS 1 retry) at System.Data.SqlClient.SqlConnection.TryOpen(TaskCompletionSource 1 ч н повторных попыток) на System.Data.SqlClient.SqlConnection.Open() в System.Data.Entity.Infrastructure.Interception.DbConnectionDispatcher.b__36 (DbConnection т, с) DbConnectionInterceptionContext в System.Data.Entity.Infrastructure. Interception.InternalDispatcher 1.Dispatch[TTarget,TInterceptionContext](TTarget target, Action 2 операции, TInterceptionContext interceptionContext, действий 3 executing, Action 3) выполнен в System.Data.Entity.Infrastructure.Interception.DbConnectionDispatcher.Open (соединение DbConnection, DbInterceptionContext interceptionContext) в System.Data.Entity.SqlServer.SqlProviderServices. <> c__DisplayClass33.b__32() at System.Data.Entity.SqlServer.DefaultSqlExecutionStrategy. <> c__DisplayClass1.b__0() в System.Data.Entity.SqlServer.DefaultSqlExecutionStrategy.Execute [TResult] (Func 1 operation) at System.Data.Entity.SqlServer.DefaultSqlExecutionStrategy.Execute(Action operation) at System.Data.Entity.SqlServer.SqlProviderServices.UsingConnection(DbConnection sqlConnection, Action 1 акт) на System.Data.Entity.SqlServer.SqlProviderServices.UsingMasterConnection (DbConnection SqlConnection, действий 1 act) at System.Data.Entity.SqlServer.SqlProviderServices.CreateDatabaseFromScript(Nullable 1 CommandTimeout , DbConnection SqlConnection, Строка createDatabaseScript) в System.Data.Entity.SqlServer.SqlProviderServices.DbCreateDatabase (соединение DbConnection, Nullable 1 commandTimeout, StoreItemCollection storeItemCollection) at System.Data.Entity.Core.Common.DbProviderServices.CreateDatabase(DbConnection connection, Nullable 1 CommandTimeout, StoreItemCollection storeItemCollection) на System.Data.Entity.Core.Objects.ObjectContext.CreateDatabase() в System.Data.Entity.Migrations.Utilities.DatabaseCreator.Create (соединение DbConnection) в System.Data.Entity.Migrations.DbMigrator.EnsureDatabaseExists (Actio п mustSucceedToKeepDatabase) в System.Data.Entity.Migrations.Infrastructure.MigratorBase.EnsureDatabaseExists (Действие mustSucceedToKeepDatabase) в System.Data.Entity.Migrations.DbMigrator.Update (Строка targetMigration) в System.Data.Entity.Migrations.Infrastructure .MigratorBase.Обновление (String targetMigration) в System.Data.Entity.Migrations.Design.ToolingFacade.UpdateRunner.Run() в System.AppDomain.DoCallBack (CrossAppDomainDelegate callBackDelegate) в System.AppDomain.DoCallBack (CrossAppDomainDelegate callBackDelegate) в системе. Data.Entity.Migrations.Design.ToolingFacade.Run (бегун BaseRunner) в System.Data.Entity.Migrations.Design.ToolingFacade.Update (String targetMigration, Boolean force) в System.Data.Entity.Migrations.UpdateDatabaseCommand. <> c__DisplayClass2. < .ctor> b__0() в System.Data.Entity.Migrations.MigrationsDomainCommand.Execute (команда Action) ClientConnectionId: ххххх

Строка соединения я использую:

Update-Database -SourceMigration xxxxxx -TargetMigration xxxxx -StartUpProjectName xxxxx -ProjectName xxxxx.Migrations -ConfigurationTypeName "xxxxx.MigrationConfiguration" -ConnectionString "Server = tcp: xxxxxx.database.windows.net, 1433; База данных = xxxxxx; Идентификатор пользователя = xxxxxx; Пароль = xxxxxx ; Trusted_Connection = False; Шифрование = Истина; Тайм-аут подключения = 30; " -ConnectionProviderName "System.Data.SqlClient" -Force

Я получил строку подключения с портала. Кто-нибудь знает, где находится вопрос или как его устранять?

В сообщении об ошибке обнаруживается только одна странная вещь: Ошибка входа для пользователя «xxxxxxx». Пользователь фактически является xxxx @ serverName. Есть ли трюк с побегами здесь?

Answer 1

Как я и предполагал - символ @ в имени пользователя ломает его. По неизвестной мне причине сгенерированное имя пользователя для Sql Azure является именем пользователя @ serverName. Когда вы получаете параметр строки соединения с порталом Azure Management и положить его EF миграции в двойных кавычках:

-ConnectionString «connString Превед @ ServerName»

Вы получаете «имя пользователя @ ServerName msgstr "отключить, поэтому базовый поставщик подключения использует только" имя пользователя ", а не" имя_пользователя @ имя_сервера ".

Entity Framework читает имя пользователя как «имя пользователя», а не «имя_пользователя @ имя_сервера», и вы получаете отказ от сервера. Почти каждая программа имеет свои умения, чтобы проверить, помещены ли вы или нет суффикс @serverName, и делает трюк за кулисами. EF немного более строгая и не работает. (и мне это нравится)

Решение проблемы прост - разверните кавычки. Окружите параметр строки соединения с одинарными кавычками и имя в двойные кавычки, например, что:

-ConnectionString «connString с„имя_пользователя @ ServerName“....»

Таким образом, имя пользователя является хранительницей в целом, а не отсекается при символе @, а EF правильно соединяется.