Azure移动服务-发布后未找到连接字符串

在将移动服务部署到Azure后，由于以下错误，对服务的调用失败:

No connection string named 'ApplicationEntities' could be found in the application config file.

错误只发生在Azure端。当我在本地测试服务时，与远程数据库的连接正常工作。

我把我的解决方案分成几个项目:

• Web Api
业务逻辑
• 数据访问(包含DbContext，首先是数据库)
• Common(包含EF生成的实体)

就像我总是做的那样，我将DataAccess Assembly的app.config中生成的连接字符串复制到web.config (Web Api项目)的connectionStrings -元素中。

<connectionStrings>    
    <add name="ApplicationEntities" connectionString="<the connection string>" providerName="System.Data.EntityClient" />
</connectionStrings>

在web部署设置中，我为"ApplicationEntities"选择了连接字符串。我测试了它有和没有选项"在运行时使用此连接字符串(更新目的地web.config)"。我总是得到同样的错误。

然后我很好奇，并通过ConfigurationManager记录了可用的连接字符串，如下所示:

StringBuilder sb = new StringBuilder();
for (int i = 0; i < ConfigurationManager.ConnectionStrings.Count; i++)
{
    sb.AppendLine(ConfigurationManager.ConnectionStrings[i].ConnectionString);
}
trace.Info(sb.ToString());

我有两个连接字符串:

data source=.'SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|aspnetdb.mdf;User Instance=true
Data Source=theserver.database.windows.net;Initial Catalog=thedb_db;User ID=theuser;Password=thepassword;Asynchronous Processing=True;TrustServerCertificate=False;

用户名和密码与管理门户中显示的用户名和密码奇怪地不同。此外，EF-Metadata信息也会丢失。

在本地测试时我得到这个连接字符串:

data source=.''SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|aspnetdb.mdf;User Instance=true
metadata=res://*/DataContext.ApplicationEntities.csdl|res://*/DataContext.ApplicationEntities.ssdl|res://*/DataContext.ApplicationEntities.msl;provider=System.Data.SqlClient;provider connection string='"data source=theserveraddress,1433;initial catalog=thedb_db;persist security info=True;user id=theusername;password=thepassword;MultipleActiveResultSets=True;Trusted_Connection=False;Encrypt=True;Connection Timeout=30;App=EntityFramework'"

我希望在Azure上运行时得到相同的连接字符串。知道哪里出错了吗?

更新:

我只是去远程调试服务(见这里)。当我在文本编辑器中打开下载的发布配置文件时，我发现有一个属性SQLServerDBConnectionString -包含在部署时总是被强制的连接字符串-具有相同的用户名和密码，我不知道它存在。我试图重写这个连接字符串，但它没有帮助。该连接保持活动状态。

更新2/May 29 2014:

似乎在此期间这个错误已经被azure移动团队修复了。仍然使用数据库优先的方法运行相同的代码，现在可以正常工作了。非常感谢!