In the last post we saw how to access and modify web.config file associated with Azure Web Role and application configuration file associated with Azure Worker Role after deployment.
In this post we will see the role of application configuration file in a Web Role.
In any Windows Azure Web Role project there are two categories of code, which runs under different process once deployed to the Web Role virtual machine.
Category-1:
The website related code runs under a normal IIS 'w3wp.exe' process.
Category-2:
All 'RoleEntryPoint' related code (i.e. code in OnStart, OnRun, Stop methods) will be running under the process 'WaIISHost.exe'.
The Visual Studio Web Role project compiles into a single DLL (e.g. NorthWindWebRole.DLL), but parts of code runs under two different processes as described above.
Following screenshot shows these two processes in Web Role virtual machine, we can see both are loading the Web Role DLL.
When category-1 code [ running under IIS (w3wp.exe) ] try to read configuration values using 'ConfigurationManager', it loads web.config and looks for the given setting. For example Entity Framework context class uses ConfigurationManager to read the default DB connection string.
When category-2 code [ running under 'WaIISHost.exe'] try to read configuration values using 'ConfigurationManager', it will read from an application configuration file with name '<assembly-name>.dll.config. For example, if the name of Web Role DLL is NorthWindWebRole.DLL, then the file that 'ConfigurationManager' try to load and read from will be 'NorthWindWebRole.dll.config'.
When we create Web Role project using Visual Studio, a web.config file will be added to the project by VS , but not application configuration file.
If any code in your 'RoleEntryPoint' methods uses directly or indirectly 'ConfigurationManager' then you need to make sure you are explicitly adding an application configuration file with name same as the compiled DLL (with .config extension) and define required settings in this file. Don't forget to set 'Build Action' property for this file to 'Content' and 'Copy To Output Directory' property to 'Copy Always'.
You may ask why we need to add such explicit application configuration file when we have an option to define and declare settings using Azure service definition and service configuration file, which can be read using RoleEnvironment.GetConfigurationSettingValue. One of the situation where we have hard dependency in application configuration file is when we use a third party assembly in our 'RoleEntryPoint' methods which internally uses .NET 'ConfigurationManager' to read its own settings.
For example, when we enable 'Windows Azure In-Role caching' in a Web Role project we can see following settings gets added to web.config file.
When we create an instance of 'DataCacheFactory' (to access cache) in the web application (i.e. from Category-1 code), it internally uses 'ConfigurationManager' to read the above settings from web.config.
Now consider the scenario where we want to access the cache from 'RoleEntryPoint' methods. Creating an instance of 'DataCacheFactory' from RoleEntryPoint' methods (i.e. from Category-2 code) will fail since 'DataCacheFactory' constructor try to read required settings using 'ConfigurationManager' class that try to load application configuration file which does not exits. This can be fixed by adding application configuration file as explained above.
In this post we will see the role of application configuration file in a Web Role.
In any Windows Azure Web Role project there are two categories of code, which runs under different process once deployed to the Web Role virtual machine.
Category-1:
The website related code runs under a normal IIS 'w3wp.exe' process.
Category-2:
All 'RoleEntryPoint' related code (i.e. code in OnStart, OnRun, Stop methods) will be running under the process 'WaIISHost.exe'.
The Visual Studio Web Role project compiles into a single DLL (e.g. NorthWindWebRole.DLL), but parts of code runs under two different processes as described above.
Following screenshot shows these two processes in Web Role virtual machine, we can see both are loading the Web Role DLL.
When category-1 code [ running under IIS (w3wp.exe) ] try to read configuration values using 'ConfigurationManager', it loads web.config and looks for the given setting. For example Entity Framework context class uses ConfigurationManager to read the default DB connection string.
When category-2 code [ running under 'WaIISHost.exe'] try to read configuration values using 'ConfigurationManager', it will read from an application configuration file with name '<assembly-name>.dll.config. For example, if the name of Web Role DLL is NorthWindWebRole.DLL, then the file that 'ConfigurationManager' try to load and read from will be 'NorthWindWebRole.dll.config'.
When we create Web Role project using Visual Studio, a web.config file will be added to the project by VS , but not application configuration file.
If any code in your 'RoleEntryPoint' methods uses directly or indirectly 'ConfigurationManager' then you need to make sure you are explicitly adding an application configuration file with name same as the compiled DLL (with .config extension) and define required settings in this file. Don't forget to set 'Build Action' property for this file to 'Content' and 'Copy To Output Directory' property to 'Copy Always'.
You may ask why we need to add such explicit application configuration file when we have an option to define and declare settings using Azure service definition and service configuration file, which can be read using RoleEnvironment.GetConfigurationSettingValue. One of the situation where we have hard dependency in application configuration file is when we use a third party assembly in our 'RoleEntryPoint' methods which internally uses .NET 'ConfigurationManager' to read its own settings.
For example, when we enable 'Windows Azure In-Role caching' in a Web Role project we can see following settings gets added to web.config file.
When we create an instance of 'DataCacheFactory' (to access cache) in the web application (i.e. from Category-1 code), it internally uses 'ConfigurationManager' to read the above settings from web.config.
Now consider the scenario where we want to access the cache from 'RoleEntryPoint' methods. Creating an instance of 'DataCacheFactory' from RoleEntryPoint' methods (i.e. from Category-2 code) will fail since 'DataCacheFactory' constructor try to read required settings using 'ConfigurationManager' class that try to load application configuration file which does not exits. This can be fixed by adding application configuration file as explained above.
No comments:
Post a Comment