Compartilhar via

Azure Development Tips for Debugging and Connection Strings

  • Artigo

I just wanted to pass on a couple of tips for Azure development that I've recently found to be helpful.

The first is around connection strings.  When you use a connection string, you typically store it in the project properties.  The labs usually demonstrate reading the connection strings with something like this:

// read storage account configuration settings
CloudStorageAccount.SetConfigurationSettingPublisher((configName, configSetter) =>
{
 configSetter(RoleEnvironment.GetConfigurationSettingValue(configName));
});

They then suggest that when you are testing and running in the local dev fabric that you configure the setting to be "UseDevelopmentStorage=true", and then when you're ready to move to production you go back in to your project settings and change it to point to your Azure storage.  In practice, I found it much simpler just to store your Azure storage details in the connection string all the time, but in your code use this rather than the sample above:

CloudStorageAccount.SetConfigurationSettingPublisher((configName, configSetter) =>
{
 string connectionString;

 if (RoleEnvironment.IsAvailable)
   connectionString = RoleEnvironment.GetConfigurationSettingValue(configName);
 else
  connectionString = "UseDevelopmentStorage=true";

 configSetter(connectionString);
});

The second tip is related to debugging.  It's sort of second nature to just hit F5 and start running.  Because you have multiple processes going on with the local dev fabric I've found it's easier to start up your solution by going to the Debug menu and choosing Start Without Debugging.  That will compile your app, deploy it to the local dev fabric and start it up.  Then you can attach to the w3wp.exe process for your ASPX or WCF application, set your breakpoints, and hit it using something like the WCF Test Client that comes with Visual Studio 2010.

Comments

  • Anonymous
    January 01, 2003
    The comment has been removed
  • Anonymous
    February 28, 2015
    This is part 2 of a 5 part series on the CASI (Claims, Azure and SharePoint Integration) Kit.
    ·