After Microsoft had introduced the common language runtime (CLR) with .Net technology, all the developers are now able to implement different version of DLL files with the same file name in window platform. Most people says they have finally overcome the DLL hell. But, the question is how does an application really work having different DLL version? Some experienced .Net developers still don't know about the actual underlying process in the .Net platform.
When you develop an application on the .Net platform, you have your managed .Net codes and then compile it into assemblies. In fact, these assemblies are not directly tied or registered to a window process. Instead, the common language runtime (CLR) isolates this managed code by creating separate logical partitions within a process called an application domain. A single process may contain multiple application domains, each of which is hosting distinct pieces of code encapsulated in assemblies. This subdivision of a traditional Windows process offers several benefits provided by the .NET Framework.
The main benefits are as follows:
- Application domains provide the operating system–neutral nature of the .NET platform by abstracting away the concept of an executable or library.
- Application domains can be controlled and (un)loaded, as you want.
- Application domains provide isolation for an application or within a process where multiple application domains live. Application domains within a process are independent of each other and as such remain functional when one fails the other.
A .NET application requires a hosting Windows process. Inside that Windows process, you can host multiple .NET application domains. An application domain is the means for the .NET CLR to isolate the managed code from Windows. The CLR automatically creates one default application domain in each worker process where it is initialized in a process. The default application domain is not unloaded until the process in which it runs shuts down. The CLR controls the shutdown of the default application domain.
After I had worked, as a Technical Lead with MediaCorp Co. Ltd, in the Web Garden environment where Window 2003 Servers run load balancing to host multiple news web sites, I had come across to setting the multiple web applications under IIS 6.0. The coolest thing of IIS 6.0 is you can have application pools that can shared among sites and applications, where each application runs in its own application domain.
An application pool is a separate Windows worker process called W3wp.exe and is started only when it needs to start. In other words, IIS comes with an application activation model that allows IIS to start-up an application pool when it receives a request for a particular application that is bound to that application pool. This enables IIS to host several thousands of applications on one server without keeping several thousand processes running.
When you are hosting multiple web sites under IIS 6.0, you definitely don't want to use DefaultAppPool for each web sites. Because when changing the Web.config file or assemblies in the Bin folder, the application domain will be recycled. It means the application pool and associated processes under that application domain will be reset. Any modification made to one web site will effect to the other web sites if it is sharing the same application pool.
So, be sure to have separate application pool for each web sites and let them run under its own processing domain.
Demo:
I have created the two web sites and two application pools for each web site.
Right click the web site and select the property.
Configure the application pool at web site property window as below
When you develop an application on the .Net platform, you have your managed .Net codes and then compile it into assemblies. In fact, these assemblies are not directly tied or registered to a window process. Instead, the common language runtime (CLR) isolates this managed code by creating separate logical partitions within a process called an application domain. A single process may contain multiple application domains, each of which is hosting distinct pieces of code encapsulated in assemblies. This subdivision of a traditional Windows process offers several benefits provided by the .NET Framework.
The main benefits are as follows:
- Application domains provide the operating system–neutral nature of the .NET platform by abstracting away the concept of an executable or library.
- Application domains can be controlled and (un)loaded, as you want.
- Application domains provide isolation for an application or within a process where multiple application domains live. Application domains within a process are independent of each other and as such remain functional when one fails the other.
A .NET application requires a hosting Windows process. Inside that Windows process, you can host multiple .NET application domains. An application domain is the means for the .NET CLR to isolate the managed code from Windows. The CLR automatically creates one default application domain in each worker process where it is initialized in a process. The default application domain is not unloaded until the process in which it runs shuts down. The CLR controls the shutdown of the default application domain.
After I had worked, as a Technical Lead with MediaCorp Co. Ltd, in the Web Garden environment where Window 2003 Servers run load balancing to host multiple news web sites, I had come across to setting the multiple web applications under IIS 6.0. The coolest thing of IIS 6.0 is you can have application pools that can shared among sites and applications, where each application runs in its own application domain.
An application pool is a separate Windows worker process called W3wp.exe and is started only when it needs to start. In other words, IIS comes with an application activation model that allows IIS to start-up an application pool when it receives a request for a particular application that is bound to that application pool. This enables IIS to host several thousands of applications on one server without keeping several thousand processes running.
When you are hosting multiple web sites under IIS 6.0, you definitely don't want to use DefaultAppPool for each web sites. Because when changing the Web.config file or assemblies in the Bin folder, the application domain will be recycled. It means the application pool and associated processes under that application domain will be reset. Any modification made to one web site will effect to the other web sites if it is sharing the same application pool.
So, be sure to have separate application pool for each web sites and let them run under its own processing domain.
Demo:
I have created the two web sites and two application pools for each web site.
Right click the web site and select the property.
Configure the application pool at web site property window as below
1 comment:
Hello there, You have done a fantastic job.
I will definitely digg it and personally recommend to my friends.
I'm sure they'll be benefited from this web site.
Check out my web page - teenpornpost
Post a Comment