nopcommerce 4.1 core 插件 相关1

时间:2023-03-09 09:10:07
nopcommerce 4.1 core  插件 相关1

nop中 插件机制是比较值得学习的:

Nop 插件学习:

1、 项目里面的生成必须是采用 直接编辑项目文件,参考nop原本的项目文件

nopcommerce 4.1 core  插件 相关1

动态加载插件的方法-mvc3 参考:

using System.Linq;

using System.Web;

using System.IO;

using System.Web.Hosting;

using System.Web.Compilation;

using System.Reflection;

[assembly: PreApplicationStartMethod(typeof(PluginFramework.Plugins.PreApplicationInit), "Initialize")]

namespace PluginFramework.Plugins

{

public class PreApplicationInit

{

static PreApplicationInit()

{

PluginFolder = new DirectoryInfo(HostingEnvironment.MapPath("~/plugins"));

ShadowCopyFolder = new DirectoryInfo(HostingEnvironment.MapPath("~/plugins/temp"));

}

/// <summary>

/// The source plugin folder from which to shadow copy from

/// </summary>

/// <remarks>

/// This folder can contain sub folderst to organize plugin types

/// </remarks>

private static readonly DirectoryInfo PluginFolder;

/// <summary>

/// The folder to shadow copy the plugin DLLs to use for running the app

/// </summary>

private static readonly DirectoryInfo ShadowCopyFolder;

public static void Initialize()

{

Directory.CreateDirectory(ShadowCopyFolder.FullName);

//clear out plugins)

foreach (var f in ShadowCopyFolder.GetFiles("*.dll", SearchOption.AllDirectories))

{

f.Delete();

}

//shadow copy files

foreach (var plug in PluginFolder.GetFiles("*.dll", SearchOption.AllDirectories))

{

var di = Directory.CreateDirectory(Path.Combine(ShadowCopyFolder.FullName, plug.Directory.Name));

// NOTE: You cannot rename the plugin DLL to a different name, it will fail because the assembly name is part if it's manifest

// (a reference to how assemblies are loaded: http://msdn.microsoft.com/en-us/library/yx7xezcf )

File.Copy(plug.FullName, Path.Combine(di.FullName, plug.Name), true);

}

// Now, we need to tell the BuildManager that our plugin DLLs exists and to reference them.

// There are different Assembly Load Contexts that we need to take into account which

// are defined in this article here:

// http://blogs.msdn.com/b/suzcook/archive/2003/05/29/57143.aspx

// * This will put the plugin assemblies in the 'Load' context

// This works but requires a 'probing' folder be defined in the web.config

foreach (var a in

ShadowCopyFolder

.GetFiles("*.dll", SearchOption.AllDirectories)

.Select(x =>  AssemblyName.GetAssemblyName(x.FullName))

.Select(x => Assembly.Load(x.FullName)))

{

BuildManager.AddReferencedAssembly(a);

}

// * This will put the plugin assemblies in the 'LoadFrom' context

// This works but requires a 'probing' folder be defined in the web.config

// This is the slowest and most error prone version of the Load contexts.

//foreach (var a in

//    ShadowCopyFolder

//    .GetFiles("*.dll", SearchOption.AllDirectories)

//    .Select(plug => Assembly.LoadFrom(plug.FullName)))

//{

//    BuildManager.AddReferencedAssembly(a);

//}

// * This will put the plugin assemblies in the 'Neither' context ( i think )

// This nearly works but fails during view compilation.

// This DOES work for resolving controllers but during view compilation which is done with the RazorViewEngine,

// the CodeDom building doesn't reference the plugin assemblies directly.

//foreach (var a in

//    ShadowCopyFolder

//    .GetFiles("*.dll", SearchOption.AllDirectories)

//    .Select(plug => Assembly.Load(File.ReadAllBytes(plug.FullName))))

//{

//    BuildManager.AddReferencedAssembly(a);

//}

}

}

}

<!-- AddThis Button BEGIN --><div class="addthis_toolbox addthis_default_style "><a class="addthis_button_preferred_1"></a><a class="addthis_button_preferred_2"></a><a class="addthis_button_preferred_3"></a><a class="addthis_button_preferred_4"></a><a class="addthis_button_compact"></a><a class="addthis_counter addthis_bubble_style"></a></div><script type="text/javascript" src="http://s7.addthis.com/js/250/addthis_widget.js#pubid=nopsolutions"></script><!-- AddThis Button END -->