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

我使用的是EF 6.1.3.我试图从包管理器控制台调用update-database对sql Azure.使用本地sql Express 2012,一切正常.我可以使用sql Server Management Studio 2012/2014和具有相同凭据的Visual Studio Server Explorer成功连接到服务器.我已从管理门户网站上对sql Azure防火墙进行了例外但我收到错误：

Error Number:18456,State:1,Class:14
Login Failed for user ‘xxxxxxx’.
This session has been assigned a tracing ID of ‘xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx’. Provide this tracing ID to customer support when you need assistance.

例外是：

System.Data.sqlClient.sqlException (0x80131904): Login Failed for user ‘xxxxx’.
This session has been assigned a tracing ID of ‘xxxxxx’. Provide this tracing ID to customer support when you need assistance.
at System.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, UInt32 waitForMultipleObjectsTimeout, Boolean allowCreate, Boolean onlyOneCheckConnection, DbConnectionoptions userOptions, DbConnectionInternal& connection)
at System.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, taskcompletionsource1 retry, DbConnectionoptions userOptions, DbConnectionInternal& connection)
at System.Data.ProviderBase.DbConnectionFactory.TryGetConnection(DbConnection owningConnection, taskcompletionsource1 retry, DbConnectionoptions userOptions, DbConnectionInternal oldConnection, DbConnectionInternal& connection)
at System.Data.ProviderBase.DbConnectionInternal.TryOpenConnectionInternal(DbConnection outerConnection, DbConnectionFactory connectionFactory, taskcompletionsource1 retry, DbConnectionoptions userOptions)
at System.Data.ProviderBase.DbConnectionClosed.TryOpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory, taskcompletionsource1 retry, DbConnectionoptions userOptions)
at System.Data.sqlClient.sqlConnection.TryOpenInner(taskcompletionsource1 retry)
at System.Data.sqlClient.sqlConnection.TryOpen(taskcompletionsource1 retry)
at System.Data.sqlClient.sqlConnection.open()
at System.Data.Entity.Infrastructure.Interception.DbConnectiondispatcher.b__36(DbConnection t, DbConnectionInterceptionContext c)
at System.Data.Entity.Infrastructure.Interception.Internaldispatcher1.dispatch[TTarget,TInterceptionContext](TTarget target, Action2 operation, TInterceptionContext interceptionContext, Action3 executing, Action3 executed)
at System.Data.Entity.Infrastructure.Interception.DbConnectiondispatcher.Open(DbConnection connection, DbInterceptionContext interceptionContext)
at System.Data.Entity.sqlServer.sqlProviderServices.<>c__displayClass33.b__32()
at System.Data.Entity.sqlServer.DefaultsqlExecutionStrategy.<>c__displayClass1.b__0()
at System.Data.Entity.sqlServer.DefaultsqlExecutionStrategy.Execute[TResult](Func1 operation)
at System.Data.Entity.sqlServer.DefaultsqlExecutionStrategy.Execute(Action operation)
at System.Data.Entity.sqlServer.sqlProviderServices.UsingConnection(DbConnection sqlConnection, Action1 act)
at System.Data.Entity.sqlServer.sqlProviderServices.UsingMasterConnection(DbConnection sqlConnection, Action1 act)
at System.Data.Entity.sqlServer.sqlProviderServices.CreateDatabaseFromScript(Nullable1 commandTimeout, DbConnection sqlConnection, String createDatabaseScript)
at System.Data.Entity.sqlServer.sqlProviderServices.DbCreateDatabase(DbConnection connection, Nullable1 commandTimeout, StoreItemCollection storeItemCollection)
at System.Data.Entity.Core.Common.DbProviderServices.CreateDatabase(DbConnection connection, Nullable1 commandTimeout, StoreItemCollection storeItemCollection)
at System.Data.Entity.Core.Objects.ObjectContext.CreateDatabase()
at System.Data.Entity.Migrations.Utilities.DatabaseCreator.Create(DbConnection connection)
at System.Data.Entity.Migrations.DbMigrator.EnsureDatabaseExists(Action mustSucceedToKeepDatabase)
at System.Data.Entity.Migrations.Infrastructure.MigratorBase.EnsureDatabaseExists(Action mustSucceedToKeepDatabase)
at System.Data.Entity.Migrations.DbMigrator.Update(String targetMigration)
at System.Data.Entity.Migrations.Infrastructure.MigratorBase.Update(String targetMigration)
at System.Data.Entity.Migrations.Design.ToolingFacade.UpdateRunner.Run()
at System.AppDomain.DoCallBack(CrossAppDomainDelegate callBackDelegate)
at System.AppDomain.DoCallBack(CrossAppDomainDelegate callBackDelegate)
at System.Data.Entity.Migrations.Design.ToolingFacade.Run(BaseRunner runner)
at System.Data.Entity.Migrations.Design.ToolingFacade.Update(String targetMigration, Boolean force)
at System.Data.Entity.Migrations.UpdateDatabaseCommand.<>c__displayClass2.<.ctor>b__0()
at System.Data.Entity.Migrations.MigrationsDomainCommand.Execute(Action command)
ClientConnectionId:xxxxx

我使用的连接字符串是：

Update-Database -SourceMigration xxxxxx -TargetMigration xxxxx -StartUpProjectName xxxxx -ProjectName xxxxx.Migrations -ConfigurationTypeName “xxxxx.MigrationConfiguration” -ConnectionString “Server=tcp:xxxxxx.database.windows.net,1433;Database=xxxxxx;User ID=xxxxxx;Password=xxxxxx;Trusted_Connection=False;Encrypt=True;Connection Timeout=30;” -ConnectionProviderName “System.Data.sqlClient” -Force

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

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

解决方法:

我怀疑 – 用户名中的@字符会破坏它.由于我不知道的原因,生成的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正确连接.