CODEWITHSUNDEEP
asp.netazureazure-sql-database
user529265
user529265

Reputation: 820

right place to have the connection string

Working with Azure web role that communicates to a SQL Azure database. Currently when I generate an edmx file for the SQL Azure database the connection strings + the username password are added to web.config file. I did a search and there were several entries on how to encrypt web.config/how to use that to switch between dev and prod but I am thinking of moving conn string out of web.config.

Is there a way by which I can move the connection string to the service definition file? Is that a recommended approach? If I move the connection string elsewhere can I still use the edmx and generated objectcontext classes (cause my existing code uses the automatically generated entity class).

Upvotes: 3

Views: 1027

Answers (2)

Guy
Guy

Reputation: 3096

I recommend having the connection string in both places, Service Configuration file (.cscfg) and Web.config. Where I also recommend from the beginning to have your web role able to run outside an Azure environment. It will impact your productivity in the long run. Especially with daily development where you do small changes and need to run the project locally to verify. Running your service locally in IIS, IIS express or Cassini (the codename for the Asp.net env) is currently faster than running your project in the local azure emulator (the devFabric). Regarding your second question about storing the username and password. It all depends on the level of security that you're looking for. The information stored inside your .cscfg are transmitted over https and secured in the Azure cloud the same way your application is secured. That being said, I would store the TEST account credentials in the project for testing and would only put the PRODUCTION storage account credentials in the .cscfg at deployment time to the public/production service.

Upvotes: 1

Igorek
Igorek

Reputation: 15850

It is best to move your connection strings into service config file. This allows you to switch over to a different SQL Azure database w/o redeployment. Switching to a different SQL Azure database w/o redeployment is useful when one has crashed or is timing out and you have a backup ready on a different server to switch over to.

You will need to initialize your object contexts by providing the connection string separately however.

Use the RoleEnvironment.IsAvailable to find out if you're running under Azure and the following code to read the setting in .cscfg:

var connectionString = RoleEnvironment.GetConfigurationSettingValue("ConnectionString");

Upvotes: 3

Related Questions