AppDomains in IIS/ASP.NET
Given an ASP.NET WebForms portal being hosted within IIS and the use of isolated modules written in ASP.NET MVC3, what is the appropriate API to use in executing the modules during runtime?
- AppDomain API
- ApplicationHost API
- AppManagerAppDomainFactory class
- Not appropriate, use IIS built-in isolation mechanisms and find another way to host MVC3-generated content in a portal's MasterPage structure
- ??
Background
We have a legacy custom portal with a number of applications hosted written using C#/WebForms. Currently, the portal and all applications live in a single project; they are all deployed at the same time. I would like to separate the applications from the portal, implement them as modules to the portal, and to isolate the execution of each module during run-time. We would like to port/rewrite each application in ASP.NET MVC 3.
As we port each applicati开发者_运维知识库on, my initial thinking is have the portal handle each request, load the app/module in an AppDomain, forward requests to the module, obtain the generated html, and place it in the portal MasterPage's ContentPlaceHolder. Before I go down this path, I thought it prudent to get some StackOverflow validation on the basics.
Isolating plugins/modules into a separate AppDomain is useful when the plugins are provided by a 3rd party and you want to apply strict security restrictions on the plugin. When you've written the plugins yourself, this level of isolation isn't necessary and is counter productive.
You can achieve the necessary level of isolation through appropriate project references. Define a separate project which contains the interfaces for the plugin API and any associated value objects. Have your plugins reference this project and implement the appropriate API's. Then your host application should reference the plugins only through this API. That gives you code separation and easier maintenance without dealing with managing multiple AppDomains.
精彩评论