Detailed example of developing plug-in system using MVC engine in ASP.NET

This article mainly introduces in detail the relevant information on using the ASP.NET MVC engine to develop plug-in systems. It has certain reference value. Interested friends can refer to

1. Preface

The plug-in system in my mind should be like Nop (more awesome ones like Orchard, OSGI.NET ), each plug-in module is not just a bunch of dll that implements a certain business interface, and is then called using reflection or IOC technology, but a complete mvc small application, I can control the installation and disabling of the plug-in in the background. The directory structure is as follows:

Place it in the root directory of the site after generation In the Plugins folder, each plug-in has a subfolder

Plugins/Sms.AliYun/

Plugins/Sms.ManDao/

I am a lazy person with obsessive-compulsive disorder, and I don’t want to copy the generated dll file to the bin directory.

2. Problems to be solved

1.asp.net engine will only load the dll in the "bin" folder by default, and the plug-in file we want It is scattered in various subdirectories under the Plugins directory.

2.How to handle when model is used in view? By default RazorViewEngine uses BuildManager to compile the view into a dynamic assembly, and then uses Activator.CreateInstance to instantiate the newly compiled object, while when using the plug-in dll, the current AppDomainDon't know how to resolve this view that references the model since it doesn't exist in "bin" or the GAC. Even worse, you won't get any error message telling you why it's not working, or what the problem is. Instead, it will tell you that the file cannot be found in the View directory.

3. A plug-in is running under the site. If you directly overwrite the plug-in's dll, you will be told that the current dll is in use and cannot be overwritten.

4. How to load the view file if it is not placed in the View directory of the site.

三.Net 4.0 makes all this possible

A new feature of Net4.0 is the ability to execute code before the application is initialized (PreApplicationStartMethodAttribute), this The feature allows the application to do some work before Application_Star. For example, we can tell where the dll of our mvc plug-in system is placed before the application starts, and do preloading processing, etc. Regarding several new features of .net, there is a blog written by Waiguo Keren to introduce them, please click here. , Regarding PreApplicationStartMethodAttribute, some bloggers have already written about it, please click here. Abp's startup module should also be implemented using the feature principle of PreApplicationStartMethodAttribute. I haven't seen whether this is the case.

4. Solution

1. Modify the main site web.config directory so that in addition to loading files in the bin directory during runtime, you can also load files from other Directory loading

 <runtime>
 <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
  <probing privatePath="Plugins/temp/" />
 </assemblyBinding>
 </runtime>

