Azure web app globalization - azure

I develop a web app locallly using US globalization. So the web.config looks like:
<system.web>
...
<globalization culture="en-US" uiCulture="en-US" />
<!--<globalization culture="no" uiCulture="no" />-->
...
</system.web>
I have two separate Azure web apps to which I deploy the app. I set the connection strings and the app settings directly in the azure management portal which I find ok, since I had to do this just once. The problem is that there is no option to set the globalization element in the management portal and the deploy always rewrites it back to US (the wanted value is no - norwegian, not that it matters, it simply should be different than US).
Is there a way to handle it either using the azure portal (a better solution imho) or using a deploy script? If so, then how?

You could implement this using a custom deployment script: http://blog.amitapple.com/post/38417491924/azurewebsitecustomdeploymentpart1/#.Vh5_QXmFMaU
One way to make the custom deployment script do what you want would be to have an app setting you define in your Norwegian site (via the portal) set to "Location = 'Norway'". Then in your custom deployment script you check to see if the app setting is set to Norway (it'll be available as an environment variable).
If it is, then you override the web config with the Norway globalization setting. There are multiple ways you could implement this part.
If the location is not defined or is set to US, then you leave it with the default US settings.

Related

Configure machineKey from ARM templates for asp.net web api project

I need to use the same machine key for different asp.net web api applications (deployed on the different servers on azure).
I can set it via web.config (machine key) sections.
But I would like to set it via ARM templates (azure).
Automation script in azure has machineKey property at the Microsoft.Web/sites/config resource (but it is null).
Site template reference doesn't have machineKey property https://learn.microsoft.com/en-us/azure/templates/microsoft.web/sites
So I assume that I can't set it via arm (I tried without success, so for now I take it from app settings How to set machineKey on Azure Website)
Does anyone know how to set machineKey section from azure templates?
Based on my knowledge, it is not possible.
Azure template is used to give web app settings. You could use template to set Web App's name, node version, javaContainer,etc.. However, given the machine key is not an app setting - it's under the system.web section of the web.config.
I also check Web App template's resource, it does not provides such configuration.

What causes azure websites to ignore settings from web.config?

My web.config contains multiple entries in "appSettings" (e.g.: twilio account key). One of these is for the asp.net chart control. It's the configuration part that states where the images the control generates are to be stored.
All of these settings work on my development machine. That is, i can connect to twilio and the chart control stores image in memory (as it should, according to the settings).
When i publish the site to my azure website (using vs), all of the settings work, apart from the chart control one. The chart control behaves as if the setting isn't even there. (it defaults to c:\TempImageFiles for storage).
I looked into the published version of the web.config and the setting is there. Only, it's beeing ignored.
My next attempt was to add that setting using the portal. (It's possible to add appSettings for a web app using the portal). I copied the exact same setting from web.config into the portal settings. This worked, so there is nothing wrong with what's in the settings.
So my question is: Why are some (at least this one) settings from web.config ignored when the app runs inside an azure web app?
You might have an app setting defined in the Web App's configuration with an identical name that overrides the web.config setting. This is typically done to have production settings stored in Azure instead of Web.config.
You can confirm if this is the case by opening your Web App's blade in the new portal, and checking the Application Settings tab there.
azure websites / azure web app service are typical web applications running on top of azure PaaS infrastructure. So whatever storage allocated to the service is accessible from the app. But it cannot be the typical C: or D: where in a regular server the app may have complete access. Mostly the C: space is allocated for IIS hosting. D:\local is something you can utilize as the app will have complete read and write access.
Please refer azure web app service sandbox details here.
If you are accessing the path via code try using Server.MapPath property to get access to the path. options like Path.GetTempPath() will not work.
One point to note is, any local storage in azure PaaS services is to be treated like a temporary storage. Whenever the site, service or role recycles the storage will be gone a fresh storage will be assigned.

How to check if code is running on Azure Websites

I knew that we can use RoleEnvironment.IsAvailable to check if code is running in Web/Worker Role. How about Azure Websites?
I tried the above RoleEnvironment code but it always returns false. I need to run some configuration code in Application_Start so I cannot depend on the request stuff.
Any help is appreciated.
This is actually very easy simply check for existence of this environment variable: WEBSITE_SITE_NAME.
!String.IsNullOrEmpty(Environment.GetEnvironmentVariable("WEBSITE_SITE_NAME"))
The content for this will be the name of your site.
To see more environment variable that you have under your site go to the following link: https://{sitename}.scm.azurewebsites.net/Env
You cannot (easily).
With azure Web Sites, your site runs in an IIS. RoleEnvironment will always be false, because it is not initialized there. Look at Azure Web Sites more like a regular hosting. Can you tell if your website is running in XYZ Hosting, or in your own IIS?
One thing that you could consider is the Application Settings in your web.config (yes, the appSettings section) and have some setting indicating whether you run on WebSites or not. Read the full article here about App Settings in Azure WebSites to understand what I mean. In short: if you set a setting value via the portal, it will take precedence over what is in web.config. You can even just set it in the Portal, not having it in your web.config.

Changing/retrieving configuration settings on role start (Azure)

I'm trying to make a service to more easily configure configuration values on Azure applications. Right now, if I want to change a setting that it the same over 7 different environments, I have to change it in 7 different .cscfg files.
My thought is I can create a webservice, that the application will query for its configuration values. The webservice will look in a storage place, like Azure Tables, and return the correct configuration values.
I've been able to integrate this into a deployment script pretty easily (package the app, get the settings, change the cscfg file, deploy). The problem with that is every time you want to change a setting, you have to redeploy.
Finally the question - Is there a way I can retrieve the configuration settings after the application starts, on role start? It would of course need a base set of settings for the app to start. Retrieving the settings from the web service on application start would be good. Any way that I don't have to redeploy the application and that it will retrieve them automatically will work.
Thanks in advance!
Just use the .cscfg for the minimum set (common to all environment) of configurable settings. The use your web services for rest of the configurations. And don't modify your .cscfg. Just have a settings provider that retrieves settings from web service (via polling or message signalling - pub/sub model). And have a reinitialize settings procedure in place for this settings provider and all the services/components that rely on configurable settings.

Moving Facebook C# SDK configuration settings to Azure ServiceConfiguration.cscfg

I'm using Facebook C# SDK for an ASP.NET MVC Facebook Canvas application that I'm hosting in Windows Azure.
I currently have the Facebook C# SDK specific configuration settings (appSecret, appId, etc.) in web.config, but I would like to move them to the service configuration file instead so that I can alter the settings when moving from Staging to Production in Azure.
(How) can this be done? Right now I'm using the CanvasAuthorize attribute that automatically reads from web.config.
[CanvasAuthorize(Permissions = FacebookPermissions.ReadStreamPermission)]
public ActionResult Login()
{
return RedirectToAction("Authenticate"); // Logged in, proceed with authentication
}
By default, Facebook C# SDK looks up at the configuration sections in web.config.
You will need to override the default Facebook application using code similar to this.
FacebookApplication.SetApplication(new DefaultFacebookApplication { AppId = "..", AppSecret = ".." });
The best place to set the application is at Application_Start.
You can checkout the sample at https://gist.github.com/820881
This means you are not tied to web.config. You can use database, azure service configuration or anything depending on your logic from where the settings can be retrieved.
I'm not sure about the reasoning of putting application specific configuration information in the Azure ServiceConfiguration.csfg file. Furthermore, I would say that this will be a problem rather than helpful to switch VIP's in the Azure control panel.
They way I do it is to have multiple web deployment configurations in my (ASP.NET MVC canvas page) Visual Studio project. One for Staging and one for Production.
I use the web.config transformation functionality in the Web Deployment to have different web.config settings for Staging/Production.
It works very well and smoothly, just right-click on the project, select Deploy and choose if you want to deploy to staging or production. You can also handle a specific testing AppID for Staging this way.
EDIT: I haven't looked in the source code for the Facebook C# SDK, but I would guess that the web.config read methods are, in fact, hard coded to use the web.config. That would also be a reason to keep it there.

Resources