Question

After I deployed my mobile service to Azure, calls to the service fails because of this error:

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

The error only occurs on Azure side. When I test the service locally, the connection to the remote database works without a problem.

I separated my solution into several projects:

  • Web Api
  • Business Logic
  • Data Access (contains the DbContext, database first)
  • Common (contains the entities generated by EF)

As I always do, I copied the connection string generated in my app.config of the DataAccess Assembly into the connectionStrings-Element of my web.config (Web Api project).

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

In the web deploy settings, I selected the connection string for "ApplicationEntities". I tested it with and without the option "Use this connection string at runtime (update destination web.config). I always get the same error.

Then I got curious and logged the connection strings available via the ConfigurationManager with something like this:

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

I got two connection strings:

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;

The username and password is strangely different from the username and password stated in the management portal. Also the EF-Metadata information get lost.

I get this connection strings when testing locally:

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\"

I expect to get the same connection strings when running on Azure. Any idea what's going wrong?

Update:

I just went for remote debugging the service (see here). As I opened the downloaded publish-profile in my text editor, I discovered that there is an attribute SQLServerDBConnectionString - containing the connection string that always gets forced when deployed - with the same username and password I'm not aware of that it exists. I tried to overrwite this connection string but it did not help. That connection remains the active.

Update 2 / May 29th 2014:

Seems that in the meantime the error has been fixed by the azure mobile team. Still running the same code using the database first approach and it's working now. Thanks a lot!

Was it helpful?

Solution 2

Just wanted to give an update that I have been looking at this for some time and think I for the first time see it too. I don't know what is going on but wanted to let you know that we are indeed looking at it.

Henrik

OTHER TIPS

I have myself tried using DB first approach with dot net backend mobile services & ran into same sort of problems as you. Digging around further, following is my observation :

  1. The azure mobile service with dot net backend must use code first approach only. This generates a specialised connection string with metadata (starting with res:)
  2. The name of the connection string has to be the same as it is when you download the default sample todo app I.e. Ms_TableConnectionString.

There is an option in azure websites to select custom SQL provider to help make a custom connection string, this option, however, is not available for dot net backend mobile service in Azure Management portal.

P.s. Posting as answer because I don't have a enough points to comment..

(I don't have enough points to comment so having to do this as an answer)

Henrik, I have this same problem. If I ftp on to the box I can see that the web.config has the correct connection string but it fails as trying to use the username in the SQLServerDBConnectionString property (OoWUqr****Login). Is it possible you could let me know in what order it is looking for connection strings and where?

And if it can't stop it using the other user is there a way I can permission them for the correct database through mobile services?

Thanks

F

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top