2. Develop a simple plug-in management class. The function of this class is to copy the dlls in each subdirectory of Plugins to the folder specified in step 1 before Application_Start. In order to make the demo as simple as possible, there is no detection of duplicate DLLs (for example, the EF assembly is referenced in the plug-in, and the main site also references it. There is already an EF DLL in the site's bin directory, so there is no need to add the EF assembly in the plug-in. dll is copied to the dynamic assembly directory set above)

using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Reflection;
using System.Text;
using System.Threading.Tasks;
using System.Web;
using System.Web.Compilation;
using System.Web.Hosting;
[assembly: PreApplicationStartMethod(typeof(Plugins.Core.PreApplicationInit), "Initialize")]
namespace Plugins.Core
{
 public class PreApplicationInit
 {

  static PreApplicationInit()
  {
   PluginFolder = new DirectoryInfo(HostingEnvironment.MapPath("~/plugins"));
   ShadowCopyFolder = new DirectoryInfo(HostingEnvironment.MapPath("~/plugins/temp"));
  }

  /// <summary>
  /// 插件所在目录信息
  /// </summary>
  private static readonly DirectoryInfo PluginFolder;

  /// <summary>
  /// 程序应行时指定的dll目录
  /// </summary>
  private static readonly DirectoryInfo ShadowCopyFolder;

  public static void Initialize()
  {
   Directory.CreateDirectory(ShadowCopyFolder.FullName);
   //清空插件dll运行目录中的文件
   foreach (var f in ShadowCopyFolder.GetFiles("*.dll", SearchOption.AllDirectories))
   {
    f.Delete();
   }
   foreach (var plug in PluginFolder.GetFiles("*.dll", SearchOption.AllDirectories).Where(i=>i.Directory.Parent.Name== "plugins"))
   {
    File.Copy(plug.FullName, Path.Combine(ShadowCopyFolder.FullName, plug.Name), true);
   }
   foreach (var a in
    ShadowCopyFolder
    .GetFiles("*.dll", SearchOption.AllDirectories)
    .Select(x => AssemblyName.GetAssemblyName(x.FullName))
    .Select(x => Assembly.Load(x.FullName)))
   {
    BuildManager.AddReferencedAssembly(a);
   }

  }
 }
}

3. How to let the View engine find our view? The answer is to rewrite RazorViewEngine. I adopted the approach of convention over configuration (assuming that our plug-in project namespace is Plugins.Apps.Sms, then the default controller namespace For Plugins.Apps.Sms.Controllers, the folder after the plug-in is generated must be /Plugins/Plugins.Apps.Sms/). By analyzing the current controller, you can know the location of the View directory of the current plug-in

using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;
using System.Web;
using System.Web.Mvc;
using System.Web.WebPages.Razor;

namespace Plugins.Web
{
 public class CustomerViewEngine : RazorViewEngine
 {

  /// <summary>
  /// 定义视图页所在地址。
  /// </summary>
  private string[] _viewLocationFormats = new[]
  {
   "~/Views/Parts/{0}.cshtml",
   "~/Plugins/{pluginFolder}/Views/{1}/{0}.cshtml",
   "~/Plugins/{pluginFolder}/Views/Shared/{0}.cshtml",
   "~/Views/{1}/{0}.cshtml",
   "~/Views/Shared/{0}.cshtml",
  };
  public override ViewEngineResult FindView(ControllerContext controllerContext, string viewName, string masterName, bool useCache)
  {
   string ns = controllerContext.Controller.GetType().Namespace;
   string controller = controllerContext.Controller.GetType().Name.Replace("Controller", "");
   //说明是插件中的控制器，View目录需要单独处理
   if (ns.ToLower().Contains("plugins"))
   {
    var pluginsFolder = ns.ToLower().Replace(".controllers", "");
    ViewLocationFormats = ReplacePlaceholder(pluginsFolder);
   }
   return base.FindView(controllerContext, viewName, masterName, useCache);
  }
  /// <summary>
  /// 替换pluginFolder占位符
  /// </summary>
  /// <param name="folderName"></param>
  private string[] ReplacePlaceholder(string folderName)
  {
   string[] tempArray = new string[_viewLocationFormats.Length];
   if (_viewLocationFormats != null)
   {
    for (int i = 0; i < _viewLocationFormats.Length; i++)
    {
     tempArray[i] = _viewLocationFormats[i].Replace("{pluginFolder}", folderName);
    }
   }
   return tempArray;
  }
 }
}

Then Specify the Razor engine as our rewritten

4. Start making a plug-in directory, which is not much different from the MVC project we usually build. It just needs some settings when publishing.

. The generation path must be written according to the agreement in Article 3, otherwise the view file will not be found

.web.config and web.config in the View directory The .cshtml file should be copied to the build directory (right-click on the file)

3. Set the build in the referenced project Attribute , if it already exists under the main program, set "Copy to output directory" to None, otherwise an error will occur when copying to the dynamic bin directory. You can modify the class in step 2 and add file comparison. Functions that are not in the bin directory are copied to the dynamic bin directory.

4. The generated directory structure is as follows:

5. Run it, everything is normal, the plug-in The controller works normally, and there is no problem if Model is referenced in the view

At this point, the core part of a plug-in system is completed, you can continue Expand and add plug-in discovery, installation, and uninstall functions. These are all child's play compared to the core functions. I will publish an article on the plug-in system based on the Abp framework in the future. If you are interested, prepare a small bench and buy melon seeds and peanuts:)

The above is the detailed content of Detailed example of developing plug-in system using MVC engine in ASP.NET. For more information, please follow other related articles on the PHP Chinese website!