Lately my focus has been on creating an ASP.NET MVC application that can host 3rd party MVC plugins. Ideally, development of those plugins would follow these rules:
Plugins can be developed in a standard MVC project, and be able to use all the existing infrastructure of the ASP.NET MVC framework.
The complexity of compiling the plugin MVC project and including into a host MVC application should not be severe.
Any changes to the normal development flow of an MVC application would be the bear minimum
After some research I've come up with the following approaches to achieve this, each with their own advantages and disadvantages.
Approach 1 - MVC plugin assembly loaded into main MVC AppDomain
Work Flow
Develop plugin inside a separate MVC project.
Compile the assembly and load it and any dependencies into the host application via PreApplicationStartMethodAttribute, MEF or a basic assembly reference within the host project (if possible).
Map a route to the plugin controllers so that the plugin is treated as an Area within the host.
Place the plugin views into the correct area folder. The layout file will need to be changed so that the layout path points to an area based location, rather than the root of the application (which would have been the case in the development MVC project)
When a request comes in for the plugin, ASP.NET will use the existing areas functionality to route the request to the correct controllers and look in the correct location for the view files.
Advantages
Will work as seamlessly as if the controllers were embedded in the host MVC application assembly.
Simple to include the assemblies into the host App Domain before application start (PreApplicationStartMethodAttribute, project reference) and after application start (MEF)
Disadvantages
No sandboxing - the controllers will have the same trust level as host.
Conclusion
This is the easiest approach, however it is also the least secure. It essentially removes the possibility of allowing untrusted developers to create plugins because those plugins will have the same trust level as the host application (meaning that if the host application can execute methods such as System.IO.File.Delete, so can the plugin)
Approach 2 - MVC plugin assembly running in own AppDomain via MAF
This approach intends to allow the creation of MVC plugins that can be sandboxed into their own AppDomains and used by the host via the System.Addin libraries.
Structure
A route is setup in the host that determines whether the url being processed is targeting a plugin. May have a pattern such as example.com/p/{plugin}/{controller}/{action}/{id}
All routes that have the above pattern are mapped to a host controller that has a module routing action. That action looks at any given route and determines the appropriate plugin to process the request based on the {plugin} segment.
The plugin view is a receiver/sender object that acts as a gateway to the plugin controllers. It has a method called AcceptRequest that receives a RequestContext from the host, and that returns an ActionResult.
The plugin pipeline contains adapters that can serialise RequestContext and ActionResult for transmission across the isolation boundary of the pipeline.
Execution Flow
A route for a plugin is matched and the plugin routing controller is called.
The controller loads the required plugin into it's own AppDomain and calls AcceptRequest, passing through the RequestContext (which is serialised via the pipeline)
AcceptRequest receives the context and determines the appropriate controller to execute based on that request (using a custom controller factory).
Once the controller has finished executing the request, it returns an ActionResult to the receiver object which then passed that ActionResult (also serialised via the pipeline) back to the host AppDomain.
The controller that initially called AcceptRequest can then return the ActionResult to the host MVC execution pipeline, as if it processed the request itself. The plugin AppDomain can then be unloaded if so wished.
Advantages
Plugin will be sandboxed in it's AppDomain, thus any permission set can be used that suits the host.
Disadvantages
Would have to be possible to serialise RequestContext and ActionResult.
Will possibly break other ASP.NET MVC functionality within the isolated AppDomain.
Conclusion
This approach sounds good on paper, but I'm not sure if it's possible/feasible to serialise the RequestContext and ActionResult objects, as well as run an MVC controller in isolation.
Questions
The first approach is fine if the code is being created by trusted developers. I know that I'm not going delete all the host view files or it's web.config file. But ultimately, if you want third party devs to create plugins for your MVC app, you need to be able to sandbox their code.
From all my research, the System.Addin library makes it easy to implement a host/plugin environment when you are using simple API based class libraries. However it seems that it isn't easy to do this when MVC is involved.
Some questions I have are:
Is the second approach I've outlined here feasible?
Is there a better way to do this?
Is there going to be easier ways to achieve MVC plugin isolation in the future?
You're going to end up making separate sites for each plugin. This way you can create reduced-privilege users for each AppPool and a systems administrator can install the "plugin" as a website running under that user.
Any alternatives are going to exhibit the Inner Platform antipattern. Unless you have a lot of time and money to spend developing a plugin-hosting system, you're going to become mired in it and resent it. I speak from experience.
The sites can share AspnetIdentity user repos and you can provide your core objects as a dll that can be referenced. Host your content (script files, css, images) on a CDN so they can be referenced. If you want to share views with your child sites, compile them in as resources:
Including Pre-Compiled Views in an ASP.NET MVC Web Application
Good luck!
IMHO System.AddIn is a a bit overkill for what you are trying to do.
Are you familiar with the System.Security.Permissions namespace? If not you could have a look at the FileIOPermission. Perhaps you could sandbox your extensible system by using (and why not, even extending) the Code Access Security mechanism of .NET.
Related
I'm building an asp.net application that will be deployed on Azure. For the moment, I'm using regular asp.net: I'm building it in VS.
I have a web service that's in an asxm file MyService.asmx with a code behind file MyService.cs that calls a different class library called MyBigClass.cs that does most of the work.
If I want to prepare for a deployment on Azure in a few months and make that web service work in its own web role that I can scale based on usage load, should I put the classes that are in the MyBigClass.cs file into the MyService.cs file? The MyBigClass.cs file contains classes that are used for other parts of the application as well; should I remove these classes and only include the ones used by the web service?
Thanks.
Difficult to give a specific answer, and to be honest - I don't think the answer to this would be Windows-Azure-specific, but rather - this is simply a design best practice question, isn't it?
It comes down to how you will go about maintaining the application, and how you are going to manage versioning, but generally speaking - code that isn't shared does not need to get deployed to both roles, so either move it back with the 'parnet' solution (web app or service), or keep in a separate assembly which you will deploy with only the relevant role.
Code that is shared between the web app and service will exist in a shared assembly which you will deploy into both roles.
So you might end up with the following projects
A web site
An assembly supporting the web site
A Web service Service
An assembly supporting the web service
A shared assembly between the web site and web service
I hope this makes sense
I've made a custom MembershipProvider which uses DependencyResolver from MVC3 to find it's dependencies. It works great for MVC apps, but not for the Web Site Adminstration Tool.
Is there some way that I can hook into the Web Site Adminstration Tool request handling to be able to configure a container before it handles the request?
Membership providers should be interoperable and therefore should work just by plugging into the config file of any provider based app.
Web Site Adminstration tool does exactly this, it runs in it's own web application completely decoupled from your MVC app, and just references your provider.
To make this work you need to ensure all dependencies required for the membership provider are packaged in one assembly and bootstrap your IoC container regardless of the environment it runs in. You can code this in such a way to share MVC initialisation, but not depend on it.
I have one dll containing my entire mvc app running on iis7 server. Should I instead have compiled controllers and business logic into separate dll's? Furthermore, should I install the non controller dll's in a separate server and if so do I configure a new virtual directory to the remote server?
What is the typical practice here? Thanks
I guess that depends on your business needs, but in general I am a fan of modularity. We have our Model shared between multiple sites so it is in its own DLL and the controllers etc. for each site are generally in another (for each site) and additional add-ons in their own as well.
Compiling into one DLL would probably get you a performance increase, but you would be hurt when it comes to upgrading individual modules.
What way makes the most sense? I have a ASP.NET app... and maybe a Silverlight app in the future.. I want both to talk to web services..
At first, I like have the WCF project be by it self for the seperation..
But then I thought.. What is the point since I can just as easily have a 'WEBSERVICES' folder that contains all the .svc files and code in the EXISTING website project. ... Atleast that way.. deploying to a remote host will be a little easier since everything is in one project..
any other considerations ?
Why not have:
your WCF service and data contracts in a Contracts assembly
your WCF service implementations in a Services assembly
reference those two assemblies from your web site or web app
put the *.svc files into a WebServices directory
That way, you have
clean and nicely organized separation of concerns
the deployment files (*.svc) are in your web site / web app as you want
you can still extend / use your WCF code in other ways (e.g. self-hosting) later on without much fuss
Two things to consider:
Security - are your services only going to be used by your application, or do they have the potential to be used anywhere else (after all they are services). If so, you will be granting access to your application in order to grant access to your web services, or at least tweaking the access to that specific folder, which might lead to security breaches.
Deployment - If you do changes on your service that doesn't break the contract, in order to deploy the changes you will have to deploy the whole application.
I would prefer to go with the approach that Marc suggested (e.g. have an assembly for contracts, one for the service implementation) and have the webservice hosted as its own application and reference it from the ASP.NET app. This way, you have proper separation of concerns and can maintain both separately.
I have a component (an assembly built in .net) that i need to access on (almost) every request to two different websites. One website is written in classic asp and the other one in asp.net mvc.
At the moment i reference the assembly in the asp.net solution and call it like i would any .net assembly. On the classic asp website, i call it through a COM wrapper.
This is all good, except now i need this component to actually stay alive and monitor changes to a configuration file. In my asp.net website i could keep a refence in the application scope and i guess i could register it in component services for the asp access.
Is this the best way to do it? Also, this way the component would actually be hosted twice - one instance in the asp.net application scope and one in the component services. I could perhaps instead only have it live in component services, and then instead reference it from asp.net.
I don't know - something smells fishy (and no, it's not me) - am i on the right track or do you see better alternatives?
Do you really need a long running object? You say you need to monitor configuration file changes -- when the config changes do you need to trigger some actions or do you just need to ensure that each incoming request uses the latest copy of the configuration for your component? If it is the latter then standard .NET configuration should work for you without concern for the object lifetime.
In terms of hosting, do you need to use any COM+ services? If not, then I would not use COM+. If you want one central location for your .NET component, why not register it in the GAC?
Ok so i think i found two solutions, both acceptable for this project:
1) Register it in global.asa on the Application_OnStart in the Application object like this Application("Someobject") = Server.CreateObject("Someobject")
2) Host it in component services and handle lifetime there.