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.
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
appSettings. Here’s a sample
This of course works when we run the WebJob instance on our local machine:
Now, change the location of the connection string from
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
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
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
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?
Therefore, finally we’ve got a conclusion that Azure WebJobs look for the connection string of Azure Storage Account in this order:
connectionStringssection of the
- 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.