I wanted to point out one difference between ConfigurationManager and WebConfigurationManager. I know there are other differences but here’s an issue I ran into recently.

I’ve been working on some Bot Framework stuff (really cool and fun, by the way). The Bot uses a QnAMakerService and QnAMakerDialog which worked great when I ran the Bot locally (debugging in Visual Studio) but it didn’t work when I deployed it to Azure. I knew that a lot of features of my bot were working but when it needed to use the QnA features it was just bombing out. A coworker helping out said he fixed my problem by putting settings in for the QnaSubscriptionKey and QnaKnowledgebaseId via the Azure Portal (navigate to your App Service, then Settings > Application Settings)

image

 

Yeah, I knew those were needed of course, but I had already added them. The settings were in my web.config file:

image

I was glad the Bot was working and I had a major clue to my issue. I wasn’t going to let it end there. Why weren’t the web.config settings being used? I took a close look at my code:

[Serializable]
public class QnADialog : QnAMakerDialog
{
public QnADialog() : base(new QnAMakerService(
new QnAMakerAttribute(
ConfigurationManager.AppSettings[“QnaSubscriptionKey“],
ConfigurationManager.AppSettings[“QnaKnowledgebaseId“],
Sorry, I couldn’t find an answer for that“,
0.5)))
{
}
}

The code seemed pretty straightforward. As a matter of fact, I recalled copying it from a sample on the web! Then I noticed that the code was using “ConfigurationManager” which was not the normal thing for me. I usually create web applications and I therefor use “WebConfigurationManager” to read from web.config files. And since my bot runs as an App Service in Azure, it IS a web application. I proceeded to make the major refactor of adding the text “Web” to the word “ConfigurationManager”. I then removed the Application Settings from the Azure Portal, leaving the values I had previously entered into the web.config file. And it worked perfectly.

As developers we have a variety of options to access configuration data and that data can be stored in several places. In addition to the two previously mentioned, there is also the CloudConfigurationManager class. My understanding is that this would have worked similarly to WebConfigurationManager. And, in fact, good old plain ConfigurationManager would have worked fine for this Azure App Service if I used the Portal to set my app settings instead of the web.config file. So, choose carefully and get to know the differences between the ConfigurationManager classes

Leave a reply

required

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>