Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

A plugin framework with ASP.NET MVC3 and embedded Razor views

I'm designing a plugin framework for ASP.NET MVC3 using Razor views, and I'm having an issue getting the embedded views to work correctly.

The plugin framework is designed to have these features:

  • Each plugin has its own models, controllers and views. The views are embedded resources, and the controllers derive from a PluginController class
  • The plugins have dependency references to a shared class library that defines the PluginController base class
  • The "shell" web application that hosts the plugins must not hold references to any plugins at design time, since it does not know at design time which plugins it has.
  • The plugin dll's are dropped in a folder in the shell application, which is not the /bin folder
  • The shell takes care of:
    1. Discovering the plugins (using reflection)
    2. Registering all controllers (I'm using Spring.Net for this)
    3. Creating routes to the controllers
    4. Serving the razor files (cshtml) through a custom VirtualPathProvider

Now everything works fine, except when the embedded views have references to types within the plugin dll. Then I get the infamous error (names left out):

The type or namespace name '[Plugins]' does not exist in the namespace '[MyPluginSolution]' (are you missing an assembly reference?)

The reason for this is that the csc compiler which is invoked runtime to compile the razor views only get the dll references from the bin folder and the GAC.

I've also tried pre-compiling the views using this technique but in the end it gives the same results, since the runtime insists on compiling a wrapper for the pre-compiled razor view.

I could of course drop the plugin dll in the /bin folder, but my question is:

Is there a way to register dlls in a non-bin (and non-GAC) folder, and treat them as "first class citizens" so they can be used by the razor views?

like image 624
lasseschou Avatar asked Jun 24 '11 09:06

lasseschou


2 Answers

Ok, the solution was found using this article.

First I create a class with a PreApplicationStartMethod. This method scans the plugin folder and copies the dlls to the AppDomain.DynamicDirectory.

Then each of these dll's are loaded using BuildManager.AddReferencedAssembly.

And voilà, the strongly-typed Razor views compile beautifully. See the code here:

[assembly: PreApplicationStartMethod(typeof(MySolution.PluginHandler.PluginActivator), "Initialize")]
namespace MySolution.PluginHandler
{
    public class PluginActivator
    {
        private static readonly DirectoryInfo PluginFolderInfo;

        static PluginActivator() {
            PluginFolderInfo = new DirectoryInfo(HostingEnvironment.MapPath("~/plugins"));
        }

        public static void Initialize() {
            CopyPluginDlls(PluginFolderInfo, AppDomain.CurrentDomain.DynamicDirectory);
            LoadPluginAssemblies(AppDomain.CurrentDomain.DynamicDirectory);
        }

        private static void CopyPluginDlls(DirectoryInfo sourceFolder, string destinationFolder)
        {
            foreach (var plug in sourceFolder.GetFiles("*.dll", SearchOption.AllDirectories)) {
                if (!File.Exists(Path.Combine(destinationFolder, plug.Name))) {
                    File.Copy(plug.FullName, Path.Combine(destinationFolder, plug.Name), false);
                }
            }
        }

        private static void LoadPluginAssemblies(string dynamicDirectory)
        {
            foreach (var plug in Directory.GetFiles(dynamicDirectory, "*.dll", SearchOption.AllDirectories)) {
                Assembly assembly = Assembly.Load(AssemblyName.GetAssemblyName(plug));
                BuildManager.AddReferencedAssembly(assembly);
            }
        }
    }
}

I hope this can help other programmers that want to create a clean plugin framework using these new technologies.

like image 146
lasseschou Avatar answered Nov 16 '22 03:11

lasseschou


David Ebbo recently blogged about precompiling Razor views into assemblies. You can view the post here.

You should be able to avoid registering the assemblies directly by dynamically loading the assemblies (I would typically use my IoC container for this) and then calling BuildManager.AddReferencedAssembly for each plugin assembly.

like image 40
Ben Foster Avatar answered Nov 16 '22 03:11

Ben Foster