WebRole entry point and config file…

When you write a web role requiring application specific configuration (like assembly binding), you may have a hard time trying to figure out which app configuration file should be used and how to get it deployed and used in your role. This issue has been hit by many developers and raised in many blogs & forums:

• https://www.s-innovations.net/Blog/2014/01/23/WaIISHostexeconfig-vs-appconfig-for-Azure-Cloud-Service-role-config

• https://stackoverflow.com/questions/14072317/waiishost-exe-config-vs-app-config-for-worker-role-config

• https://stackoverflow.com/questions/19758937/what-is-the-name-of-the-web-role-config-file-with-sdk-2-2

• https://social.msdn.microsoft.com/Forums/windowsazure/en-US/0a11dce1-e8bf-4669-94fc-8ba985a860b0/windows-azure-sdk-18-and-web-role-configuration-files

  …

The key point to remember is that full IIS web role entry point (code implemented in WebRole.cs) is loaded into the WaIISHost.exe process and not w3wp.exe. Therefore, you can't expect settings defined in web.config to be used in you role entry point.

There are 2 solutions to this issue :

• One option consists to use WaIISHost.exe.config – see
  Reading config files from RoleEntryPoint and your web site
• The other option consists to create a <webrole name>.dll.config file

These are the steps you can use for the second option in Visual Studio :

1. In solution explorer, click on your web role project (WebRole1 in this example) and select Add -> Web Configuration File

2. Name the configuration file <webrole name>.dll.config (in this example, WebRole1.dll.config)

3. Setup the config file content depending on your needs (assembly redirection…etc)

4. Right click on the config file, select "Properties" and set "Copy to output directory" to "Copy always" :

   

5. Build the Azure package and deploy it to Azure

Alternatively to the above approach, you can use a "Before build" action to copy the web.config to bin\<webrole name>..dll.config :

copy $(ProjectDir)Web.config $(TargetDir)$(TargetFileName).config

Using the context menu, you'll then need to include in the project the bin\<webrole name>.dll.config. With this approach, you'll be able to set all you settings in a single file (web.config).

With the above steps, you should end up with the web role config file copied to the /bin directory of your webrole (E:\sitesroot\0\bin). In case, it isn't, you may also check that the configuration file is present in the package created (open the cspkg file as a zip file and confirm that the config file is present under the path : WindowsAzure1.cspkg\WebRole1_<ID>.cssx\approot\bin\).

I would like to thank Mr Claus Nielsen for having reported the issue and spending time to troubleshoot it with Microsoft Support…

Emmanuel Boersma

Comments

• Anonymous
  June 04, 2015
  A note for anybody trying to use the pre-build command above, ensure the commands are encased in quotes if your project directory has spaces, else the command will not work. copy "$(ProjectDir)Web.config" "$(TargetDir)$(TargetFileName).config"

• Anonymous
  November 19, 2015
  Something seems circular here. If you make a change in Web.config, does the dll.config get updated in the build or does it take a second build?

• Anonymous
  November 19, 2015
  do you mean that the .dll.config file in the project should be a link? so before build, copy over web.config?

• Anonymous
  December 19, 2016
  You can use this solution for local development, but not for fixing the publish issue. In order the publish packager to take the file into consideration and add it to the package, the file must be in the bin folder and added as project file. But if you do this, then the copy to output will not work, nor the transformation of .config file. If you don't do the copy step & transformation, the file will be used for debug setting which can cause issues with cloud settings used for local debug run.You are left with maintaining the outputfilename.config manually, after every binding assembly change. Adding it to the bin folder as project file before publish, and removing it after.