Can I access web.config from my Azure web role entry point?

Question

I have an Azure web role and I want to store some settings in web.config under <appSettings> tag. Yes, I'm aware of service configuration files, yet I have reasons to prefer web.config.

When I execute (from here ):

System.Configuration.Configuration rootWebConfig =
    System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration(null);
if (rootWebConfig1.AppSettings.Settings.Count > 0) {
}

settings count is always zero although I've added a key-value pair under <appSettings> .

What am I doing wrong? Is it possible to read settings from web.config from inside web role entry point?

Answer 1

The reason for this is that Microsoft has introduced Full IIS capability since Azure SDK 1.3. A side effect of this is that the RoleEntryPoint gets walled off from the rest of the web application.

The following excerpt from Microsofts blog post describes what you're seeing.

...with full IIS, the RoleEntryPoint runs under WaIISHost.exe , while the web site runs under a normal IIS w3wp.exe process.

...so it expects its configuration to be in a file called WaIISHost.exe.config . Therefore, if you create a file with this name in the your web project and set the "Copy to Output Directory" property to "Copy Always" you'll find that the RoleEntryPoint can read this happily.

Apart from the solution mentioned, an option might be to try to use Hosted Web Core (HWC) mode instead of full IIS mode.

---

Update - changes introduced in Azure SDK 1.8

• Azure SDK 1.3 -1.7 will look in WaIISHost.exe.config

• Azure SDK 1.8+ will look in the WebRoleProjectName.dll.config .

With the newest change to the SDK, you should be able to place an app.config in your project and your role entry point should then have access to it.

Answer 2

Where is your web.config , and where is the code you're executing?

If it's in the OnStart() method of a RoleEntryPoint subclass, you'll be seeing the entries in a web.config in the root of the same project - typically, this is the Web deploy project itself, not your Web site. This allows Azure to support multiple Web sites under one Web deployment role.