Recently, with a new customer engagement, I’ve been building Azure WebJob instances. We are all aware that Azure WebJobs require a connection string to Azure Storage Account. In this post, I’m writing a very interesting fact around the storage account connection string, which I’ve found.
Acknowledgement
In this post, the Azure WebJob instance is written in the following environment:
- .NET Framework 4.6.2
- Azure WebJob SDK 2.0.0
Location of Connection String
There are two different locations that we can possibly store the storage account connection strings in Web.config or App.config – connectionStrings or appSettings. Here’s a sample App.config file:
This of course works when we run the WebJob instance on our local machine:
Now, change the location of the connection string from connectionStrings to appSettings:
As the connection string is declared inside the appSettings section, it throws an error as expected:
Nothing special, right? Let’s deploy this WebJob to an Azure App Service instance.
Combination of Application Settings Blade
Once deployed, the WebJob instance has the configuration settings file:
Let’s rename it to WebJobSample.exe.config.bak so that the WebJob instance can’t load the settings, then run the WebJob.
It throws an error, meaning the configuration file is definitely necessary to run the WebJob instance because the configuration file also contains the binding redirection details. Let’s change the name back to the original one.
Make sure that the connection string belongs to the connectionStrings section.
Also make sure that there is no connection string setup in the Application Settings blade of the Azure App Service instance where the WebJob is deployed.
Now run the WebJob instance again and see how it’s going.
This time, it throws a different error. Actually, the configuration settings contains the connection string of the local storage emulator, which is incorrect. So, if we add connection string into the App Settings blade, it will override it, as we expect Application Settings blade takes precedence.
However, it still throws the same error:
It means the connection string value from the Application Settings blade can’t take over the configuration file. If we omit the connection string from the configuration file, it throws this error:
That is basically the same error when we run the WebJob locally by moving the connection strings to the appSettings section. Therefore, we can come to the conclusion that:
Connection string for Azure Storage Account for WebJob should be stored to the
App.configfile, rather than the Application Settings blade.
However, this doesn’t quite make sense to me as Application Settings blade should take priority. By the way, Azure Functions is basically the extensions of Azure WebJobs and it stores the connection string within the Application Settings blade. Why not applying the same rule to Azure WebJobs? Let’s do it.
Change the configuration settings file to move the connection string from the connectionStrings section to appSettings section.
And make sure that there’s no connection string stored at the Application Settings blade.
Arrrggghhh!! The same error as previously seen! It can’t recognise the appSettings section!
What else option do we still have? Correct. Let’s add the connection string into the Application Settings blade, but this time, to the app settings section, instead of the connection strings section.
Now run the WebJob instance.
YES!! It works! Let’s do the final test. Store connection string to both the connectionStrings section of the App.config file and the app settings section of the Application Settings blade. Which one will take precedence?
Doh! the App.config wins!
Therefore, finally we’ve got a conclusion that Azure WebJobs look for the connection string of Azure Storage Account in this order:
connectionStringssection of theApp.configfile- App Settings section of the Application Settings blade of Azure App Service instance
If you prefer using App.config, perform the XML transformation during the deployment process so that the real connection string is properly injected; otherwise if you prefer using Application Settings blade, also perform the XML transformation to totally remove the connection string from the App.config during the deployment process so that the WebJob instance uses the value from the Application Settings blade.
Hope this will give you guys some indications what to choose for yours.