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正确连接.

标签：c,entity-framework,azure,azure-sql-database
来源： https://codeday.me/bug/20190609/1202709.html