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

Well, this was one of those bugs that took a while to figure out and of course the solution was pretty simple.

It turns out that this:

[EnableCors(origins: “http://MyWebsite.com”, headers: “*”, methods: “*”)]

is not the same as this:

[EnableCors(origins:”http://mywebsite.com”, headers: “*”, methods: “*”)]

I have some JavaScript that calls an ASP.NET web API method on another domain. Let’s pretend that the API is on myservice.com and the website is on mywebsite.com. As you can guess, I was having some issues and getting an error similar to this:

Failed to load http://myservice.com/api/SomeController/SomeMethod: No ‘Access-Control-Allow-Origin’ header is present on the requested resource. Origin ‘http://mywebsite.com is therefore not allowed access.

I tried a lot of things to figure out what was going on. I knew that I had the CORS attribute on my controller and I had config.EnableCors(); set up in my Web API configuration. This is one of the first times I’m using CORS on Azure so I thought it had something to do with Azure, but that was not correct. After trying many, many hacks with no success and staring at my EnableCors Attribute, I had the “crazy” idea to change “http://MyWebsite.com” to ”http://mywebsite.com” and of course, everything worked fine. From now on, I’ll use all lowercase!

I hope you won’t get stuck wasting as much time as I did trying to figure this one out!