0

I have a webapp deployed to an Azure Web App. In the webapp I am using MembershipReboot, with Entity Framework. The Sql Server database is also in Azure.

It is deployed via BitBucket integration and continuous deployment, in a staging slot.

As part of the build process, a web.config transfrom, changes the connection string value to "dummy".

I set this the connection string, named MembershipReboot, in the Azure portal.

When I browse to the application, I get this error:

Format of the initialization string does not conform to specification starting at index 0.

If I change the connection string in the web.config, to be the Sql Azure connection string the app loads fine. If I set it back to "dummy" then I get the above error.

This indicates to me that the connection string set in the Azure portal isn't being picked up by the application.

I created this Azure enviromnent using the ARM template deploy, mixed with some Azure powershell commands. I've tried creating the environment by hand too, with the same issue.

Any ideas on what to look at next?

edit: Just to say, the correct connection string is viewable within Kudu.

nachojammers
  • 1,225
  • 1
  • 10
  • 12
  • Why do you think that error indicates that "the connection string set in the Azure portal isn't being picked up by the application"? – Zain Rizvi Sep 08 '15 at 18:25
  • When I changed the connection string in the web.config, to be the correct connection string, the application worked. When it is set to "dummy" it didn't work. The correct connection string was already set in the Azure portal. Therefore I concluded the app wasn't picking the connection string from the portal. See my answer below, to see how we fixed it. – nachojammers Sep 09 '15 at 09:30

1 Answers1

0

Managed to fix this.

It was due to StructureMap being invoked, and creating a database context (via global.asax), before the environment was providing the correct connection string.

In our case, the app was mixing Owin startup and global.asax Application_Start, we had to move the global.asax startup into the Owin startup, and not allow the database context to be created during that startup. I suspect we could have just done the latter.

nachojammers
  • 1,225
  • 1
  • 10
  • 12