如何从Visual Studio中的包管理器控制台调用针对SQL Azure的update-database？

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'登录失败.已为此会话分配了跟踪ID"xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx".在需要帮助时,请将此跟踪ID提供给客户支持.

例外是:

System.Data.SqlClient.SqlException(0x80131904):用户'xxxxx'登录失败.已为此会话分配了跟踪ID"xxxxxx".在需要帮助时,请将此跟踪ID提供给客户支持.在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, TaskCompletionSource1重试,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, TaskCompletionSource1重试,DbConnectionOptions USEROPTIONS)在System.Data.SqlClient.SqlConnection.TryOpenInner(TaskCompletionSource 1 retry) at System.Data.SqlClient.SqlConnection.TryOpen(TaskCompletionSource1重试)在System.Data. System.Data.Entity.Infrastructure.Interception.InternalDispatch中的System.Data.Entity.Infrastructure.Interception.DbConnectionDispatcher.b__36(DbConnection t,DbConnectionInterceptionContext c)中的SqlClient.SqlConnection.Open()ER 1.Dispatch[TTarget,TInterceptionContext](TTarget target, Action2的操作,TInterceptionContext interceptionContext,动作3 executing, Action3中执行)在System.Data.Entity.Infrastructure.Interception.DbConnectionDispatcher.Open在System.Data.Entity.SqlServer.SqlProviderServices(的DbConnection连接,DbInterceptionContext interceptionContext).<> c__DisplayClass33.b__32()在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, Action1个动作)在System.Data.Entity.SqlServer.SqlProviderServices.UsingMasterConnection (的DbConnection SqlConnection的,动作1 act) at System.Data.Entity.SqlServer.SqlProviderServices.CreateDatabaseFromScript(Nullable1的CommandTimeout,的DbConnection的SqlConnection,字符串createDatabaseScript)在System.Data.Entity.SqlServer.SqlProviderServices.DbCreateDatabase(的DbConnection连接,可空1 commandTimeout, StoreItemCollection storeItemCollection) at System.Data.Entity.Core.Common.DbProviderServices.CreateDatabase(DbConnection connection, Nullable1的CommandTimeout,StoreItemCollection storeItemCollection)在System.Data.Entity.Core.Objects.ObjectContext. System.Data.Enti上的System.Data.Entity.Migrations.Utilities.DatabaseCreator.Create(DbConnection连接)中的CreateDatabase()ty.Migrations.DbMigrator.EnsureDatabaseExists(动作mustSucceedToKeepDatabase)在System.Data.Entity.Migrations.Infrastructure.MigratorBase.EnsureDatabaseExists(动作mustSucceedToKeepDatabase)在System.Data.Entity.Migrations.DbMigrator.Update(字符串targetMigration)在System.Data.位于System.AppDomain.DoCallBack的System.AppDomain.DoCallBack(CrossAppDomainDelegate callBackDelegate)上的System.Data.Entity.Migrations.Design.ToolingFacade.UpdateRunner.Run()中的Entity.Migrations.Infrastructure.MigratorBase.Update(String targetMigration)(CrossAppDomainDelegate callBackDelegate) )在System.Data.Entity.Migrations.Design.ToolingFacade.Run(跑垒员浇道)在System.Data.Entity.Migrations.Design.ToolingFacade.Update(字符串targetMigration,布尔力)在System.Data.Entity.Migrations.UpdateDatabaseCommand .<> c__DisplayClass2.<.ctor> b__0()在System.Data.Entity.Migrations.MigrationsDomainCommand.Execute(Action command)ClientConnectionId:xxxxx

我使用的连接字符串是:

更新数据库-SourceMigration XXXXXX -TargetMigration XXXXX XXXXX -StartUpProjectName -ProjectName xxxxx.Migrations -ConfigurationTypeName "xxxxx.MigrationConfiguration" -ConnectionString"服务器= TCP:xxxxxx.database.windows.net,1433;数据库= XXXXXX;用户ID = XXXXXX; Password = xxxxxx; Trusted_Connection = False; Encrypt = True;连接超时= 30;" -ConnectionProviderName"System.Data.SqlClient" - Force

我从门户网站获得了连接字符串.有谁知道问题在哪里或如何解决这个问题？

我在错误消息中只发现一个奇怪的事情:用户'xxxxxxx'登录失败.用户实际上是xxxx @ serverName.这里有逃脱伎俩吗？

Answer 1

我怀疑 - 用户名中的@字符会破坏它.由于我不知道的原因,生成的Sql Azure用户名是username @ serverName.从Azure管理门户获取连接字符串参数并将其用于双引号的EF迁移时:

-ConnectionString"connString with username @ serverName"

您获得"username @ serverName"截止,因此底层连接提供程序仅使用"username"而不是"username @ serverName".

实体框架将用户名读取为"用户名"而不是"username @ serverName",您将被服务器拒绝.几乎每个程序都有智能来检查你是否放置了@serverName后缀,并在幕后做了诀窍.EF有点严格,但没有.( 我喜欢它)

问题的解决方案很简单 - 转过报价.用单引号括起连接字符串参数,用双引号括起来:

-ConnectionString'connString with"username @ serverName"....'

这样,用户名作为整体保留,而不是@字符的截止,EF正确连接.